@gtrabanco/pi-agentic-workflow 0.11.1 → 0.12.0

package/skills/review-plan/references/CHECKS.md

@@ -102,7 +102,10 @@ One row per finding in the receipt's `findings` array: stable `id`, `severity`
 (`info | low | medium | high | critical`), `class` (`product | plan | source |
 environment | runtime`), `claim` with its section/row pointer, `evidenceRefs`
 (≥ 1 — a finding without evidence is a hunch and gets dropped), `verification`,
-`resolution: open` on emission. Material = anything above `info`; a PASS may not
-carry an open or unverified material row. A Product-rooted finding found here
+`resolution: open` on emission. Material = `medium` and above; a `low` row is a
+persisted report-note the stage author resolves without a re-review, and `info`
+is immaterial. Deflating a real defect below the `medium` minimum to unblock a
+pass is itself a finding; a PASS may not carry an open or unverified material
+row. A Product-rooted finding found here
 keeps `class: product`: the class routes the repair, it is not a record of who
 noticed what.

package/skills/review-plan/references/OUTPUT.md

@@ -115,16 +115,17 @@ not authority.
 | Verdict / class | Who acts | What happens next |
 |---|---|---|
 | `PLAN-REVIEW-PASS` | nobody | `/execute-phase <NN>` binds this receipt + exact snapshot digest |
-| `PLAN-REVIEW-FAIL`, `class: plan` | `plan-feature` / `plan-fix` (the author) | one root-caused repair batch → new `artifactRevisionId` → re-review of the new snapshot |
+| `PLAN-REVIEW-FAIL`, `class: plan` | `plan-feature` / `plan-fix` (the author) | one root-caused repair batch → new `artifactRevisionId` → next cycle (default re-review; a recorded wording-only batch skips it) |
 | `PLAN-REVIEW-FAIL`, `class: product` | `design-feature` | repair the Product half → `review-spec` → the Plan receipt is re-derived (`stale-parent`) |
 | `PLAN-REVIEW-FAIL`, `class: source\|environment\|runtime` | its owner, later | record the row, keep it `open`, route it. Do not edit the plan to hide it and do not start `execute-phase` on a plan carrying an open material row |
 
 Repeating this review follows the no-progress and convergence rules in
 `pre-execution-review/references/POLICY.md` §4 — a repeat needs
 a changed snapshot or a named falsifiable question plus a new evidence route, and
-entering a second repair/re-review cycle prints the `CONVERGENCE-ANOMALY` block
-before any further edit. A second cycle never grants PASS and never gets folded
-into `review-change → fold-findings`, which repairs source, not plan authority.
+a second consecutive repair/re-review cycle prints the `CONVERGENCE-ANOMALY`
+block before any further edit; the orchestrator's `stop-review-loop-cap` refuses
+a third and names `design-feature` (a PASS resets the count). A second cycle
+never grants PASS and never folds into `review-change → fold-findings`.
 
 ### Skill-specific turn-contract boxes
 
@@ -157,10 +158,9 @@ On FAIL, name every finding id once, in order, joined with ` + `:
 
 ```
 → Next: /plan-feature <NN-slug> "<instruction>" (or /plan-fix <N> "<instruction>") —
-    one repair batch for F1 + P9 + L4, then /review-plan <NN-slug> re-reviews the new
+    one repair batch for F1 + P9 + L4, then /review-plan <NN-slug> judges the new
     artifact revision
   · class: product → /design-feature <NN-slug> then /review-spec <NN-slug>; the plan
     re-derives afterwards
   · a missing product choice → answer it yourself in the instruction; nothing here chooses
-  · a second cycle about to start → print CONVERGENCE-ANOMALY first, then route to the owner
 ```

package/skills/review-spec/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review-spec
 user-invocable: true
-version: 1.7.1
+version: 1.8.0
 argument-hint: <NN-slug | path/to/SPEC.md>
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT

package/skills/review-spec/references/CHECKS.md

@@ -101,5 +101,8 @@ Each finding is one row of the receipt's `findings` array: stable `id`,
 source | environment | runtime`), `claim` (what is wrong, with the section
 pointer), `evidenceRefs` (≥ 1 — a finding without evidence is a hunch and gets
 dropped), `verification` (`verified | unverified`), `resolution` (`open` on
-emission). Material = anything above `info`; a `PASS` may not carry an open or
+emission). Material = `medium` and above; a `low` row is a persisted report-note
+the stage author resolves without a re-review, and `info` is immaterial.
+Deflating a real defect below the `medium` minimum to unblock a pass is itself a
+finding; a `PASS` may not carry an open or
 unverified material row.

package/skills/review-spec/references/OUTPUT.md

@@ -106,8 +106,8 @@ not authority.
 | Verdict | Who repairs | What happens next |
 |---|---|---|
 | `SPEC-REVIEW-PASS` | nobody | `/plan-feature <NN-slug>` binds this receipt + exact snapshot digest |
-| `SPEC-REVIEW-FAIL` | `design-feature` (the author) | one root-caused repair batch → new revision → re-review of the new snapshot |
-| `NEEDS-DESIGN` | the human, through `design-feature` | dated `## Amendments`/`Product decisions` entry → new revision → re-review |
+| `SPEC-REVIEW-FAIL` | `design-feature` (the author) | one root-caused repair batch → new revision → next cycle (default re-review; a recorded wording-only batch skips it) |
+| `NEEDS-DESIGN` | the human, through `design-feature` | dated `## Amendments`/`Product decisions` entry → new revision → next cycle |
 
 A finding whose `class` is `plan`, `source`, `environment`, or `runtime` does not
 become work here: record it, keep it open, and route it to its owner (`review-plan`
@@ -117,8 +117,11 @@ schedules nothing.
 Repeating this review follows the no-progress and convergence rules in
 `pre-execution-review/references/POLICY.md` §4: a repeat needs a
 changed snapshot or a named falsifiable question plus a new evidence route, and
-entering a second repair/re-review cycle prints `CONVERGENCE-ANOMALY` before any
-further edit. A `design-feature` repair turn re-reads the union of open findings
+a second consecutive repair/re-review cycle prints `CONVERGENCE-ANOMALY` before
+any further edit. A third cycle never starts without explicit user instruction:
+the orchestrator's `stop-review-loop-cap` refusal stops the invocation and names
+`design-feature` as the human route, and a PASS resets the count. A
+`design-feature` repair turn re-reads the union of open findings
 from `planning-findings.md`, not just the newest receipt, so nothing recorded here
 is ever lost between cycles.
 
@@ -150,7 +153,8 @@ On FAIL or NEEDS-DESIGN, name every finding id once, in order, joined with ` + `
 
 ```
 → Next: /design-feature <NN-slug> "<instruction>" — one repair batch for F1 + F2 + F4,
-    then /review-spec <NN-slug> re-reviews the new artifact revision
+    then /review-spec <NN-slug> judges the new artifact revision
+  · a third cycle → explicit user instruction first; the decider refuses it (`stop-review-loop-cap`) and names design-feature
   · a product choice is missing → answer it in the instruction; nothing here chooses for you
   · finding class is plan/source/environment/runtime → route to its owner, do not edit the SPEC
 ```

package/skills/verification-contract/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: verification-contract
 user-invocable: false
-version: 1.2.1
+version: 1.3.0
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >
@@ -88,6 +88,12 @@ a cover-up. The sole legitimate amendment is a **proven mis-encoding of external
 documented semantics of the platform/library/language, cited from authoritative documentation — not a product decision change. Even that surfaces as a
 **finding plus a SPEC amendment**, never a silent edit to go green.
 
+The deterministic backstop for this rule is the feature 60 path-protection
+checkpoint (`path-protection@1` in the turn contract): the Tier 1 gate fails a
+protected-path change with no recorded justification/approval, and the pi guard
+blocks the write before it lands. This manifest is the finish line those
+recorded escapes are checked against.
+
 Prevention rides the research gate (**research-before-encode**): platform
 semantics are verified against authoritative documentation **before a test encodes them**, so **adding stronger tests stays allowed**; **editing expectations never** (except the proven-mis-encoding path above).