@gtrabanco/pi-agentic-workflow 0.18.4 → 0.19.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/package.json +2 -2
- package/skills/init-workspace/SKILL.md +11 -1
- package/skills/phase-contract/SKILL.md +68 -5
- package/skills/product-audit/SKILL.md +12 -4
- package/skills/review-change/SKILL.md +33 -1
- package/skills/triage-issue/SKILL.md +8 -2
- package/skills/unit-lane/SKILL.md +1 -1
- package/skills/unit-lane/references/PLAN.md +54 -4
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@gtrabanco/pi-agentic-workflow",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.19.0",
|
|
4
4
|
"description": "Pi package: canonical agentic-workflow skills, friendly slash commands, and per-command model routing.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"pi-package",
|
|
@@ -57,7 +57,7 @@
|
|
|
57
57
|
"@earendil-works/pi-tui": "*"
|
|
58
58
|
},
|
|
59
59
|
"dependencies": {
|
|
60
|
-
"@gtrabanco/agentic-workflow": "0.
|
|
60
|
+
"@gtrabanco/agentic-workflow": "0.2.0",
|
|
61
61
|
"@gtrabanco/agentic-workflow-schema": "4.5.0"
|
|
62
62
|
},
|
|
63
63
|
"devDependencies": {
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: init-workspace
|
|
3
3
|
user-invocable: true
|
|
4
|
-
version: 3.
|
|
4
|
+
version: 3.3.0
|
|
5
5
|
argument-hint: <target-dir>
|
|
6
6
|
author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
|
|
7
7
|
license: MIT
|
|
@@ -109,6 +109,16 @@ loads exactly upgrade and skips bootstrap plus portability.
|
|
|
109
109
|
is not listed (markdown/yaml/json are never auto-detected), and a listed
|
|
110
110
|
server that fails to start must be removed (one failure disables every
|
|
111
111
|
server in the project). Document verification is a script's job.
|
|
112
|
+
- **Retrieval index scaffold and git hooks are consent-gated (AC22).** The
|
|
113
|
+
index surface — the committed `.agentic-workflow/index.json` config plus the
|
|
114
|
+
three freshness hooks (`post-merge`, `post-checkout`, `post-rewrite`, all
|
|
115
|
+
`index-sync.sh` installed into `.git/hooks/`) — is installed **only after an
|
|
116
|
+
explicit yes** to the question "install the doc retrieval index scaffold and
|
|
117
|
+
its git hooks?". Without consent: install nothing, record it as a residual
|
|
118
|
+
(the entry point still runs and builds its index on first query — the hooks
|
|
119
|
+
are only a freshness fast path), and never write `.git/hooks/` or the config
|
|
120
|
+
on a later visit without a fresh yes. The hooks are best-effort by contract
|
|
121
|
+
(`doc --sync --quiet`, always exit 0 — a fast path never breaks git).
|
|
112
122
|
- **Never redefine the urgency label vocabulary here.** `skills/triage-issue
|
|
113
123
|
/SKILL.md` is the sole owner of the `urgent`/`fix-next` names, colors, and
|
|
114
124
|
apply rules — this skill only seeds those two labels into the repo; it never
|
|
@@ -1,20 +1,22 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: phase-contract
|
|
3
3
|
user-invocable: false
|
|
4
|
-
version: 1.0
|
|
4
|
+
version: 1.1.0
|
|
5
5
|
author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
|
|
6
6
|
license: MIT
|
|
7
7
|
description: >
|
|
8
|
-
Internal contract: the single owner of the eight phase-lint rules, the
|
|
9
|
-
PASS/BLOCKED result, and the normalized
|
|
10
|
-
`execute-phase` and the lane's `plan` step.
|
|
8
|
+
Internal contract: the single owner of the eight phase-lint rules, the two
|
|
9
|
+
accepted phase grammars, the fixed PASS/BLOCKED result, and the normalized
|
|
10
|
+
phase fingerprint. Consumed by `execute-phase` and the lane's `plan` step.
|
|
11
|
+
Not a menu entry.
|
|
11
12
|
---
|
|
12
13
|
|
|
13
14
|
# Phase Contract (internal)
|
|
14
15
|
|
|
15
16
|
The one authoritative owner of phase shape for this workflow. Planners lint
|
|
16
17
|
every phase they emit against the eight rules below; `execute-phase` re-checks
|
|
17
|
-
the same rules before any edit. Nothing else may define what a valid phase is
|
|
18
|
+
the same rules before any edit. Nothing else may define what a valid phase is —
|
|
19
|
+
including which grammar a phase is written in.
|
|
18
20
|
|
|
19
21
|
## When to use
|
|
20
22
|
|
|
@@ -62,18 +64,75 @@ The exemption is scoped to those two boxes: boxes 1, 2, 4, 5, 6 and 8 stay armed
|
|
|
62
64
|
executed phase, and for an unemitted phase every box stays armed, so pre-ticking
|
|
63
65
|
a phase to dodge a check is a defect, never a pass.
|
|
64
66
|
|
|
67
|
+
## The two grammars (fix #272)
|
|
68
|
+
|
|
69
|
+
One contract, two shapes. `scripts/phase-lint.mjs` mechanizes exactly this
|
|
70
|
+
split and never carries a second copy of the semantics:
|
|
71
|
+
|
|
72
|
+
| grammar | where | shape |
|
|
73
|
+
|---|---|---|
|
|
74
|
+
| **plan** | a plan file, or any `##/###/#### P<n> — <Title>` heading | heading + `Layer: <enum>` + `- [ ]` tasks + `Done-when:` |
|
|
75
|
+
| **unit doc** | the unit doc's `## Tasks` section | one `P<n> — <task> (validator: <command> <outcome>)` bullet per phase, wrapped lines joining the bullet, plus an optional nested `- Relevant files: <path, path…>` line |
|
|
76
|
+
|
|
77
|
+
Precedence is fail-closed and one-way: **if a document carries any plan-style
|
|
78
|
+
phase heading, the plan grammar governs it**; only when it carries none does
|
|
79
|
+
the unit-doc grammar apply; a document with no phase in either answers
|
|
80
|
+
`BLOCKED: no-phases`. A `P<n>` bullet outside `## Tasks` (a progress-log line,
|
|
81
|
+
for instance) is prose, never a phase.
|
|
82
|
+
|
|
83
|
+
### Mapping the eight boxes to a bullet phase
|
|
84
|
+
|
|
85
|
+
A bullet has no separate title line and declares no layer, so two boxes have no
|
|
86
|
+
input and are **skipped** (not "passed"); the rest run unchanged over the
|
|
87
|
+
bullet's joined text:
|
|
88
|
+
|
|
89
|
+
| box | unit-doc status |
|
|
90
|
+
|---|---|
|
|
91
|
+
| 1 title names one deliverable | **n/a** — there is no title line; the bullet is the task, and box 4 carries atomicity |
|
|
92
|
+
| 2 one declared layer | **n/a** — a unit doc declares no layer (layers belong to plans) |
|
|
93
|
+
| 3 ≥ 1 task, ≤ 8 tasks | applies — a bullet is exactly one task; a repeated `P<n>` number FAILs as `duplicate unit-doc phase P<n>` |
|
|
94
|
+
| 4 one deliverable | applies — same arrow-chain, >3-case and created-file checks |
|
|
95
|
+
| 5 zero decision words | applies, unchanged |
|
|
96
|
+
| 6 no conditional scope mutation | applies, unchanged |
|
|
97
|
+
| 7 no external/manual gates | applies with the **final-bullet exemption**: the last bullet is the unit doc's verification/close-out line, so `manual` / `ask the user` / `gh pr` are allowed there only |
|
|
98
|
+
| 8 machine-checkable done-when | applies — the bullet's `(validator: …)` span **is** the done-when: it must carry a backticked command *and* an expected outcome; a bullet without the span FAILs as `bullet carries no \`(validator: …)\`` |
|
|
99
|
+
|
|
100
|
+
### The `Relevant files:` sub-section is metadata
|
|
101
|
+
|
|
102
|
+
A nested `- Relevant files: <path, path…>` line under a bullet declares that
|
|
103
|
+
phase's read set (the lane's plan step writes it from its own discovery). It is
|
|
104
|
+
**never** a task: it does not count toward box 3, never feeds a box-2 target and
|
|
105
|
+
is scanned by no rule. Every entry must be a path or a glob; an empty list, an
|
|
106
|
+
empty entry or a token that is neither fails the phase closed under its own
|
|
107
|
+
`relevant-files:` finding id — a malformed read set is reported, never dropped.
|
|
108
|
+
**Never-authority (same rule as every selector):** a file that is *not* listed
|
|
109
|
+
is never out of scope — an executor may always add one, logging it in the unit
|
|
110
|
+
doc's Progress log.
|
|
111
|
+
|
|
65
112
|
## Result — fixed PASS/BLOCKED output
|
|
66
113
|
|
|
67
114
|
```text
|
|
68
115
|
Phase-lint: PASS (8/8)
|
|
69
116
|
```
|
|
70
117
|
|
|
118
|
+
A unit-doc bullet phase reports the boxes it actually runs:
|
|
119
|
+
|
|
120
|
+
```text
|
|
121
|
+
P<n> Phase-lint: PASS (6/6) · fingerprint P<n>:unit-doc:<n-tasks>:<title-deliverable>
|
|
122
|
+
```
|
|
123
|
+
|
|
71
124
|
or, on the first failing box:
|
|
72
125
|
|
|
73
126
|
```text
|
|
74
127
|
Phase-lint: BLOCKED — box <n>: <one-line reason>
|
|
75
128
|
```
|
|
76
129
|
|
|
130
|
+
A malformed `Relevant files:` sub-section reports under its own id:
|
|
131
|
+
|
|
132
|
+
```text
|
|
133
|
+
P<n> relevant-files: <one-line reason>
|
|
134
|
+
```
|
|
135
|
+
|
|
77
136
|
A BLOCKED phase is re-cut or split; it is never emitted, committed, or executed
|
|
78
137
|
as-is (no `--force` bypass exists for a non-atomic phase — that decision belongs
|
|
79
138
|
to the user).
|
|
@@ -85,6 +144,10 @@ Each phase's fingerprint is a deterministic string over the phase's shape:
|
|
|
85
144
|
exact phase version a plan committed to — templates and plans record
|
|
86
145
|
`Phase-lint: PASS (8/8) · fingerprint <fingerprint>` so later re-lints and
|
|
87
146
|
`execute-phase` can confirm nothing in the phase shape drifted since planning.
|
|
147
|
+
A unit-doc bullet phase has no layer, so its slot is the literal `unit-doc`
|
|
148
|
+
(`P<n>:unit-doc:<n-tasks>:<title-deliverable>`, title = the bullet text up to
|
|
149
|
+
its first `:`, with the `(validator: …)` span removed); both grammars hash the
|
|
150
|
+
same way, so a re-lint of either is comparable with its own earlier run.
|
|
88
151
|
|
|
89
152
|
## Guardrails
|
|
90
153
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: product-audit
|
|
3
3
|
user-invocable: true
|
|
4
4
|
disable-model-invocation: true
|
|
5
|
-
version: 3.
|
|
5
|
+
version: 3.4.0
|
|
6
6
|
metadata:
|
|
7
7
|
opencode/autoinvoke: false
|
|
8
8
|
argument-hint: <path-or-area> (optional — defaults to the whole product)
|
|
@@ -10,9 +10,12 @@ author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
|
|
|
10
10
|
license: MIT
|
|
11
11
|
description: >
|
|
12
12
|
Audit the whole product across code, quality, process, docs, roadmap, and
|
|
13
|
-
tooling
|
|
14
|
-
|
|
15
|
-
|
|
13
|
+
tooling; it owns the repo-wide bug hunt, security research, and broken-version
|
|
14
|
+
investigation (scoped and budgeted per dimension, as distinct from
|
|
15
|
+
`review-change`'s change-scoped review). Persist one severity-ranked,
|
|
16
|
+
F-numbered report with proposals; never fix or file work. Triggers:
|
|
17
|
+
"product-audit", "audit the product", "full health check", "are we product-ready",
|
|
18
|
+
"CTO review".
|
|
16
19
|
---
|
|
17
20
|
|
|
18
21
|
# Product Audit
|
|
@@ -38,6 +41,11 @@ first on purpose).
|
|
|
38
41
|
- Periodically (every few features) or at a product-ready milestone.
|
|
39
42
|
- When you want the broad, honest picture — quality, security, debt, docs, and
|
|
40
43
|
roadmap — not the review of a single change (`review-change`) or PR (`audit-pr`).
|
|
44
|
+
- **It owns the repo-wide sweep.** Open-ended, repository-wide bug hunting,
|
|
45
|
+
security research and broken-version investigation land **here** — scoped,
|
|
46
|
+
sampled and budgeted per dimension (state what you sampled). The same hunt
|
|
47
|
+
against one change is `review-change`'s job: neither skill absorbs the other's
|
|
48
|
+
scope.
|
|
41
49
|
|
|
42
50
|
Unlike diff, PR, or docs-only reviews, this skill covers the whole product.
|
|
43
51
|
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: review-change
|
|
3
3
|
user-invocable: true
|
|
4
|
-
version: 3.
|
|
4
|
+
version: 3.10.0
|
|
5
5
|
argument-hint: <path-or-glob> [--adversarial N] [--synthesize]
|
|
6
6
|
author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
|
|
7
7
|
license: MIT
|
|
@@ -68,6 +68,32 @@ mapping candidate evidence.
|
|
|
68
68
|
Default target is the **current change** (branch diff vs the default branch);
|
|
69
69
|
accept a path/glob to widen or narrow. State the scope at the top of the report.
|
|
70
70
|
|
|
71
|
+
## Review charter — dismantle the claim
|
|
72
|
+
|
|
73
|
+
The workflow's job is to demonstrate that what works, works — **and works
|
|
74
|
+
well**: programmatically, engineering-wise, decision-wise, and against user
|
|
75
|
+
expectation. This review exists to **try to dismantle that claim**; if it
|
|
76
|
+
survives the attempt, that survival *is* the review outcome. So:
|
|
77
|
+
|
|
78
|
+
- **In-scope defects are this review's job — never “out of scope”.** A bug, a
|
|
79
|
+
security issue, or a guard skip inside the current feature's scope is a
|
|
80
|
+
`review-change` finding: a feature is not complete while it has one. The
|
|
81
|
+
reward is not delivery, it is meeting the acceptance criteria, adequate
|
|
82
|
+
engineering without over-engineering, meeting **other features' requirements**
|
|
83
|
+
(a page that needs auth verifies the session *and* the permission; a change to
|
|
84
|
+
another table that a requirement depends on stays in scope even if it “looks”
|
|
85
|
+
out of scope), and above all the user's expectation.
|
|
86
|
+
- **Ask, don't infer — the whole expectation surface.** Where the plan, the diff
|
|
87
|
+
or the requirement leaves the user's expectation unclear, surface it as a
|
|
88
|
+
question in non-technical terms (a technical user asks for an app; a
|
|
89
|
+
non-technical user asks for “an app to measure my heart rate”) — never as an
|
|
90
|
+
assumed intent. This extends ask-don't-infer from acceptance criteria to every
|
|
91
|
+
expectation the change is judged against.
|
|
92
|
+
- **Repo-wide hunting is not this review.** Open-ended bug hunting, security
|
|
93
|
+
research and broken-version investigation *across the repository* belong to
|
|
94
|
+
`product-audit`, where the sweep is scoped and budgeted; this review stays on
|
|
95
|
+
the change at hand.
|
|
96
|
+
|
|
71
97
|
## Step 0 — Discover the project & the change (always first)
|
|
72
98
|
|
|
73
99
|
Per Workflow conventions + documentation map, decide axes from:
|
|
@@ -76,6 +102,12 @@ Per Workflow conventions + documentation map, decide axes from:
|
|
|
76
102
|
and optional recorded platform skills (extras only).
|
|
77
103
|
2. **Footprint:** what the diff touches (UI, API, infra, domain). An axis applies
|
|
78
104
|
only when both project and footprint support it.
|
|
105
|
+
3. **Prior findings (optional retrieval aid, never authoritative):** when the
|
|
106
|
+
index entry point exists, `agentic-workflow doc --query "<change topic>"
|
|
107
|
+
--json-only` may surface earlier findings, decisions and session-log entries
|
|
108
|
+
on the same surface before the passes run. A missing index, an absent entry
|
|
109
|
+
point, or an empty answer changes nothing — grep stays the exhaustive
|
|
110
|
+
fallback, and the index is never a decision authority.
|
|
79
111
|
|
|
80
112
|
## Applicability matrix (default; the project's docs refine it)
|
|
81
113
|
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: triage-issue
|
|
3
3
|
user-invocable: true
|
|
4
|
-
version: 2.
|
|
4
|
+
version: 2.10.0
|
|
5
5
|
argument-hint: <issue-number> [more issue numbers…] | <audit-id> F<k> [F<j>…] | --prioritize-now <unit> F<k> [F<j>…]
|
|
6
6
|
author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
|
|
7
7
|
license: MIT
|
|
@@ -57,7 +57,13 @@ first on purpose).
|
|
|
57
57
|
|
|
58
58
|
Per the agent guide's **Workflow conventions** + **documentation map**, then read
|
|
59
59
|
what THIS skill needs: the fix index (e.g. `docs/fix/README.md`) and fix SPEC
|
|
60
|
-
template, and the roadmap.
|
|
60
|
+
template, and the roadmap. **Retrieval aid (optional, never authoritative):**
|
|
61
|
+
when the index entry point exists, run it once before the forge read —
|
|
62
|
+
`agentic-workflow doc --query "<topic terms>" --json-only` — to surface prior
|
|
63
|
+
findings, decisions and session-log entries on this topic. It is a fast path
|
|
64
|
+
over the same corpus grep covers: a missing index, an absent entry point, or an
|
|
65
|
+
empty answer changes nothing (grep stays the exhaustive fallback — AC21), and
|
|
66
|
+
the index is never a decision authority. In review-finding mode, read the target unit's SPEC,
|
|
61
67
|
acceptance, `review-findings.md`, current diff, and PR instead of looking for an
|
|
62
68
|
issue comment. Otherwise read the issue in full, including comments and labels
|
|
63
69
|
(forge CLI per the project's Workflow conventions — examples use `gh`):
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: unit-lane
|
|
3
3
|
user-invocable: true
|
|
4
|
-
version: 1.
|
|
4
|
+
version: 1.2.0
|
|
5
5
|
argument-hint: <NN-slug | "<idea>"> [--retriage] | --fix <issue-number> | --from-issue <issue-number>
|
|
6
6
|
description: >
|
|
7
7
|
One-shot lane conductor for a delivery unit: triage, implement, evidence, and
|
|
@@ -15,24 +15,74 @@ first. No future-phase work.
|
|
|
15
15
|
Fill the unit doc's **Tasks** section:
|
|
16
16
|
|
|
17
17
|
```
|
|
18
|
-
P1 — <task description> (validator: <
|
|
19
|
-
|
|
18
|
+
P1 — <task description> (validator: <backticked command> <expected outcome>)
|
|
19
|
+
- Relevant files: <path, path…>
|
|
20
|
+
P2 — <task description> (validator: <backticked command> <expected outcome>)
|
|
20
21
|
…
|
|
21
22
|
Pn — last task is verification when the unit has behavior
|
|
22
23
|
```
|
|
23
24
|
|
|
25
|
+
Both phase grammars are accepted (owner: `phase-contract`): these bullets, or
|
|
26
|
+
full plan-style `## P<n> —` blocks when the unit doc already carries them —
|
|
27
|
+
`phase-lint` parses either and answers `no-phases` only when it finds neither.
|
|
28
|
+
A bullet's `(validator: …)` span is its machine-checkable done-when (a
|
|
29
|
+
backticked command **and** an expected outcome, e.g. `exits 0`), and the nested
|
|
30
|
+
`Relevant files:` line is **metadata, never a task** — it is that phase's read
|
|
31
|
+
set, written from the planner's own discovery, and a file that is missing from
|
|
32
|
+
it is never out of scope for the executor.
|
|
33
|
+
|
|
34
|
+
## Prior-decisions contradiction sweep
|
|
35
|
+
|
|
36
|
+
Before the plan is accepted, sweep its claims against what the repository has
|
|
37
|
+
**already decided in writing** — a plan must not contradict a prior decision in
|
|
38
|
+
architecture, engineering, product, or any other domain.
|
|
39
|
+
|
|
40
|
+
**Candidate sources** — deterministic keyword/FTS matching, no new index and no
|
|
41
|
+
new tooling: `docs/features/<NN>-<slug>/decisions.md`,
|
|
42
|
+
`docs/fix/<issue>-<topic>/decisions.md`, the project's architectural invariants,
|
|
43
|
+
the Normalized Repository State (`discover-repository-state` /
|
|
44
|
+
`resolve-repository-state`), `AGENTS.md`, and a unit SPEC's `## Design status`
|
|
45
|
+
(legacy marker, units ≤ 60).
|
|
46
|
+
|
|
47
|
+
**Fixed evidence shape** — one row per candidate hit, the decision quoted from
|
|
48
|
+
its source:
|
|
49
|
+
|
|
50
|
+
| claim | prior decision | source path | relation |
|
|
51
|
+
|---|---|---|---|
|
|
52
|
+
| <the plan claim> | <the recorded decision> | <path:line> | `contradicts` \| `compatible` |
|
|
53
|
+
|
|
54
|
+
The cell value is exactly one of two values: `contradicts` or `compatible` —
|
|
55
|
+
a row relation, not a stage verdict.
|
|
56
|
+
|
|
57
|
+
**Advisory only — no new authority.** `contradicts` routes to
|
|
58
|
+
`resolve-repository-state` only when the hit is against a frozen NRS fact
|
|
59
|
+
(its only candidate source that carries a `<contradiction-id>` row after a
|
|
60
|
+
`discover-repository-state` step); hits against
|
|
61
|
+
`decisions.md` / `AGENTS.md` / architectural invariants / `## Design status`
|
|
62
|
+
surface a `NEEDS-DECISION` for the user, per the existing rules. A plan with **no
|
|
63
|
+
candidate match is clean and proceeds** — a miss never blocks it, a missed
|
|
64
|
+
candidate can never void a plan, and the sweep issues no stage verdict and grants no
|
|
65
|
+
gate of its own.
|
|
66
|
+
|
|
24
67
|
## Checklist (pass only if)
|
|
25
68
|
|
|
26
69
|
- [ ] Every AC maps to at least one task
|
|
27
70
|
- [ ] Tasks are ordered smallest first
|
|
28
|
-
- [ ] Each task names its validator (command
|
|
71
|
+
- [ ] Each task names its validator (a backticked command plus its expected outcome)
|
|
29
72
|
- [ ] Final task is verification (proves the whole unit works)
|
|
30
73
|
- [ ] No task reaches into a future-phase concern (docs, release, migrations)
|
|
31
74
|
- [ ] Phases labeled P1, P2, … (never S1, Step 1)
|
|
75
|
+
- [ ] Every plan claim touching architecture, engineering or product intent was
|
|
76
|
+
swept against the candidate sources above
|
|
77
|
+
- [ ] Each candidate hit is one fixed-shape row, with the prior decision cited
|
|
78
|
+
at `path:line` and one of the two relations
|
|
32
79
|
|
|
33
80
|
## Forbidden
|
|
34
81
|
|
|
35
82
|
- Do not bundle across phase boundaries — one phase = one commit
|
|
36
83
|
- Do not plan work beyond the unit's acceptance criteria
|
|
37
84
|
- Do not include docs/release tasks here — those are separate catalog steps
|
|
38
|
-
- Do not invent tasks that the ACs do not demand
|
|
85
|
+
- Do not invent tasks that the ACs do not demand
|
|
86
|
+
- Do not turn the sweep into a gate, stage verdict or blocking check — it routes,
|
|
87
|
+
it never blocks a miss, and it adds no authority
|
|
88
|
+
- Do not record a `prior decision` that no source `path:line` cites
|