@sabaiway/agent-workflow-engine 1.10.0 → 1.11.0

package/CHANGELOG.md

@@ -4,6 +4,25 @@ 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.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.11.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.11.0",
   "available": true,
   "provides": ["plan"],
   "roles": {},

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sabaiway/agent-workflow-engine",
-  "version": "1.10.0",
+  "version": "1.11.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

@@ -115,7 +115,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