@sabaiway/agent-workflow-engine 1.10.0 → 1.12.0

package/CHANGELOG.md

@@ -4,6 +4,41 @@ All notable changes to the methodology engine. Versions are this **package's** n
 they are distinct from the **deployment-lineage** stamp written into a project's `docs/ai/`
 (which tracks the shared `agent-workflow` lineage, head `1.3.0`).
 
+## 1.12.0 — Plans carry a home for review-settled decisions (§7 optional `## Decisions (locked)`)
+
+A **feature** release (canon text + its tests; installer unchanged; deployment-lineage head stays
+`1.3.0` — no migration). Decisions a plan's review loop SETTLED (fixtures, contracts, boundary
+clauses) now have a canonical, machine-extractable home:
+
+- **`references/planning.md` §7** — the plan-document structure gains one optional row after
+  `## Approach`: `## Decisions (locked) ← optional: settled, binding decisions the executor must
+  not re-litigate`. The heading string is load-bearing: the kit's grounded-review facts assembler
+  (`grounding.mjs`, AD-038) extracts the section by exact-heading match.
+- **`references/planning.md` §8** — one checklist bullet: decisions the review loop settled live
+  under the optional `## Decisions (locked)` heading — binding for the executor, never re-litigated
+  at Execute.
+- **`test/planning-canon.test.mjs`** — pins the exact §7 row (heading + optional + executor-binding
+  wording, positioned after `## Approach`) and the §8 mention.
+
+## 1.11.0 — Plans carry only checked syntax (the §9 checked-vs-unchecked boundary)
+
+A **feature** release (canon text + its tests; installer unchanged). The §9 "No code-mechanics in
+the plan" rule now names a hard discriminator for what syntax plan prose may carry:
+
+- **`references/planning.md` §9 (B5)** — **checked syntax**: a Step's exact paths + commands stay
+  REQUIRED (§7/§8) and count as checked because the plan's own Verification runs them against an
+  explicit expected outcome or gate — merely running without asserting checks nothing; the only
+  other syntax a plan may carry is a literal fixture/schema fragment a named test copies or
+  validates. **Un-run, logic-bearing syntax** — control-flow, a regex, a glob, a grammar, an
+  algorithm body, a mini-DSL, anything that transforms data or evaluates a condition — never lives
+  in plan prose, however plausible or shell-verified it looks ("I ran it in my shell" is not a
+  checker): a fold or draft that wants one writes the red→green test-as-spec at Execute instead.
+- **`references/procedures.md` plan-authoring step 5** — the terse mirror of the same boundary at
+  the point of use (the kit advisor prints this section verbatim).
+- **Lockstep tests** — `planning-canon.test.mjs` (§9 it-block) and `procedures-canon.test.mjs`
+  (Set-1) pin the two new tokens `checked syntax` + `logic-bearing`; non-vacuity proven by an
+  injected red→green in both guards.
+
 ## 1.10.0 — Cost-lane vocabulary in the orchestration canon (§5)
 
 A **feature** release (canon text + its tests; installer unchanged). Work now has named **cost

package/SKILL.md

@@ -3,7 +3,7 @@ name: agent-workflow-engine
 description: Canonical home of the agent-workflow planning methodology — the Plan→Phase→Step→Substep vocabulary, plan lifecycle, queue.md series index, mandatory Cleanup phase, the bounded methodology slot fragment, the orchestration-recipe vocabulary (Solo / Reviewed / Council / Delegated), and the activity-procedures canon (plan-authoring / plan-execution, with typed recipe slots). A published, installable npm package (available:true) that *provides* the methodology text; it mutates nothing. The composition root (agent-workflow-kit) reads this canon LIVE from the installed engine and injects the bounded slots from it — one source of truth, no bundled mirror; `npx @sabaiway/agent-workflow-kit@latest init` installs the engine.
 disable-model-invocation: true
 metadata:
-  version: '1.10.0'
+  version: '1.12.0'
 ---
 
 # agent-workflow-engine

package/capability.json

@@ -3,7 +3,7 @@
   "schema": 1,
   "name": "agent-workflow-engine",
   "kind": "methodology-engine",
-  "version": "1.10.0",
+  "version": "1.12.0",
   "available": true,
   "provides": ["plan"],
   "roles": {},

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sabaiway/agent-workflow-engine",
-  "version": "1.10.0",
+  "version": "1.12.0",
   "description": "Canonical home of the agent-workflow planning methodology — the Plan→Phase→Step vocabulary, plan lifecycle, queue.md series index, and mandatory Cleanup phase, consumed by the kit (composition root). The methodology engine of the agent-workflow family.",
   "keywords": [
     "ai-agents",

package/references/planning.md

@@ -89,6 +89,7 @@ A harness "approved — you can now start coding" prompt (e.g. Claude Code's **E
 
 ## Context              ← why this Plan exists, current state, why now (reads cold)
 ## Approach             ← chosen design + an explicit "What we are NOT doing"
+## Decisions (locked)   ← optional: settled, binding decisions the executor must not re-litigate
 ## Phase 1: <name>
    ### 1.1. <step>      ← exact paths + commands
 ## Phase 2: <name>
@@ -108,6 +109,7 @@ A harness "approved — you can now start coding" prompt (e.g. Claude Code's **E
 - If part of a series: `queue.md` is initialised / updated (§3).
 - No `git add <plan>` and no "commit the plan" wording in the final report.
 - Every code-touching decision cites the `file:line` it is grounded in; the plan stays at intent / invariant / acceptance altitude, leaving fine code-mechanics to Execute (§9).
+- Decisions the review loop SETTLED (fixtures, contracts, boundary clauses) live under the optional `## Decisions (locked)` heading (§7) — binding for the executor, never re-litigated at Execute.
 
 ## 9. Right-altitude & code-grounded folds
 
@@ -115,7 +117,7 @@ These disciplines keep a plan converging instead of churning, and keep a fold or
 
 **Right altitude.** A plan pins *intent + architecture + invariants + acceptance criteria* — the named tests that must stay green and the new tests that must pass. It does NOT spell out fine code-mechanics in prose: those are resolved in code at Execute (against the real files + the per-Step review + the gates), where prose cannot diverge from reality. Most "blockers" that resurface across review rounds are code-level details that never belonged in a prose plan.
 
-**No code-mechanics in the plan.** A Step still carries its exact paths + commands (§7, §8); the ceiling is on *fold-bred* detail — a review fold must not push fine code-mechanics (`cd`, an env default, a flag) into prose, where they diverge from reality. A fold that needs a mechanic is the trigger to write the test (test-as-spec) instead.
+**No code-mechanics in the plan.** A Step still carries its exact paths + commands (§7, §8) — checked syntax: the plan's own Verification runs them against an explicit expected outcome or gate, and merely running without asserting checks nothing; the only other syntax a plan may carry is a literal fixture/schema fragment a named test copies or validates. Un-run, logic-bearing syntax — control-flow, a regex, a glob, a grammar, an algorithm body, a mini-DSL, anything that transforms data or evaluates a condition — never lives in plan prose, however plausible or shell-verified it looks ("I ran it in my shell" is not a checker): a fold or draft that wants one is the trigger to write the red→green test-as-spec at Execute instead.
 
 **Fold by code, not prose.** Before folding any code-touching finding into the plan, READ the cited `file:line`; the fold cites it. A fold grounded in prose alone drifts from the code and seeds the next bug.
 

package/references/procedures.md

@@ -57,8 +57,10 @@ Produce a self-contained, cold-readable plan, reviewed to the configured depth b
    **0 blockers + 0 majors** from every backend the recipe names (the convergence bar,
    [`planning.md`](planning.md) §9); folding ≠ convergence — re-review after folding. Fold a
    code-touching finding **test-as-spec** (a named acceptance test, not a prose paragraph); a fold must
-   add **no code-mechanics** to the plan — a Step still carries its own exact paths + commands, but a
-   fold needing a mechanic is the trigger to name the test instead. Council runs every named backend
+   add **no code-mechanics** to the plan — a Step still carries its own exact paths + commands
+   (checked syntax: its Verification asserts an expected outcome), but un-run, logic-bearing syntax
+   (control-flow, a regex, a glob, a mini-DSL) never enters plan prose — a fold needing one is the
+   trigger to name the test instead. Council runs every named backend
    **every round** (recipe fidelity,
    [`orchestration.md`](orchestration.md) §4) — never quietly drop a ready backend. Cap architecture
    plan-review at **≤2 rounds**, stopping at the **crossover** where **backend divergence** (one backend