git:20260829.0e758b6 to git:20260911.1a9f16c

+ Read `references/task-visibility.md` before step 1: it defines the stage-level view this pipeline publishes through the platform's task-tracking capability, the per-step chat narration, and the completion rule: a step is done only after it ran, and the turn does not end before DONE or a GATE stop.

+ Before step 1, judge whether the conversation expresses semantic intent to assign a stage — planning or implementation — to a model or harness; a plain mention in feature content, quotes, comparisons, or a filename is not an assignment. When one exists, read `references/stage-routing.md` before step 1. It alone defines the routable stages, scope and strength resolution, the `implementation_engine` grammar, ordered fallback, the sanitization that keeps routing out of planning and review inputs, and the exact carrier strings (the prefix that passes the assignment to a child skill) for both handoffs. A carrier you improvise drops the user's instruction or contaminates the plan with routing.

+ 1. **Read `references/plan-brief.md` first**, then invoke the `ce-plan` skill with the sanitized feature request — or the arguments you were invoked with, unchanged, when no routing directive was present — prefixed with the `plan_model:<alias>` carrier when a planning-stage directive resolved, and with the settled-decisions brief that file specifies. That file alone defines the artifact-root rule this step's GATE reads, the brief's required fields, demotion rule, topical scope bar, and skip-entirely case, and the readiness values the GATE applies.

+ 2. **Read `references/work-return.md` first**, then invoke the `ce-work` skill with `mode:return-to-caller <plan-path-from-step-1>`, or with the carrier form from `references/stage-routing.md` when a routing carrier resolved. That file alone defines what each return status means, the fields a `status: complete` return must contain, the verification evidence it must carry, where `settled_decision_conflicts` go, and the one recovery invocation.

+ 3. **Read `references/review-followup.md` now**, then invoke the `ce-simplify-code` skill on the branch diff — **skip** only the invocation, never the read, when the change is docs-only (only markdown/docs paths changed) or trivial (roughly under 10 changed lines). That file governs steps 3 through 6. It alone defines this step's scope and the structure it must keep, how to read the review back, which findings step 5 applies and how they are committed, and the residual record step 6 writes down.

+ 6. **Autonomous residual handoff** — run it whenever anything unresolved is left to record: an actionable `downstream-resolver` finding step 5 did not apply, a `settled_conflict` stamp from step 4, or a proceeded-and-flagged `settled_decision_conflicts` entry from step 2. Skip only when none of the three exists — `Actionable findings: none.` does not decide it alone.

+ 8. Ship: the goal is the remaining work committed, pushed, and in an open PR whose URL you hold. **Read `references/shipping-tail.md` first** — it governs steps 8 through 10 — then invoke the `ce-commit-push-pr` skill with `mode:pipeline branding:on` unless that file routes this run elsewhere. That file alone defines when a project-defined process replaces that default and the blocked stop when the process falls short, what LFG passes into the skill, the `New concepts:` trailer and ticket back-fill, the no-remote substitution, and step 9's stack handoff.

+ 10. Output `<promise>DONE</promise>` when complete, after the close-out in `references/shipping-tail.md`, which defines the two user-runnable handoff lines, how each host renders them, and when to offer the next piece of work.