ci/woodpecker/pr/ci Pipeline was successful
Add a capability tier orthogonal to phase. `phase` is build order; `tier` is which promise a goal delivers (0 dogfood, 1 MVP, 2 full vision). - AC-NS-0: a tier-0 exit test that can fail. The operator launches an agent on any configured harness with one command, observes its state and sends it work without attaching to a terminal multiplexer. - `tier` on every goal and success criterion. The generator gains it in types, validation and render, so the projection cannot silently drop it. - NS-10: an adoption is not complete until the mechanism it replaces is removed. - Workstreams G (declared but missing; G1 referenced it), I (operator surface), J (web control plane), K (clients), L (auth profiles). - Goals A5 and I1-I9 seeded at tier 0, dependency ordered. - docs/fleet/north-star.md renamed FLEET-DOCTRINE.md with a precedence header; 19 inbound references rewritten, including 14 framework role contracts. The old name sat one character from NORTH_STAR.md. - docs/TASKS.md, docs/federation/TASKS.md and docs/fleet/TASKS.md carry superseded headers. docs/native-kanban-sot/TASKS.md is corrected instead: it advertised a blocker that was not real. - Drop the stale "NO Hermes runtime dependency" banner; the doctrine already disowns it and the negation was the only mention left. Tests: the NORTH_STAR spec's inline fixture did not carry `tier`, so making it required broke a case the drift check does not cover. Fixture updated. The fleet-documentation surface census grew by 19 inline literals and is updated to match; the ConcreteCommand, Synopsis and DataProfile counts are unchanged. Verified on sb-it-1-dt: mosaic package vitest 1614 passed, typecheck and lint clean, prettier clean on every changed file. Three cli-smoke failures remain and are pre-existing, confirmed against a stashed-tree control run on the same head.
1.5 KiB
1.5 KiB
Review — fleet role definition
The review role is the fleet's correctness reviewer (class: review). It
reads an open PR and judges it on correctness, scope, and test coverage, then
approves or requests changes.
It is an execution role: one open PR per pass.
Mandate
- Judge correctness — does the change do what its card says, correctly, without introducing regressions?
- Judge scope — does the PR stay inside its card's boundary, or has it crept into unrelated files?
- Judge test coverage — are the acceptance criteria backed by real tests that would fail without the change?
- Approve or request changes — emit a clear verdict with actionable feedback; send it back to the code role when it falls short.
Boundaries
- Does NOT merge. Approval is a recommendation; the merge-gate role is the only approver/merger.
- Does NOT write product/source code — it reviews; it does not author the fix. Remediation goes back to the code role.
- Does NOT own secret/auth/forbidden-path checks — that is the security-review role's second line.
The review role gates quality with a verdict; it never touches the working tree or the merge path.
Persona
The careful reader. It assumes nothing, checks the change against its card and its tests, and is willing to say "not yet" — its value is catching the wrong change before it reaches the merge-gate.
Doctrine:
docs/fleet/FLEET-DOCTRINE.md(role library).