Motir

renderSessionPrBody builds the pull request from DispatchRecord[] — one - KEY — title line per card, the failed ones, and the motir done --session instruction. It is a MANIFEST: fully traceable, and it says nothing about what the branch does.

A card title is what was planned. The commit is what was done — including everything that only surfaced while doing it. Those diverge, and the commit is the truer record.

From this story's own branch, the same card two ways:

From the title: 11.5.17 searchWorkItems onto the v1 collection, and the four total readers onto countWorkItems

From the commit: three call sites were never searches — they sent limit: 1, threw the row away, and read the total because the old transport made a count free. Each is one request now.

Same card. Only one of them tells a reviewer what changed.

Who writes what — and neither can do the other's job

The AGENT writes the substance. One card, one commit; that commit message is the per-card narrative, written by the only actor that knows what the change means. It already exists — nothing new is authored for the pull request. 11.5.25 tells the agent that this message becomes the body, and what that asks of it.

The LOOP writes the frame. Which run, which branch, which cards were skipped and why, how the run stopped, whether a re-plan is pending, and the close-out instruction. An agent saw one card and can know none of it.

So the body becomes the loop's frame plus the commits between the base and the branch head, instead of the card titles.

What to build

1. renderSessionPrBody reads the commit range for THAT repo's branch rather than reconstructing prose from records. ⚠️ Per repo: a multi-repo run opens one pull request per repo, and each body must carry only its own commits — the range is read in that repo's cwd, against that repo's branch.
2. Each commit contributes its SUBJECT as the list entry and its BODY as the reasoning beneath. "Review this as ONE unit" is exactly when a reviewer needs the why, so the bodies are not dropped in favour of a link to the commits tab.
3. A commit with an empty body falls back to the card's title, so a thin commit degrades to today's output rather than to a bare subject line with nothing under it.
4. The frame survives unchanged: run id, branch, the carried and failed lists, the close-out instruction.

Scope BOUNDARY

renderSessionPrBody and its tests. It does NOT change the TITLE — sessionPrTitle stays Motir auto run <runId> — N work items. A better title would name the parent story the cards share, which needs a parent the loop does not read; that is a separate card, and mixing it in would buy a read this one does not need. It does NOT change closeOutRepos' orchestration, the git helper, or motir batch. It does NOT add a network call: the commit range is a local git read.

Acceptance criteria

• The body carries every commit on the branch, subject and body, in branch order — asserted against a real repository with more than one commit, because the ordering and the per-repo scoping are the two things a records-shaped implementation gets wrong.
• A multi-repo run's pull requests each carry ONLY their own repo's commits, asserted with two repos on the same run.
• A commit with an empty body renders the card's title instead, and never a bare subject.
• The frame is unchanged: run id, branch, carried list, failed list, close-out instruction — asserted with the existing strings untouched, so this trades nothing for what it adds.
• A run whose branch has no commits opens no pull request, exactly as today.
• No network call is added; the commit read is local git.

Context refs

• packages/cli/src/autoLoop.ts — renderSessionPrBody, sessionPrTitle, DispatchRecord.
• packages/cli/src/commands/auto.ts — closeOutRepos, and RepoSession (cwd, branch, keys) which scopes the range per repo.
• packages/cli/src/git.ts — the gh pr create helper that receives the body; unchanged by this card.
• 11.5.25 — the prompt, which TELLS the agent its commit message becomes this body and what that asks of it. Without that instruction the quality would be incidental; with it, this card has something worth assembling. The two are independently shippable and better together.
• Story: MOTIR-1855.