@sabaiway/agent-workflow-engine 1.3.0 → 1.4.0

package/CHANGELOG.md

@@ -4,6 +4,26 @@ 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.4.0 — Durable session contracts in the canon: read-at-start, Definition of Done, communication
+
+A **feature** release. The activity-procedures canon (`references/procedures.md`, read **live** by the
+composition root) gains three durable-session contracts, and the two bounded slot fragments gain the
+matching clauses so the composition root's canonical-refresh can push them to existing deployments:
+
+- **Read-at-start.** The canon tells the agent to read the project's standing recipe preference in
+  `docs/ai/orchestration.json` at the start of a planning/execution session (set it with the `set-recipe`
+  writer) — no re-asking what is already configured.
+- **plan-authoring Definition of Done.** A planning session must produce a self-contained plan **and** a
+  cold-start execution prompt for the next session — both **without the user asking**.
+- **Communication contract.** User-facing messages deliver the artifact **inline** (never a bare "see
+  §X" as a substitute), lead with the result, with a large-artifact carve-out.
+- **Slot fragments.** `orchestration-slot.md` gains the read-at-start clause (points at `set-recipe`);
+  `methodology-slot.md` gains the communication clause. Both stay one bounded content line, under the
+  deployed-`AGENTS.md` cap.
+
+Generic as ever — no project release-publishing bake-in. The deployment-lineage head stays **`1.3.0`**
+(stamp-independent reconciles reach the base; the engine **package** version is a separate axis).
+
 ## 1.3.0 — Activity procedures: named, recipe-aware playbooks
 
 The engine now also owns the **activity-procedures** canon — *how to perform* a named workflow

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.3.0'
+  version: '1.4.0'
 ---
 
 # agent-workflow-engine

package/capability.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sabaiway/agent-workflow-engine",
-  "version": "1.3.0",
+  "version": "1.4.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/methodology-slot.md

@@ -1 +1 @@
-> **Workflow methodology** — plan → execute → review. Plans are ephemeral `docs/plans/*.md` (gitignored, **never committed**); every Plan ends with a mandatory **Phase: Cleanup**; series order lives in `docs/plans/queue.md`. Full vocabulary, lifecycle, and the plan-then-execute split live in the project's **planning skill** (it overrides the generic `writing-plans`); summary in `docs/ai/agent_rules.md` §5. Named activities (plan-authoring, plan-execution) have procedures — see `/agent-workflow-kit procedures <activity>` for the steps + resolved recipe.
+> **Workflow methodology** — plan → execute → review. Plans are ephemeral `docs/plans/*.md` (gitignored, **never committed**); every Plan ends with a mandatory **Phase: Cleanup**; series order lives in `docs/plans/queue.md`. Full vocabulary, lifecycle, and the plan-then-execute split live in the project's **planning skill** (it overrides the generic `writing-plans`); summary in `docs/ai/agent_rules.md` §5. Named activities (plan-authoring, plan-execution) have procedures — see `/agent-workflow-kit procedures <activity>` for the steps + resolved recipe. **Communication:** user-facing messages deliver the artifact inline (paste the prompt / diff / command — never "see §X" as a substitute), lead with the result, show exactly what was asked, and never read as mockery (a large artifact: a real summary inline + a link).

package/references/orchestration-slot.md

@@ -1 +1 @@
-> **Orchestration recipes** — compose plan → execute → review with a named recipe: **Solo** (no backend), **Reviewed** (one backend reviews), **Council** (both review, you synthesize), **Delegated** (a backend executes a bounded sub-task); the orchestrator always commits, a backend is never autonomous. Pick + plan one for this environment with `/agent-workflow-kit recipes` (read-only); the deployed how/why lives in your `docs/ai/` workflow docs.
+> **Orchestration recipes** — compose plan → execute → review with a named recipe: **Solo** (no backend), **Reviewed** (one backend reviews), **Council** (both review, you synthesize), **Delegated** (a backend executes a bounded sub-task); the orchestrator always commits, a backend is never autonomous. Pick + plan one for this environment with `/agent-workflow-kit recipes` (read-only); the deployed how/why lives in your `docs/ai/` workflow docs. At the start of a planning/execution session, read your standing recipe preference in `docs/ai/orchestration.json` — set it in plain language with `/agent-workflow-kit set-recipe` (previews first; hand-edit stays supported).

package/references/procedures.md

@@ -24,6 +24,17 @@ committed); `plan-execution` commits **per Step**. Any project-declared release/
 stages are honored per the project's `workflow:methodology` slot — this generic canon bakes in no
 single project's stages.
 
+**Read your preference at session start.** At the start of a planning or execution session, read the
+project's standing recipe preference in `docs/ai/orchestration.json` (set it in plain language with
+`/agent-workflow-kit set-recipe` — it previews then writes; hand-editing the file stays supported); the
+kit resolves it against backend readiness. Do not re-ask each session what is already configured there.
+
+**Communication contract.** Every user-facing message delivers the artifact **inline** — the plan, the
+next-session prompt, the diff, the value asked for — never a bare pointer ("see §X / open the file") as a
+*substitute* for showing it; lead with the result, show exactly what was asked, and never read as
+mockery. For a genuinely large artifact, deliver a real summary or the key excerpt inline **and** link
+the file — never flood, never hide.
+
 ---
 
 ## plan-authoring
@@ -43,6 +54,10 @@ Produce a self-contained, cold-readable plan, reviewed to the configured depth b
 5. **Fold + loop** — fold every finding back into the draft and re-review until the review is clean.
 6. **Present for approval** — surface the finished plan to the user; do not begin execution here.
 
+**Required output (Definition of Done):** a planning session produces a self-contained plan in
+`docs/plans/` **and** a cold-start execution prompt to begin the next session — **both produced without
+the user asking**. A planning session that ends without both is not done.
+
 The plan MUST end with the mandatory **Phase: Cleanup** ([`planning.md`](planning.md) §4) — a plan
 without it is not done.
 
@@ -66,5 +81,7 @@ Execute an approved plan Step by Step; each Step is one logical commit.
 7. **Commit boundary** — the orchestrator makes the single commit for the Step; a backend never
    commits. The project's commit-approval policy (e.g. ask first) lives in the project's own rules.
 
+**Output:** each Step lands as one logical commit with its gates green; the orchestrator owns the commit.
+
 Honor any project-declared release/publishing or extra stages (per the `workflow:methodology` slot)
 before the plan's Cleanup — this generic canon does not enumerate them.