SSOT conflict: implement's completion handoff prescribes a different pre-PR order than pre-pr.md, which declares its order unreorderable

[kyle-sexton]

Spun out of Lane C (#2936) during adversarial validation — this is the one genuine find from the rejected "zero-assembly chain doc" proposal. Refs #2933.

The conflict

Two surfaces own an ordered pre-PR sequence, and they disagree.

plugins/session-flow/skills/workflow/context/pre-pr.md — "Complete in order; each step gates the next":

1. Test thoroughly
2. Review (self-review the full diff, or dispatch a fresh-context reviewer)
3. Stage surgically
4. Simplify
5. Review the simplify diff
6. Re-test after simplify
7. Verify outcome (confirm the result matches the original intent, with evidence)
8. Open the PR

That file then declares the ordering fixed:

Override boundary. This sequence — its steps and their order, including the simplify pass (4–6) — is fixed plugin identity, not consumer config; there is no seam to reorder it or swap in a different checklist by editing the plugin.

plugins/implementation/skills/implement/SKILL.md:186, step 5, titled "Hand off to the pre-PR sequence":

run /verification:confirm for outcome verification when the verification plugin is installed …, then suggest the project's review/PR flow (/review:quality-gate and /source-control:pull-request when those plugins are installed …)

and the same ordering again in the chaining table at :199:

All implementation complete, tests pass → /verification:confirm …, then suggest the project's review/PR flow

So implement puts outcome verification before review; pre-pr.md puts review at step 2 and outcome verification at step 7, after the simplify pass. The step that names itself a handoff to the pre-PR sequence prescribes an order that sequence forbids.

Why it matters

This is not cosmetic. Under pre-pr.md's order, the simplify pass (4–6) happens before outcome verification, so what gets verified is the simplified code. Under implement's order, /verification:confirm renders its verdict on pre-simplify code and the simplify edits ship unverified. Only one of these can be the repo's doctrine.

Compounding it: pre-pr.md claims there is no seam to reorder its sequence, while a sibling plugin in the same fleet effectively reorders it at the handoff point — which makes the override-boundary paragraph inaccurate as written, whichever order wins.

What to decide

1. Which order is doctrine. (No pre-judgment here — the implement order has a defensible reading too: confirm that the thing works before spending review effort on it.)
2. Where the order is owned. PLUGIN-PHILOSOPHY.md:474-476 routes a cross-plugin concern to a docs/conventions/ owner doc rather than to either plugin's own surface; pre-pr.md currently owns it de facto from inside one plugin.
3. Whether pre-pr.md's "no seam to reorder" claim survives, and in what wording.

Explicitly out of scope

Writing a canonical "default execution chain" document. That proposal was rejected with reasons in Lane C — the chain as drafted was factually wrong (the fresh-context phase verifier fires at every phase boundary, a loop, while confirm → quality-gate → pull-request fires once at completion, and that verifier is dispatched by implementation:implement-dispatch, not implement), and converting implement's inline mentions into citations would strip the presence gates from the invocation sites, which the seam-phrasing convention places exactly there. This issue is the narrow ordering conflict only.

Acceptance criteria

• One order is stated as doctrine, in one place, with the other surface citing it
• pre-pr.md's override-boundary paragraph is accurate with respect to that decision
• implement/SKILL.md:186 and :199 agree with the decided order, with their presence gates intact