task-pipeline

Shape: static. The stage list is decided before the run and stays decided, because stage 10 has to account for what ran. THREE places discover structure, and they do not land the same way: the module map and the carry-over ledger are committed artifacts, and since v1.69.0 the work graph is a third — `.task-pipeline/graph.json`, mutated mid-run by `graph.py add` and deliberately NOT committed. Every mutation records why it happened, which is what keeps a run from explaining its completion by a plan that existed only at the end; that the graph itself does not survive the run is an open row rather than a settled decision.

task-pipeline

Use when work changes the repository — feature, fix, bug, refactor, migration, integration, rewrite, adoption or hardening, or when the output is a finding that lands in it: audit, bug hunt, production check, PR review. Runs a substantial task through an intake grill, docs study, brainstorm, spec, plan, build, tests, deploy, post-deploy, docs/wiki sync and acceptance with explicit gates. reports unconfirmed releases; audits existing docs. Not for: answering a question, explaining code, a typo or a one-line edit, a mechanical rename, reconnaissance that lands nothing — say to opt out.

evidence-docs

Use when writing or reviewing anything that will be read as true — a decision record, a README, an acceptance report, a runbook, a changelog entry, an audit finding, or any claim that something was verified. Applies the ten canons of evidence-backed documentation — what makes a claim documentation rather than an assertion, and routes to the doctrine that enforces each one. Also use when a project needs a documentation gate, a decision register, a propagation matrix, or a retrospective that outlives its author. Not for: drafts, chat answers, commit messages or code comments — say to opt out.

project-audit

Use when someone asks what is actually true of a whole project right now — what is finished, what is half-built, what is broken, and what nobody has looked at. Walks a cold start: discover what the project is, run a registry of probes chosen from that, read production evidence (published artefact against source, CI history, telemetry present or absent), then leave a JSON sidecar so the next audit can say what moved, and a self-contained HTML report on request. Read-only: it proposes board rows and commits nothing. Not for: auditing one deliverable inside a run (that is the pipeline's own ladder), reviewing a diff, or checking a skill's construction — say to opt out.

/task-pipeline — how the change reaches the repository

• when: the change touches the repository
• decline it: no pipeline

If task-pipeline is installed, substantial repository changes go through it — feature, fix, refactor, migration, integration, rewrite, adoption, hardening, in any language. Planning is part of the pipeline: brainstorm, spec and plan occupy stages 2–4, never a parallel planning cycle.

The boundary. NOT through it: questions, explanations, reading/analysing code; typos, one-line edits, mechanical renames; reconnaissance/measurement that commit nothing.

Refusal phrase: "no pipeline" or «без пайплайна». Name the chosen route for borderline cases.

Among the routers: super-ux owns interface behavior; task-pipeline delivery.

/project-audit — what is actually true of this project right now

• when: the question is the whole project, not one change
• decline it: no diagnosis

If task-pipeline is installed, whole-project truth goes through project-audit — finished, partial, broken or unexplored. Cold start/no brief: discover the project and production evidence beyond Git; produce HTML + JSON. Read-only: findings become proposed board rows, not project edits.

The boundary. NOT through it: a run's deliverable audit, diff/PR review, skill construction (make-skill), code vs scenarios (/ux-audit).

Refusal phrase: "no diagnosis" or «без диагностики» — avoid «без аудита»: аудит triggers task-pipeline.

Among the routers: project-audit diagnoses before changes; task-pipeline delivers them.