task-pipeline-skill 1.94.1 → 1.96.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +73 -0
- package/CONTRIBUTING.md +32 -0
- package/HOW-IT-WORKS.md +4 -3
- package/README.md +19 -7
- package/SKILL-CARD.md +2 -2
- package/evals/RESULTS.md +55 -8
- package/evals/cases/task-pipeline.json +139 -0
- package/evals/fixtures/lessons/expect-match.sh +30 -0
- package/evals/fixtures/lessons/index.jsonl +2 -0
- package/evals/fixtures/waves-unclaimed/expect-refusal.sh +26 -0
- package/evals/fixtures/waves-unclaimed/inventory.json +33 -0
- package/evals/fixtures/waves-unclaimed/modules.json +4 -0
- package/evals/fixtures/waves-unclaimed/plan.json +5 -0
- package/evals/task-pipeline.evals.json +104 -0
- package/package.json +1 -1
- package/plugins/task-pipeline/.claude-plugin/plugin.json +1 -1
- package/plugins/task-pipeline/agents/verifier.md +1 -1
- package/plugins/task-pipeline/commands/task-pipeline.md +3 -2
- package/plugins/task-pipeline/hooks/release-gate.sh +1 -1
- package/plugins/task-pipeline/skills/task-pipeline/SKILL.md +16 -11
- package/plugins/task-pipeline/skills/task-pipeline/pipeline.example.json +4 -0
- package/plugins/task-pipeline/skills/task-pipeline/pipeline.schema.json +19 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/artifacts.md +1 -1
- package/plugins/task-pipeline/skills/task-pipeline/references/audit.md +5 -2
- package/plugins/task-pipeline/skills/task-pipeline/references/brainstorm.md +1 -1
- package/plugins/task-pipeline/skills/task-pipeline/references/browser.md +1 -1
- package/plugins/task-pipeline/skills/task-pipeline/references/certification.md +1 -1
- package/plugins/task-pipeline/skills/task-pipeline/references/companion-skills.md +3 -2
- package/plugins/task-pipeline/skills/task-pipeline/references/continuity.md +10 -2
- package/plugins/task-pipeline/skills/task-pipeline/references/doctrine-map.md +20 -2
- package/plugins/task-pipeline/skills/task-pipeline/references/finish-line.md +145 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/grill.md +1 -1
- package/plugins/task-pipeline/skills/task-pipeline/references/iteration.md +9 -5
- package/plugins/task-pipeline/skills/task-pipeline/references/loop-guard.md +5 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/portability.md +13 -1
- package/plugins/task-pipeline/skills/task-pipeline/references/progress.md +8 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/review.md +7 -2
- package/plugins/task-pipeline/skills/task-pipeline/references/spec.md +7 -5
- package/plugins/task-pipeline/skills/task-pipeline/references/stage-00-intake.md +158 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/stage-01-docs-study.md +10 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/stage-02-brainstorm.md +52 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/stage-03-spec.md +66 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/stage-04-plan.md +11 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/stage-05-dev.md +55 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/stage-06-tests.md +11 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/stage-07-lint-deploy.md +15 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/stage-08-post-deploy.md +29 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/stage-09-docs-wiki.md +45 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/stage-10-acceptance.md +91 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/stages.md +49 -484
- package/plugins/task-pipeline/skills/task-pipeline/references/verification.md +1 -1
- package/plugins/task-pipeline/skills/task-pipeline/references/waves.md +9 -6
- package/plugins/task-pipeline/skills/task-pipeline/scripts/graph.py +1 -1
- package/plugins/task-pipeline/skills/task-pipeline/scripts/stage_checkpoint.py +156 -33
- package/plugins/task-pipeline/skills/task-pipeline/scripts/waves.py +219 -3
- package/plugins/task-pipeline/skills/task-pipeline/templates/brief.md +14 -0
- package/plugins/task-pipeline/skills/task-pipeline/templates/inventory.schema.json +15 -1
- package/plugins/task-pipeline/skills/task-pipeline/templates/run.md +26 -2
|
@@ -36,7 +36,8 @@ A fix designed against today's state is the intermediate state that
|
|
|
36
36
|
seam, and the fix is then paid for twice. The finding gets an id in its owning register
|
|
37
37
|
and lands on a canvas node. Its wave decides when it is built.
|
|
38
38
|
|
|
39
|
-
**The hotfix lane is the only exception, and it is closed.**
|
|
39
|
+
**The hotfix lane is the only exception, and it is closed.** This list is its single home;
|
|
40
|
+
[`finish-line.md`](finish-line.md)'s blocking test B2 cites it. It has five entries:
|
|
40
41
|
- production is down;
|
|
41
42
|
- data is being lost or corrupted;
|
|
42
43
|
- a credential has leaked;
|
|
@@ -57,12 +58,12 @@ reason. "It is quick" is not one of the five entries.
|
|
|
57
58
|
| 4 | Question round | answers from the sources, then one batch to the operator | every question is answered, assumed, or blocks a named node |
|
|
58
59
|
| 5 | Plan | the work graph with waves and risk classes — `scripts/waves.py sync-graph` writes each node's `wave` and `risk` from the plan, so `graph.py close` enforces the rounds it owes — and one packet per node | every REQ lands on a node; [`planning.md`](planning.md)'s set comparison holds |
|
|
59
60
|
| 6 | Build | parallel agents, each owning disjoint files | each node is committed on its branch, with its own checks green |
|
|
60
|
-
| 7 | Verify | rounds per node, starting as each node lands | each node passes its risk class's rounds |
|
|
61
|
+
| 7 | Verify | rounds per node, starting as each node lands; each finding triaged at discovery ([`finish-line.md`](finish-line.md)) | each node passes its risk class's rounds |
|
|
61
62
|
| 8 | Seam check | cross-module checks per seam group | every seam the canvas names is exercised end to end |
|
|
62
63
|
| 9 | Docs | stage 9 over everything the release iteration shipped | the doc gate passes and the docs match the code |
|
|
63
64
|
| 10 | Release | versions, tags, pins, changelogs, in dependency order | the published artefacts resolve |
|
|
64
|
-
| 11 | Post-release check | the stage-8 trio on what was released | every item the release claims closed is checked on the released artefact |
|
|
65
|
-
| 12 | Next pool | the re-measured inventory and the proposal | the hand-back is sent |
|
|
65
|
+
| 11 | Post-release check | the stage-8 trio on what was released, read as a finish-line round | every item the release claims closed is checked on the released artefact, and `finish:` is computed |
|
|
66
|
+
| 12 | Next pool | the re-measured inventory and the proposal | the hand-back, with its `finish:` line, is sent |
|
|
66
67
|
| 13 | Retrospective | the project retro, plus the shared lesson store where one exists | written last ([`retrospective.md`](retrospective.md)) |
|
|
67
68
|
|
|
68
69
|
Steps 1–4 are stages 0–4 run once. Steps 6–8 are stages 5–8 per wave, and a wave's
|
|
@@ -218,7 +219,10 @@ actually published, installed or deployed — never on the branch. Each item the
|
|
|
218
219
|
claims closed is re-checked against the released artefact. For installed packages and
|
|
219
220
|
skills, follow [`deploy-targets.md`](deploy-targets.md) → *The verification trio*: update
|
|
220
221
|
within the authorized rollout and read back each claimed installed channel. A failure goes to the hotfix
|
|
221
|
-
lane if it is one of its five entries.
|
|
222
|
+
lane if it is one of its five entries. Every post-release failure is triaged at the finish
|
|
223
|
+
line ([`finish-line.md`](finish-line.md) → *Triage at discovery*): a blocking one is fixed in
|
|
224
|
+
this release iteration, and the corrective release counts against `run.finish.maxReleases`; a
|
|
225
|
+
deferred one goes to the next pool, with an id.
|
|
222
226
|
|
|
223
227
|
## The next pool
|
|
224
228
|
|
|
@@ -101,6 +101,11 @@ review cap reached — 3 rounds — artifact: test/validate.py
|
|
|
101
101
|
- **New > self-inflicted** — the reader is still paying. Continuing is then the
|
|
102
102
|
operator's call, made with the numbers in hand rather than out of fatigue.
|
|
103
103
|
|
|
104
|
+
At the level of a whole iteration only new **blocking** findings argue for continuing; a
|
|
105
|
+
deferred or noise finding is paid for on the board, not with another round
|
|
106
|
+
([`finish-line.md`](finish-line.md) → *Rounds and the stop*). The class is read from the
|
|
107
|
+
run ledger's `finding:` lines and the rounds from its `round:` lines, never from memory.
|
|
108
|
+
|
|
104
109
|
**The pair is the whole point.** A round count alone says how tired everyone is; the
|
|
105
110
|
pair says whether the loop still produces anything. Measured on one file once, the
|
|
106
111
|
guard's shapes and the run's own prose disagreed — one still paying, one exhausted —
|
|
@@ -39,8 +39,19 @@ a row pointing outside the bundle is the defect this file exists to catch.
|
|
|
39
39
|
|
|
40
40
|
| Workflow decision | Home |
|
|
41
41
|
|---|---|
|
|
42
|
+
| 0 · Stage procedure | `references/stage-00-intake.md` |
|
|
43
|
+
| 1 · Stage procedure | `references/stage-01-docs-study.md` |
|
|
44
|
+
| 2 · Stage procedure | `references/stage-02-brainstorm.md` |
|
|
45
|
+
| 3 · Stage procedure | `references/stage-03-spec.md` |
|
|
46
|
+
| 4 · Stage procedure | `references/stage-04-plan.md` |
|
|
47
|
+
| 5 · Stage procedure | `references/stage-05-dev.md` |
|
|
48
|
+
| 6 · Stage procedure | `references/stage-06-tests.md` |
|
|
49
|
+
| 7 · Stage procedure | `references/stage-07-lint-deploy.md` |
|
|
50
|
+
| 8 · Stage procedure | `references/stage-08-post-deploy.md` |
|
|
51
|
+
| 9 · Stage procedure | `references/stage-09-docs-wiki.md` |
|
|
52
|
+
| 10 · Stage procedure | `references/stage-10-acceptance.md` |
|
|
42
53
|
| The stage list, ids, names, gate types | `pipeline.example.json` |
|
|
43
|
-
|
|
|
54
|
+
| Full gates, freedom levels, the run checklist and exact stage-detail routes | `references/stages.md` |
|
|
44
55
|
| Which reference owns which stage (the doctrine map) | `references/doctrine-map.md` |
|
|
45
56
|
| What the intake grill asks, and the autonomy sweep | `references/grill.md` |
|
|
46
57
|
| **The escalation boundary** — what an agent may settle alone | `references/grill.md` |
|
|
@@ -53,6 +64,7 @@ a row pointing outside the bundle is the defect this file exists to catch.
|
|
|
53
64
|
| The entry audit and what it inspects | `references/setup.md` |
|
|
54
65
|
| The ladder, seams, axis rotation, ratchets | `references/audit.md` |
|
|
55
66
|
| Loop detection and its caps | `references/loop-guard.md` |
|
|
67
|
+
| **The finish line** — when an iteration stops: the contract, triage at discovery, the round budget | `references/finish-line.md` |
|
|
56
68
|
| **What the run prints about itself** — the header block, the rail, the iteration line | `references/progress.md` |
|
|
57
69
|
| **What the run leaves running and leaves behind** — the eight classes, the `holds:` field, the teardown | `references/residue.md` |
|
|
58
70
|
| **The run mode** — item-by-item pacing, default off, what it never collapses | `references/continuity.md` |
|
|
@@ -169,6 +169,9 @@ SCOPE what this claim covers: the commit, the environment, the REQ
|
|
|
169
169
|
NOT VERIFIED what was built and NOT checked, or could not be. The literal
|
|
170
170
|
`none within the stated scope` is a valid answer; an empty
|
|
171
171
|
field is not
|
|
172
|
+
FINISH finish: done | budget | blocked — the finish block, as
|
|
173
|
+
finish-line.md prints it; mid-iteration, the round and
|
|
174
|
+
the open blocking count
|
|
172
175
|
|
|
173
176
|
DECISIONS WAITING <n> each as a question with options, asked HERE
|
|
174
177
|
AMBIGUITIES <n> computed, below
|
|
@@ -189,6 +192,11 @@ And `none within the stated scope` is a claim with a subject — it says *nothin
|
|
|
189
192
|
what SCOPE names is unverified*. Leaving the field empty says nothing at all, which reads
|
|
190
193
|
as the same thing and is not: canon 9a, one artifact over.
|
|
191
194
|
|
|
195
|
+
**`FINISH` says why the iteration stopped** ([`finish-line.md`](finish-line.md) → *The
|
|
196
|
+
finish block*): `done` with its exit checks green on the artefact, `budget` with each open
|
|
197
|
+
blocker a `needs-operator` board row, or `blocked`. A hand-back that cannot fill it has not
|
|
198
|
+
reached a finish line, and says which round it is in.
|
|
199
|
+
|
|
192
200
|
**Where there is no brief** — `checkup`, `setup`, a short path — TASK quotes the
|
|
193
201
|
operator's own sentence instead, marked as such. An unquotable TASK is a run that cannot
|
|
194
202
|
say what it was asked, which is worth its own line.
|
|
@@ -108,14 +108,19 @@ Review in this order; stop reading the diff only when you've covered all of it.
|
|
|
108
108
|
**Severities:**
|
|
109
109
|
|
|
110
110
|
- **Critical** — wrong behavior, data loss, security hole, a red or dishonest test
|
|
111
|
-
suite. Blocks.
|
|
111
|
+
suite. Blocks the node when the defect is in its diff or caused by it.
|
|
112
112
|
- **Important** — a real defect or spec gap that will bite: missing requirement,
|
|
113
|
-
unhandled failure path, a magic value the constraints named. Blocks
|
|
113
|
+
unhandled failure path, a magic value the constraints named. Blocks the node when the
|
|
114
|
+
defect is in its diff or caused by it.
|
|
114
115
|
- **Minor** — style, naming, a nit with no behavioral consequence. Never blocks;
|
|
115
116
|
goes to the ledger.
|
|
116
117
|
- **⚠️ Cannot verify from diff** — the requirement lives in unchanged code or spans
|
|
117
118
|
tasks. Not a blocker for the reviewer; the controller resolves it.
|
|
118
119
|
|
|
120
|
+
**A pre-existing defect the reviewer notices** — one the diff neither contains nor
|
|
121
|
+
causes — does not block the node, whatever its severity. It goes to finish-line triage
|
|
122
|
+
([`finish-line.md`](finish-line.md) → *Triage at discovery*).
|
|
123
|
+
|
|
119
124
|
Formatting nits that don't change meaning are not findings. Praise is not a
|
|
120
125
|
finding either.
|
|
121
126
|
|
|
@@ -28,9 +28,12 @@ spec*.
|
|
|
28
28
|
|
|
29
29
|
## UX track (user-facing tasks only)
|
|
30
30
|
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
31
|
+
Apply [the artifact-provider contract](companion-skills.md): super-ux is the
|
|
32
|
+
preferred provider; equivalent artifacts or the inline fallback remain valid.
|
|
33
|
+
Missing or invalid scenario artifacts stop the gate, regardless of provider.
|
|
34
|
+
Record each unavailable check by name as NOT_RUN; do not claim a linter ran.
|
|
35
|
+
The following chain describes the super-ux provider when available. Other
|
|
36
|
+
providers owe the same scenario quality and traces, not these package commands.
|
|
34
37
|
|
|
35
38
|
0. **The design destination is already decided — read it, don't re-open it.** When
|
|
36
39
|
Figma is on, the stage-0 brief names the team/org and the files — one per surface
|
|
@@ -94,8 +97,7 @@ green over both.
|
|
|
94
97
|
not checkable; a record is. The track writes a **director record** in the product's
|
|
95
98
|
repository, beside `docs/ux/`: `docs/design/<surface>/director-record.md`, a header
|
|
96
99
|
line `surface_class: <class>` and one `## <Field>` heading per field. Which fields are
|
|
97
|
-
owed is the brief's `surface_class` ([`
|
|
98
|
-
class*):
|
|
100
|
+
owed is the brief's `surface_class` ([`stage-00-intake.md`](stage-00-intake.md) → *0 — Intake grill — MANDATORY*, the surface-class bullet):
|
|
99
101
|
|
|
100
102
|
| Class | Fields the record owes |
|
|
101
103
|
|---|---|
|
|
@@ -0,0 +1,158 @@
|
|
|
1
|
+
# Stage 0 detail
|
|
2
|
+
|
|
3
|
+
The full gate and freedom level remain in [stages.md](stages.md).
|
|
4
|
+
|
|
5
|
+
## Contents
|
|
6
|
+
|
|
7
|
+
- 0 — Intake grill — MANDATORY
|
|
8
|
+
|
|
9
|
+
## 0 — Intake grill — MANDATORY
|
|
10
|
+
- **Stage 0 is not optional and not skippable.** There is no "small enough task"
|
|
11
|
+
exemption, no "the request was already clear" exemption, no starting stage 1
|
|
12
|
+
"while the operator thinks". The only sanctioned bypass is the
|
|
13
|
+
entry-from-super-ux short-circuit below, and even that still requires a scope
|
|
14
|
+
confirmation and a record of what was adopted vs skipped. A run that reaches
|
|
15
|
+
stage 1 without a committed, operator-confirmed brief is a **failed run** —
|
|
16
|
+
stop and go back.
|
|
17
|
+
- **Entry-from-super-ux short-circuit (check FIRST).** task-pipeline is often
|
|
18
|
+
launched *from* super-ux — its `/ux` action menu offers "execute autonomously
|
|
19
|
+
via the task-pipeline plugin" once the UX chain (and often a
|
|
20
|
+
`docs/ux/plans/…` fix plan) is already built. Before grilling, detect that:
|
|
21
|
+
if `docs/ux/` already holds a validated chain (foundation → flows → screens →
|
|
22
|
+
scenarios) and/or a fresh fix plan, **do not re-run the grill or the stage-3
|
|
23
|
+
UX track from scratch.** Instead: (1) run a quick check — `/ux-lint`
|
|
24
|
+
(`docs/ux/lint.py`) green, chain present, plan (if any) readable; (2) confirm
|
|
25
|
+
the scope with the operator in ONE line; (3) skip to the first stage that
|
|
26
|
+
still has real work (usually stage 4 Plan if a UX fix plan already exists, or
|
|
27
|
+
stage 3 Spec to formalize it). Record what was adopted vs skipped. If the
|
|
28
|
+
check finds drift/gaps, fall back to the normal flow for the missing parts
|
|
29
|
+
only.
|
|
30
|
+
- **What (normal entry):** the operator's one-line task is almost never enough to
|
|
31
|
+
run autonomously. Before anything else, **grill the operator** to expand that
|
|
32
|
+
one line into a complete, unambiguous brief — resolve every decision branch
|
|
33
|
+
up front so stages 1→10 need no further human input beyond the manual gates.
|
|
34
|
+
This is input expansion, not design: turn "make me feature X" into locked
|
|
35
|
+
answers for scope, users, constraints, data, edge cases, done-criteria.
|
|
36
|
+
- **Phase 1 — harvest the knowledge sources FIRST**
|
|
37
|
+
([`knowledge-sources.md`](knowledge-sources.md)). Before the first question:
|
|
38
|
+
query what the project already knows about this task — code, **the code graph**
|
|
39
|
+
when one is built ([`knowledge-graph.md`](knowledge-graph.md): `graphify query` /
|
|
40
|
+
`affected` / `god-nodes` answer *reach*, which is what grep cannot), `CLAUDE.md`,
|
|
41
|
+
`CONTEXT.md`/ADRs, `docs/` + `docs/ux/`, past pipeline briefs and carry-over
|
|
42
|
+
ledgers, **the retro's standing instructions and run stamps** (`<artifacts>/retro.md`,
|
|
43
|
+
read **in full** — ten standing rows and ten stamps, both bounded **by a cap**, and they bind this
|
|
44
|
+
run; stamp each instruction as it fires. Its *Recent log* is **queried** by the
|
|
45
|
+
task's nouns, not read: uncapped narrative inside a binding source is what makes the
|
|
46
|
+
capped part get skimmed, [`retrospective.md`](retrospective.md)), **lessons from other
|
|
47
|
+
projects** (source 7b, [`knowledge-sources.md`](knowledge-sources.md): `scripts/lessons.py
|
|
48
|
+
query` over the local index, then a shared store where the session lists one — each
|
|
49
|
+
layer's state printed in the source ledger), the **knowledge wiki** if one is
|
|
50
|
+
installed
|
|
51
|
+
([obsidian-wiki](https://github.com/ar9av/obsidian-wiki) — recommended,
|
|
52
|
+
never required), and any **other repo or hosted doc system the project names as
|
|
53
|
+
its docs**. Write the **source ledger** into the brief (a row per source, or an
|
|
54
|
+
explicit "none found"; **the graph's row carries its measured lag — commits and
|
|
55
|
+
days behind `HEAD`, the signal that measured it, and `⚠ not trusted for reach
|
|
56
|
+
until refreshed` on anything but `current`**
|
|
57
|
+
([`knowledge-graph.md`](knowledge-graph.md) → *Measure the lag*; a build date is
|
|
58
|
+
the graph's own reply about itself, not a measurement of it). It is retrieval
|
|
59
|
+
scoped by the task's own nouns, not a read of everything — and it is what makes
|
|
60
|
+
phase 2's answers checkable instead of merely confident.
|
|
61
|
+
- **Phase 1b — the documentation inventory**
|
|
62
|
+
([`documentation.md`](documentation.md)). Four questions, answered before the
|
|
63
|
+
interview and written to `docs/DOCMAP.md` (seeded from
|
|
64
|
+
[`../templates/docmap.md`](../templates/docmap.md), **only when absent**): where
|
|
65
|
+
do settled things live, what is each fact's single home, what does a change of
|
|
66
|
+
type X oblige, and what proves it. A project with no answers gets them seeded —
|
|
67
|
+
registers, the matrix and `scripts/check-docs.sh` — and the seeding is itself
|
|
68
|
+
recorded as the register's first entry. **One decision home per project:** an
|
|
69
|
+
existing `docs/adr/` *is* the register and is recorded as such, never duplicated.
|
|
70
|
+
The gate is seeded so that it exits `0` on its own seeds; a project that starts
|
|
71
|
+
red learns on day one that the gate is noise.
|
|
72
|
+
- **Phase 1b+ — offer the entry audit, once** ([`setup.md`](setup.md)). When
|
|
73
|
+
`docs/DOCMAP.md` is absent or its regime line predates the project's last release,
|
|
74
|
+
ask whether to audit the documentation that already exists **before** building on
|
|
75
|
+
it. Record the answer — including a refusal — in the brief's autonomy sweep and
|
|
76
|
+
never ask again. `audit.md`'s ladder runs at the *end* over the change; this runs
|
|
77
|
+
at the *start* over what is already there.
|
|
78
|
+
- **Phase 1c — reconcile intent against as-built.** Git says how it *should* be;
|
|
79
|
+
the run record says how it *turned out*. Read both for the area you are about to
|
|
80
|
+
touch and resolve every divergence — the document is stale, the record is wrong,
|
|
81
|
+
or they genuinely disagree and that is a decision. There is no fourth option, and
|
|
82
|
+
starting on an unresolved divergence means building against a system that does
|
|
83
|
+
not exist.
|
|
84
|
+
- **Phase 1d — the short-path triage: printed, proposed, never taken silently.** This
|
|
85
|
+
pipeline's own boundary exempts a typo, a one-line fix and a mechanical rename — and
|
|
86
|
+
nothing measured that until 2026-08-10, so the exemption depended on an agent
|
|
87
|
+
remembering it while eleven stages and four manual gates stood in front of a
|
|
88
|
+
one-paragraph edit. Three questions, each with something behind it:
|
|
89
|
+
|
|
90
|
+
```
|
|
91
|
+
1. files the request names, resolved git ls-files -- <paths> -> N
|
|
92
|
+
2. any of them a public contract the surfaces the host's release
|
|
93
|
+
syncs, its schema or config
|
|
94
|
+
contracts, a shipped command,
|
|
95
|
+
its README -> yes/no
|
|
96
|
+
3. behaviour a user or a caller observes changes -> yes/no
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
Few files, no contract, no observable change ⇒ **propose** the short path: stages 1,
|
|
100
|
+
2, 3 and 4 marked `⊘` with the triage answer as the reason, and 5→10 running
|
|
101
|
+
unchanged. **Propose, never take.** The answer goes in the brief's autonomy sweep and
|
|
102
|
+
silence takes the full flow — the same floor deploy authorization uses. The glyph is
|
|
103
|
+
what makes it safe: a skipped stage is printed on the rail **with its reason**
|
|
104
|
+
([`progress.md`](progress.md)), and a skip nobody can see is indistinguishable from a
|
|
105
|
+
stage that was never entered.
|
|
106
|
+
- **How it runs: [`grill.md`](grill.md)** — the full doctrine, built into this
|
|
107
|
+
skill (nothing to install). In short: close what the sources can, then ONE batch
|
|
108
|
+
of the material unknowns, ordered by dependency, a recommended answer with each —
|
|
109
|
+
one at a time only where answers depend on each other or the operator asks;
|
|
110
|
+
contradictions reconciled on the spot; **every answer that touches
|
|
111
|
+
a harvested source is checked against it** — the operator outranks any document,
|
|
112
|
+
but only out loud, and the losing side is logged for the stage-9 doc update; plus
|
|
113
|
+
**domain awareness**
|
|
114
|
+
(challenge terms against `CONTEXT.md`, sharpen fuzzy language, stress-test with
|
|
115
|
+
concrete scenarios, cross-reference the code, record ADRs for hard-to-reverse
|
|
116
|
+
calls) and the **autonomy sweep** that pre-resolves every stage-1→10 blocker.
|
|
117
|
+
Deploy authorization has a hard floor there: a standing go counts only when it
|
|
118
|
+
names the target and the preconditions.
|
|
119
|
+
- **The run mode is settled here too** ([`continuity.md`](continuity.md)): does
|
|
120
|
+
the run advance item-by-item with no check-in between items, and on what
|
|
121
|
+
interval? Exactly three sources arm it: `pipeline.json` → `run.loop` (read
|
|
122
|
+
first — a recorded mode is the answer and is not re-asked), the operator's answer
|
|
123
|
+
here, or a standing instruction the host already carries. The ledger names which, once:
|
|
124
|
+
`loop: armed by <source:line>`. **Absent all three, it is off.** It buys pacing, never
|
|
125
|
+
authorization: no loop mode collapses a `manual` gate or an outward act. The
|
|
126
|
+
same file carries the other half of pacing — the context budget, which fires
|
|
127
|
+
only on a harness signal or the operator's word, never on an estimate.
|
|
128
|
+
- **UI early-detect:** one branch of the grill is always "does this touch a
|
|
129
|
+
user-facing surface (web/mobile/CLI/TUI)?". If yes → surface **super-ux**
|
|
130
|
+
now (use it if installed; otherwise give the install line — see SKILL.md
|
|
131
|
+
*Prerequisites*); this arms the stage-3 UX track. **And the same branch records
|
|
132
|
+
the surface's class** — the next bullet.
|
|
133
|
+
- **The surface class.** Every user-facing task's brief carries
|
|
134
|
+
`surface_class: flagship | product | internal | ad`, and the class selects the gate
|
|
135
|
+
profile the visual layer is held to for the rest of the run:
|
|
136
|
+
|
|
137
|
+
| Class | What it is | Director record (stage 3) | Visual half (stages 5–6) | Stage 10 |
|
|
138
|
+
|---|---|---|---|---|
|
|
139
|
+
| `flagship` | the surface a product is judged by — landing, onboarding, paywall, a hero screen | the full record | **gate**: full matrix, pairwise across every axis, the full rubric | approved contact sheet |
|
|
140
|
+
| `product` | an ordinary screen of the product | the short record — Brief, Mode, References, Markers, Open | **gate**: every state and the mandatory pairs; the gate items of the rubric | approved contact sheet |
|
|
141
|
+
| `internal` | an admin panel, an internal tool, a CLI | none owed | recommended; the project linter is the floor | the functional look |
|
|
142
|
+
| `ad` | a creative that runs as an advertisement or a store asset | Brief, Mode, References, Markers, ADA (its rubric profile and safe zones), Open | **gate**: the ad profile and the safe zones | approved contact sheet |
|
|
143
|
+
|
|
144
|
+
Ask it as one question with a recommended answer read off the request — a landing or a
|
|
145
|
+
paywall is `flagship` unless the operator says otherwise — and never leave it to stage
|
|
146
|
+
5: a class decided at build time is decided by whoever wants the build to pass. A
|
|
147
|
+
work-graph node that builds the surface copies the class as `surface_class`, and
|
|
148
|
+
`graph.py certify` then owes the fourth, `visual` reading on `flagship` and `product`
|
|
149
|
+
([`certification.md`](certification.md) → *The fourth reading*).
|
|
150
|
+
- **Artifact:** lock the resolved decisions into a **task brief** committed at
|
|
151
|
+
`<artifacts>/specs/YYYY-MM-DD-<topic>-brief.md` (scope, users/UI verdict and,
|
|
152
|
+
for a user-facing task, `surface_class`, constraints, assumptions, explicitly-deferred items, done-criteria) **plus the
|
|
153
|
+
autonomy sweep's per-stage answers and the model decision**. Seed it from
|
|
154
|
+
the skill's `templates/brief.md` skeleton — but only when absent, never
|
|
155
|
+
overwrite an existing brief. Stages 2–4 build on this brief; stages 5–10 read
|
|
156
|
+
its autonomy section instead of asking. Where the session produced them, also:
|
|
157
|
+
an updated `CONTEXT.md` (terms written as they resolved) and any ADRs under
|
|
158
|
+
`docs/adr/` — see `grill.md` → *Domain awareness*.
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
# Stage 1 detail
|
|
2
|
+
|
|
3
|
+
The full gate and freedom level remain in [stages.md](stages.md).
|
|
4
|
+
|
|
5
|
+
## 1 — Docs study
|
|
6
|
+
- **What:** ground every external library / API / SDK the task touches on the
|
|
7
|
+
*current* docs, before locking any contract.
|
|
8
|
+
- **Invoke:** the `context7` MCP — `context7:resolve-library-id` → `context7:query-docs`,
|
|
9
|
+
scoped by topic or the `context7-docs` skill. Web-search fallback for libs context7
|
|
10
|
+
can't resolve.
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
# Stage 2 detail
|
|
2
|
+
|
|
3
|
+
The full gate and freedom level remain in [stages.md](stages.md).
|
|
4
|
+
|
|
5
|
+
## 2 — Brainstorm + decompose
|
|
6
|
+
- **How it runs: [`brainstorm.md`](brainstorm.md)** — built into this skill. Read
|
|
7
|
+
the brief first (stage 0 already answered scope/constraints/done-criteria), then
|
|
8
|
+
explore the codebase, scope-check for decomposition, the open questions in one
|
|
9
|
+
batch, 2–3 approaches with a recommendation, design presented in sections and
|
|
10
|
+
approved section by section. **Hard gate:** no code, no scaffolding, no implementation
|
|
11
|
+
skill before the operator approves the design — including on "obviously simple"
|
|
12
|
+
tasks.
|
|
13
|
+
- **UI detection (mandatory check):** decide whether the task touches any
|
|
14
|
+
user-facing surface (web, mobile, CLI, TUI — new feature, new screen/command,
|
|
15
|
+
or a change to user-visible behavior). Record the verdict; it arms the UX
|
|
16
|
+
track in stage 3.
|
|
17
|
+
- **Decomposition (platforms only): [`decomposition.md`](decomposition.md).** If
|
|
18
|
+
the brief describes a platform rather than a change — several independent
|
|
19
|
+
capabilities, several surfaces that could ship separately, REQs no single
|
|
20
|
+
deliverable satisfies — cut it into **modules** before any spec is written, and
|
|
21
|
+
commit the module map (`specs/<topic>-modules.md`): what each module delivers,
|
|
22
|
+
the entities it owns, what it depends on, the contracts it exposes, its REQs and
|
|
23
|
+
its status, in build order with the walking skeleton first. Single-module work
|
|
24
|
+
records `single module: <name>` in the design and moves on — a skipped
|
|
25
|
+
decomposition is a decision, never an omission.
|
|
26
|
+
- **Where the queue is a work graph, it is WRITTEN here**
|
|
27
|
+
([`work-graph.md`](work-graph.md)): `.task-pipeline/graph.json`, carrying the frozen REQ
|
|
28
|
+
ids so `serves` resolves, one node per unit of work with its owner, what it touches and
|
|
29
|
+
**the check that will close it**, and an edge per dependency **naming what it hands
|
|
30
|
+
over**. The check is the planner's job and not the verifier's: a node whose completion
|
|
31
|
+
test is decided by whoever happens to close it is a node two closes will disagree about,
|
|
32
|
+
and `validate` refuses one that names none. Then
|
|
33
|
+
`python3 scripts/graph.py validate` — a graph that does not validate is not a queue, and
|
|
34
|
+
`next` refuses to walk one. The reason to prefer it over a prose plan is measured, not
|
|
35
|
+
aesthetic: a 400-node graph and a 4-node graph produce the same 27-byte frontier, so the
|
|
36
|
+
cost of knowing what is next does not grow with the programme.
|
|
37
|
+
- **And the check is what THREE readings will run, not one**
|
|
38
|
+
([`certification.md`](certification.md)). A node is closed by `unit`, `seam` and `product`
|
|
39
|
+
reports, dispatched blind and in parallel, and `certify` refuses the close until all three
|
|
40
|
+
pass. That is a planning fact, not only a verification one: a node whose blast radius nobody
|
|
41
|
+
can name is a node the seam and product tiers cannot scope, so `touches` and `serves` are
|
|
42
|
+
what make the two outer readings possible at all.
|
|
43
|
+
- **The queue exists here, so the loop arms here** ([`continuity.md`](continuity.md) →
|
|
44
|
+
*Part 1a*). Where the loop is armed — `run.loop` with `arm: after-decomposition`, the
|
|
45
|
+
operator's preflight answer, or a standing instruction the host carries (which arms here
|
|
46
|
+
unless it says otherwise) — and the map holds more than one module, arm the mode at the
|
|
47
|
+
close of this stage, cite the source as `loop: armed by <source:line>`, and print one
|
|
48
|
+
line: the mode, and
|
|
49
|
+
either the job id and its cancel command (`interval`) or the delay chosen and why
|
|
50
|
+
(`dynamic`). Arming collapses no gate and authorizes no outward act; it decides only
|
|
51
|
+
that the run does not stop to ask *"shall I take the next one?"*. Single-module work
|
|
52
|
+
arms nothing and says so — a loop with one item is a timer.
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
# Stage 3 detail
|
|
2
|
+
|
|
3
|
+
The full gate and freedom level remain in [stages.md](stages.md).
|
|
4
|
+
|
|
5
|
+
## 3 — Spec — with UX track for user-facing tasks
|
|
6
|
+
- **How it runs: [`spec.md`](spec.md)** — built into this skill: the UX-track order,
|
|
7
|
+
what the spec must lock (types, schemas, signatures, file layout, the **Global
|
|
8
|
+
Constraints** block stages 4–5 depend on), the self-review pass and the operator
|
|
9
|
+
review gate.
|
|
10
|
+
- **UX track (runs FIRST when stage 2 flagged UI; skip entirely otherwise).**
|
|
11
|
+
Apply [the artifact-provider contract](companion-skills.md): super-ux is the
|
|
12
|
+
preferred provider; equivalent artifacts or the inline fallback remain valid.
|
|
13
|
+
Missing or invalid scenario artifacts stop the gate, regardless of provider.
|
|
14
|
+
Record each unavailable check by name as NOT_RUN; do not claim a linter ran.
|
|
15
|
+
The following chain describes the super-ux provider when available. Other
|
|
16
|
+
providers owe the same scenario quality and traces, not these package commands.
|
|
17
|
+
When using super-ux, walk its chain top-down (see its `system-map.md`):
|
|
18
|
+
0. **Destination first, when Figma is on.** The brief already names the team/org
|
|
19
|
+
and the files — **one per surface** (App, Web, ASO: store screenshots, icon and
|
|
20
|
+
logo), never one file for every frame; `docs/ux/foundation.md` → *Design tooling*
|
|
21
|
+
is the canonical record. Confirm each **resolves** before drawing. **Never create a file while a
|
|
22
|
+
recorded one resolves; if it doesn't resolve, stop and ask — never create a
|
|
23
|
+
replacement** (that is the duplicate, and it hides a permissions problem).
|
|
24
|
+
A creation happens at most once, in the named team, and its URL is written to
|
|
25
|
+
the canonical record before the first frame.
|
|
26
|
+
1. `/ux` (the only super-ux entry) — reports which `docs/ux/` layers exist,
|
|
27
|
+
repairs the skeleton, records the Figma on/off choice, recommends the next
|
|
28
|
+
action. Never make the operator pick skills.
|
|
29
|
+
2. `ux-foundation` → `docs/ux/foundation.md` — the **WHY**: personas, Jobs to
|
|
30
|
+
Be Done, **customer journey maps (CJM)**, user stories (Given/When/Then).
|
|
31
|
+
3. `ux-flows` → `docs/ux/flows.md` + `docs/ux/screens.md` — the **HOW + UI
|
|
32
|
+
map**: task analysis, user-flow diagrams (branches, error paths), every
|
|
33
|
+
screen + state with wireframe and (Figma on) a Figma frame link.
|
|
34
|
+
4. `ux-scenarios` → `docs/ux/scenarios.md` — the **WHAT** (source of truth for
|
|
35
|
+
behavior): scenarios validated against the scenario-format contract super-ux
|
|
36
|
+
itself ships (`scenario-format.md` — read its current version there, never
|
|
37
|
+
pin one here) — IDs, statuses, `Traces:` to stories/journey stages/flows,
|
|
38
|
+
edge/error states enumerated.
|
|
39
|
+
5. **Run the super-ux linter** (`/ux-lint` or `python3 docs/ux/lint.py`) — it
|
|
40
|
+
must pass: no drift, no orphans, no broken traces or stale Figma links.
|
|
41
|
+
These skills are **idempotent** — reuse and extend existing `docs/ux/` layers,
|
|
42
|
+
never rebuild from scratch. If the chain already exists and is validated (e.g.
|
|
43
|
+
the task entered from super-ux), just verify (linter green) and embed it into
|
|
44
|
+
the spec; only build the parts that are missing.
|
|
45
|
+
- **COPY track and VISUAL track — a parallel layer after UX, and their
|
|
46
|
+
convergence.** Three tracks, three questions, none substituting for another:
|
|
47
|
+
super-ux decides what the interface must **do**, `copywriting` how it
|
|
48
|
+
**sounds** (every string a product's user will read, against the brand pack),
|
|
49
|
+
`sheleg-design` how it **looks** (tokens, themes, typography, motion). COPY and
|
|
50
|
+
VISUAL are **parallel** — both consume the UX track's scenarios, neither
|
|
51
|
+
consumes the other — and where both ran, **their convergence check is run and
|
|
52
|
+
recorded before the spec is committed**: each can be right alone and the two
|
|
53
|
+
disagree together on one screen. The full doctrine — each track's scope and
|
|
54
|
+
out-of-scope, the refusal sentences, the four contradictions the check
|
|
55
|
+
catches — is [`spec.md`](spec.md) → *The COPY and VISUAL tracks, and their
|
|
56
|
+
convergence*, its one home. **The VISUAL track leaves a trace, not a fact**: a
|
|
57
|
+
director record at `docs/design/<surface>/director-record.md`, whose fields the gate
|
|
58
|
+
reads by the brief's `surface_class` (`python3 scripts/visual_gate.py record <file>
|
|
59
|
+
--class <c>`), and a refusal is that same file saying `Mode: declined` and why.
|
|
60
|
+
- **Spec:** write the approved design to
|
|
61
|
+
`<artifacts>/specs/YYYY-MM-DD-<topic>-design.md` and commit it. Lock all
|
|
62
|
+
shared contracts (types, schemas, signatures, file layout). For UI tasks the
|
|
63
|
+
spec **embeds the UX layer**: links the validated scenario IDs, the flows and
|
|
64
|
+
`SCR-` screens, the CJM stages the feature serves, and the UX
|
|
65
|
+
patterns/principles from super-ux that apply (`best-practices.md`,
|
|
66
|
+
`ux-design-principles.md`, `component-guidelines.md`).
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
# Stage 4 detail
|
|
2
|
+
|
|
3
|
+
The full gate and freedom level remain in [stages.md](stages.md).
|
|
4
|
+
|
|
5
|
+
## 4 — Plan
|
|
6
|
+
- **How it runs: [`planning.md`](planning.md)** — built into this skill →
|
|
7
|
+
`<artifacts>/plans/YYYY-MM-DD-<topic>.md` (same slug as the brief and the
|
|
8
|
+
spec). Zero-context tasks, exact
|
|
9
|
+
paths, complete code in every step, TDD steps with expected output, DoD each,
|
|
10
|
+
dependency graph + parallel groups, non-overlapping file ownership, and the
|
|
11
|
+
Global Constraints block copied verbatim from the spec.
|
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
# Stage 5 detail
|
|
2
|
+
|
|
3
|
+
The full gate and freedom level remain in [stages.md](stages.md).
|
|
4
|
+
|
|
5
|
+
## 5 — Dev
|
|
6
|
+
- **How it runs: [`build.md`](build.md)** — built into this skill: isolate the
|
|
7
|
+
workspace (native worktree tool first, git fallback, baseline tests), keep a
|
|
8
|
+
ledger under `.task-pipeline/build/<plan>/` so a compacted context can resume,
|
|
9
|
+
then one fresh implementer subagent per task with a file-based brief and report,
|
|
10
|
+
a review after every task ([`review.md`](review.md)), and a five-round fix loop
|
|
11
|
+
with an explicit breaker. TDD per task ([`tdd.md`](tdd.md)): failing test →
|
|
12
|
+
watch it fail → minimal impl → watch it pass → commit. Pin subagents to the
|
|
13
|
+
run's confirmed model (`model-tiering.md`). The plan's parallel groups fan out
|
|
14
|
+
**only when all three hold** — the tasks share no `depends:`, their file ownership
|
|
15
|
+
is exclusive per the plan, and each implementer gets its own worktree; otherwise
|
|
16
|
+
sequential. A group that did fan out gets **one convergence check over all its
|
|
17
|
+
reports and diffs together, before the first worktree is integrated**
|
|
18
|
+
([`build.md`](build.md) §4.2a) — a per-task review reads one diff and cannot see a
|
|
19
|
+
contradiction that exists only between two of them.
|
|
20
|
+
- **Web front end? The task's own surface is checked in a browser, not in the diff.**
|
|
21
|
+
Where a browser channel is connected — `playwright` **or** `chrome-devtools`, either
|
|
22
|
+
one, whichever answers first (**how**: [`browser.md`](browser.md); which:
|
|
23
|
+
[`companion-skills.md`](companion-skills.md)): after a
|
|
24
|
+
task that changes a rendered surface, load it, take a snapshot and read the
|
|
25
|
+
console and the network log **before the task is marked DONE** — a component can be
|
|
26
|
+
correct and land under a fixed header, and a review of the diff cannot see that.
|
|
27
|
+
**What the look finds is fixed in this task, or parked with the ruling the GATE below
|
|
28
|
+
requires — never parked silently** — a browser finding filed without a ruling is the
|
|
29
|
+
diff-review verdict wearing a screenshot; the look was worth taking only if it can
|
|
30
|
+
still change the code or is on record as deliberately not doing so. Absent, say the surface was verified by reading
|
|
31
|
+
the diff and treat it as the weaker claim it is. **On a surface whose brief names a
|
|
32
|
+
`surface_class`, the project linter runs here too**, after each task that changes a
|
|
33
|
+
rendered surface — `python3 scripts/visual_gate.py lint <dir>`; an S1 finding is
|
|
34
|
+
fixed in the task, and NOT_RUN (exit 3) is recorded as such
|
|
35
|
+
([`browser.md`](browser.md) → *The visual half*). **With Figma on, the token drift
|
|
36
|
+
probe runs beside it** after a task that touches the token file or a tokenised
|
|
37
|
+
component: `python3 scripts/visual_gate.py tokens --figma <variables.json> --css
|
|
38
|
+
<tokens.css>`. A FAIL is fixed in the task, renaming one side to match the other.
|
|
39
|
+
No export is NOT_RUN, recorded as such. A component whose API the task changed
|
|
40
|
+
updates its Code Connect mapping in the same change
|
|
41
|
+
([`build.md`](build.md) → *Code Connect, kept*). A slop marker caught while the
|
|
42
|
+
implementer is dispatched costs a line; caught on the contact sheet it costs a round. Stage 6 repeats this over the whole tree; this one catches it while the
|
|
43
|
+
implementer that wrote it is still dispatched. The matrix pointed this companion at
|
|
44
|
+
stages 5–6 from the day it was added and **this stage had never named it** — found by
|
|
45
|
+
the guard comparing the two, not by a reader.
|
|
46
|
+
- **Domain companions, where the task is on their ground** — recommended, never a
|
|
47
|
+
gate ([`companion-skills.md`](companion-skills.md)): `sheleg-dev` when the build
|
|
48
|
+
wires money, tracking, sign-in or page speed; `agent-stack` when the thing being
|
|
49
|
+
built is an agent system; `telegram-dev` when Telegram is the platform rather
|
|
50
|
+
than the transport. Absent, the build ships on the host's own doctrine and the
|
|
51
|
+
close-out names the seam nobody checked.
|
|
52
|
+
- **Integration closes the stage:** sync with the base branch, re-run the full suite
|
|
53
|
+
on the result, land it the project's way (merge, or a PR — outward, so it needs a
|
|
54
|
+
go), remove the worktree. Stages 7–9 act on the integrated result, so a branch the
|
|
55
|
+
operator chose to leave unmerged is recorded as such.
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
# Stage 6 detail
|
|
2
|
+
|
|
3
|
+
The full gate and freedom level remain in [stages.md](stages.md).
|
|
4
|
+
|
|
5
|
+
## 6 — Tests
|
|
6
|
+
- **What:** consolidate test coverage for the change: confirm new functionality
|
|
7
|
+
has tests (written test-first in stage 5), update/repair existing tests the
|
|
8
|
+
change touched, and add edge-case + failure-path tests per DoD.
|
|
9
|
+
- **Invoke:** the host test runner (see `conventions.md` → *Lint + test*); the
|
|
10
|
+
built-in [`tdd.md`](tdd.md) cycle for any uncovered gap — failing test first,
|
|
11
|
+
same as stage 5.
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# Stage 7 detail
|
|
2
|
+
|
|
3
|
+
The full gate and freedom level remain in [stages.md](stages.md).
|
|
4
|
+
|
|
5
|
+
## 7 — Lint + deploy
|
|
6
|
+
- Read host conventions (`conventions.md`): run the linter; fix failures. The suite
|
|
7
|
+
is already green from stage 6 — re-run it if code changed since. For UI projects,
|
|
8
|
+
the **super-ux linter** (`python3 docs/ux/lint.py` / `/ux-lint`) is part of lint —
|
|
9
|
+
it must pass too (no UX drift merges). Then deploy per the project's convention;
|
|
10
|
+
if the project defines release automation (`pipeline.json` → `release`, toggle
|
|
11
|
+
on), that is what "deploy" runs here. **No runbook, or one too thin to act on?
|
|
12
|
+
Write it first** ([`deploy-targets.md`](deploy-targets.md)) — a deploy performed
|
|
13
|
+
from inference about the project is one nobody can repeat or roll back, and the
|
|
14
|
+
operator is standing at this gate anyway. That reference also carries the CLI
|
|
15
|
+
verbs per target for when the runbook names a platform you have to recall.
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# Stage 8 detail
|
|
2
|
+
|
|
3
|
+
The full gate and freedom level remain in [stages.md](stages.md).
|
|
4
|
+
|
|
5
|
+
## 8 — Post-deploy
|
|
6
|
+
- Tail deploy logs / health-check per conventions. Confirm clean boot, no error
|
|
7
|
+
spike, live subsystems healthy. **All three of the verification trio, not one of
|
|
8
|
+
them** ([`deploy-targets.md`](deploy-targets.md) → *The verification trio*):
|
|
9
|
+
deployment/process state, runtime logs, and a health-check request from outside.
|
|
10
|
+
Where deploy happens in CI, verify the **deploy** job and not only the build —
|
|
11
|
+
a green build beside a skipped deploy is the commonest way a run reports success
|
|
12
|
+
while nothing shipped.
|
|
13
|
+
- **A deployed web target is opened, not curled.** A `200` proves the server
|
|
14
|
+
answered; it says nothing about whether the page rendered, whether a bundle 404'd,
|
|
15
|
+
or whether the console filled with errors on load — all three ship green past a
|
|
16
|
+
health check. Where a browser channel is connected — `playwright` **or**
|
|
17
|
+
`chrome-devtools`, either one ([`browser.md`](browser.md)) — load the deployed URL and read
|
|
18
|
+
the console and the network log; quote what you read, not that you looked
|
|
19
|
+
([`companion-skills.md`](companion-skills.md)). Absent → say the check was an HTTP
|
|
20
|
+
response only, which is the honest name for it.
|
|
21
|
+
- **Read the CI verdict for the deploy's own commit** ([`conventions.md`](conventions.md)
|
|
22
|
+
→ *The CI verdict*): the run's conclusion quoted, the **failing step's log quoted**
|
|
23
|
+
on anything but `success`, and one of the three states stated — including **`no run
|
|
24
|
+
found`**, out loud, because a project without CI is a legitimate state and not a
|
|
25
|
+
green one.
|
|
26
|
+
- **A public surface a logged-out reader will see** can additionally be audited for
|
|
27
|
+
search and answer-engine visibility with `seo-aeo-audit`
|
|
28
|
+
([`companion-skills.md`](companion-skills.md)) — recommended, never a gate;
|
|
29
|
+
absent, visibility ships unaudited and the close-out says so.
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Stage 9 detail
|
|
2
|
+
|
|
3
|
+
The full gate and freedom level remain in [stages.md](stages.md).
|
|
4
|
+
|
|
5
|
+
## 9 — Docs + wiki
|
|
6
|
+
- **The propagation sweep runs first** ([`documentation.md`](documentation.md)).
|
|
7
|
+
The ledger below names the documents you **read**; the matrix in `docs/DOCMAP.md`
|
|
8
|
+
names the documents you **owe**. They are not the same list, and the gap between
|
|
9
|
+
them is where documentation rots — the document nobody read is exactly the
|
|
10
|
+
document nobody updated. Walk the matrix row for **every** change type this run
|
|
11
|
+
produced. Every settled thing gets an id in the register, every answered question
|
|
12
|
+
is flipped to `Resolved→<id>`, and every document named in a
|
|
13
|
+
`Consequences / affects:` line cites its decision.
|
|
14
|
+
- **Then run the documentation gate** (`bash scripts/check-docs.sh`, or whatever
|
|
15
|
+
`docs/DOCMAP.md` → *Gates* names) and print its **ratchet counts** beside the
|
|
16
|
+
verdict, so "green" reads as *"green, and here is exactly what was not looked
|
|
17
|
+
at"* ([`gates.md`](gates.md)). A check that skipped says so.
|
|
18
|
+
- **The stage-0 source ledger is the work list** ([`knowledge-sources.md`](knowledge-sources.md)
|
|
19
|
+
→ *Close the loop*): every source the harvest read gets updated if this run
|
|
20
|
+
changed or disproved it. What was worth reading at stage 0 and is wrong now is
|
|
21
|
+
the next run's false premise.
|
|
22
|
+
- Update host module docs / runbooks per the project's self-update rules, in the
|
|
23
|
+
**same change**. For UI tasks, confirm the super-ux layers were updated in this
|
|
24
|
+
change and the linter is green (super-ux *same-change* + *no-drift* rules).
|
|
25
|
+
- **Sync the knowledge wiki** — `wiki-update` when
|
|
26
|
+
[obsidian-wiki](https://github.com/ar9av/obsidian-wiki) is installed (detect:
|
|
27
|
+
`~/.obsidian-wiki/config`, or the skill resolves). Not installed → recommend it
|
|
28
|
+
once with its install line and continue; a missing wiki never blocks the gate.
|
|
29
|
+
Distil the knowledge (decisions, seams, why), not a diff summary.
|
|
30
|
+
- **Refresh the code graph** — `/graphify . --update` when one exists
|
|
31
|
+
([`knowledge-graph.md`](knowledge-graph.md)). The close-out has **three**
|
|
32
|
+
artifacts, not two: docs, wiki, graph. The graph is the source the *next* run's
|
|
33
|
+
harvest queries first, so a stale one is a false premise carrying the authority of
|
|
34
|
+
a machine — a wrong doc gets argued with, a wrong graph gets believed. Incremental
|
|
35
|
+
and model-free for code; a run that deleted code legitimately rebuilds smaller
|
|
36
|
+
(`--force`).
|
|
37
|
+
- **Then check the graph against the docs** — the cheap half of the divergence sweep
|
|
38
|
+
(`graphify god-nodes`; any doc naming a module the graph no longer has). A hub no
|
|
39
|
+
doc names, or an edge the docs deny, is either a leak in the code or a lie in the
|
|
40
|
+
docs; a doc naming a node that no longer exists is a stale ledger row found
|
|
41
|
+
mechanically. Doc-side findings are fixed here; **absences go to stage 10's ladder
|
|
42
|
+
walk as REQ rows** ([`audit.md`](audit.md)).
|
|
43
|
+
- **Docs living in another repository** are outward: propose the edit, get an
|
|
44
|
+
explicit go, then open a PR there. No go → the exact edit goes in the carry-over
|
|
45
|
+
ledger.
|