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 — how the change reaches the repository

• when: the change touches the repository
• decline it: «без пайплайна» or «quick».

If task-pipeline is installed, any work that CHANGES THE REPOSITORY goes through it — no separate request needed. Feature, fix, refactor, migration, integration, rewrite, adoption, hardening; in any language and any wording. Planning that work is part of the pipeline, not a cycle beside it: brainstorm, spec and plan are its stages 2–4, and no separate planning route exists alongside it.

The boundary — "it changes the repository," and it cuts both ways. NOT through the pipeline: a question and its answer, an explanation, reading and analysing code; a typo, a one-line edit, a mechanical rename; reconnaissance and measurement that commit nothing. Running ten stages for a single character is the fastest way to teach an agent to route around it.

Refusal phrase: «без пайплайна» or «quick». For a borderline case, name the route you are taking in one line rather than choosing silently.

Among the routers: super-ux decides what the interface must do; task-pipeline how the change reaches the repository. The first owns the content, the second the delivery.

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

• when: the question is the whole project, not one change
• decline it: «без диагностики»

If task-pipeline is installed, asking what is TRUE of a whole project goes through project-audit — what is finished, what is half-built, what is broken, and what nobody has looked at. It runs from a cold start, with no brief and no requirement spine: discover what the project is, choose probes from that, read the production evidence a repository cannot hold — the published artefact against its source, the release pipeline's failure rate, telemetry present or absent — and leave an HTML report beside a JSON sidecar so the next audit can say what moved. It is read-only: findings leave as proposed board rows, and nothing is written.

The boundary — "the subject is the project, not a change." NOT through it: auditing one deliverable inside a run, which is the pipeline's own ladder; reviewing a diff or a PR; a skill's construction, which is make-skill; code against its scenarios, which is /ux-audit. Pointing it at a two-file change is how you teach an agent to skip it on the repository that needed it.

Refusal phrase: «без диагностики» — not «без аудита», because аудит is task-pipeline's own trigger and a refusal containing a trigger fires the hook it exists to silence.

Among the routers: task-pipeline decides how a change reaches the repository; project-audit says what is there before any change is proposed. The first owns the delivery, the second the diagnosis.