Rider: agent-config defects fixed alongside #974

What is this?

A rider, not a project.

• These are small agent-config defects found while mapping the agent-config files during the #974 work. Each is rule 18 territory (a config surface found broken gets fixed in the moment), and none of them is big enough to deserve a project folder of its own.
• They live here because this is the folder the session was already writing into. They have nothing to do with the PM lane guard beyond that.
• Each is its own commit, separate from the guard fix, so the guard commit reads on its own.

What was fixed?

1. Two em dashes in pr-workbench, one of them in the description every tool indexes.

• The file was grandfathered at 2 in the ratchet baseline, so neither failed the gate. Line 4 was the expensive one: a skill description propagates into every tool's skill index, so the character was being republished into four generated copies.
• Line 90's table cell became a comma. Line 4 was rewritten anyway for the next defect.
• The baseline was tightened rather than left slack. All four entries (.agents, .claude, .gemini, .github copies) were removed from no-em-dash-baseline.json, which pins the file at zero. A win left in the baseline is a win that silently regresses.

2. The pr-workbench description contradicted its own body.

	Text
Was	"This skill covers the full lifecycle from fetching PR details through pushing, merging to dev is handled manually via GitHub UI."
Now	"Covers the full lifecycle, from fetching PR details through pushing and driving the open PR to the merge gate. Marking a PR ready and merging still need her word at the moment of action, or the autonomy grant in session-pr."

• Its own Step 7, and both session-pr and autopilot, describe an agent squash-merging under an autonomy grant. A description is what an agent reads when deciding whether to LOAD a skill, so a stale one misroutes before anyone can reach the correction inside.
• The new text does not widen anything: it names the gate rather than the door, and rule 16 plus the two PreToolUse hooks are unchanged.

3. autopilot pointed at a brainstorming skill that does not exist.

• Step 2 read "New feature or ambiguous scope → planning / brainstorming first". There is no such directory under .agents/skills/, and that line was the only reference in the tree.
• The dead half was removed rather than replaced, per the instruction not to create a skill for it. planning already owns that job, so the line now names it and says so: "→ planning first (it owns the consolidate-then-spec loop)".

What was NOT touched?

• .agents/ is the source and the generated copies were regenerated, never hand-edited. npm run sync:all, not sync:agents, which alone leaves the skill copies stale.
• Nothing in the PM lane guard, and nothing about when a PR is marked ready or merged.

Second rider: the draft-PR contradiction, settled by her ruling

What is this?

Also a rider, and also not a project.

• Two rule-versus-rule contradictions surfaced in the same sweep, went to the operator, and came back decided. This records the three text fixes that carry the decision, as its own commit.

Her ruling.

• She had misread a draft pull request as a ready one and ordered the timing changed. On learning it was a draft she reversed herself: "in that case drafts are fine. I thought you were trying to open the PR, not draft it. That was my mistake." Then, on being shown the contradictions: "lets fix the rules please."
• So non-negotiable rule 12 is correct and stands: one branch, one draft pull request opened early, marked ready once at session end. The places below are the ones that were wrong, and they now match it. Rule 12 itself was not touched, and nothing about when a PR is marked ready or merged moved. Only when it is OPENED.

What changed?

1. pr-workbench Step 3: the review gate was genuinely wrong, not narrowly scoped.

• The sentence sits inside the "Driving an open PR" checklist, so a narrow reading was plausible: the PR already exists by then, and the gate is really about what happens next. But the words do not support it. The old text said "do not push or open the PR until the review is back" and then "then open the draft and see the loop through to merge", which puts the draft's creation explicitly after the review. That cannot be reconciled with autopilot, which opens the draft at step 1 and reviews at step 3, or with rule 12.
• Fixed in two places, because the same claim appeared twice in the step.

	Text
Was (heading line)	"Run /code-review here, and before opening ANY PR (operator workflow gate)."
Now	"Run /code-review here, and before ANY PR is marked ready (operator workflow gate). The draft itself opens at the START of the work (rule 12), so what waits for the review is putting the PR in front of a reviewer, never creating it."
Was (body)	"Treat it as the same tier as npm run validate: do not push or open the PR until the review is back, ... then open the draft and see the loop through to merge"
Now	"Treat the gate as the same tier as npm run validate: the draft is already open, and what waits for the review is marking it ready and merging. ... then see the loop through to merge"

• Her 2026-07-25 grant is quoted in that paragraph and the quote stays verbatim. It conditioned the autonomy on "run /code-review before any PR open", which is the sentence the whole contradiction grew out of. Rather than silently re-reading her words, the paragraph now carries her 2026-08-27 clarification next to them and says how to read the earlier phrase: before the PR is put in front of a reviewer.

2. ONBOARDING.md taught open-at-the-end in FIVE places, not one.

The named line was 626. Four more copies of the same teaching sat in the same file, two of them runnable command blocks a newcomer copies rather than reads. Leaving them would have forked the rule the way a stale template does, which is the most expensive drift shape this repo has.

Where	Was	Now
First-pull-request block	"Do the work, then when it is ready to share: npm run validate then gh pr create --draft"	"Open the draft PR right away, before the work" (push plus gh pr create --draft), then a second block: when the work is ready, npm run validate then gh pr ready
The bullet under it	"Open PRs as drafts. ... Mark it ready when you want review."	"Open the PR as a draft, and open it EARLY (rule 12). ... an early draft is free and gives your reviewer a live diff to watch. Mark it ready once, when the work is done."
Daily flow, step 4	"When the work is READY, run the gate once, then open a draft PR"	Step 2 is now "Open the draft PR EARLY (rule 12)", and the final step runs the gate then gh pr ready. Steps renumbered, and a git push added to the commit step
"Before You Open a PR" heading	the validate gate sat under a heading that now names the wrong moment	"Before You Mark the PR Ready"
"PR Rules" bullet	"Open it as a draft (--draft); mark ready when you want review"	"Open it as a draft (--draft), early, at the start of the work (rule 12); mark ready once when the work is done"

• The prose paragraph that summarizes those rules moved from two rules to three, so it names the early-draft half rather than only the draft half.
• The validate gate did not move. It still runs once, when the work is ready, exactly as rule 3 says. Only the heading naming the moment changed, because "before you open a PR" now points at the wrong end of the session.

3. session-pr: the heading called a fixed point a FLOOR.

	Text
Was	"## Merge timing: ~6pm Pacific is a FLOOR and a sync point, not a deadline"
Now	"## Merge timing: ~6pm Pacific is a FIXED sync point, not a floor and not a deadline"

• The body already says merging before ~6pm needs her explicit per-PR word and that "don't merge at the last minute" means don't slip past. That is a fixed point in both directions, and a floor is only one of them. The heading is the half that gets skimmed, so it was the half doing the damage.

What was found and NOT changed?

• Nothing else carried either contradiction. FLOOR appears in exactly one place under .agents/, and the remaining draft references in pr-workbench (the push-discipline paragraph and Step 7) already describe opening drafts early and leaving ready-marking to her.