@sabaiway/agent-workflow-engine 1.2.0 → 1.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +24 -0
- package/README.md +6 -3
- package/SKILL.md +7 -2
- package/capability.json +1 -1
- package/package.json +1 -1
- package/references/methodology-slot.md +1 -1
- package/references/procedures.md +70 -0
package/CHANGELOG.md
CHANGED
|
@@ -4,6 +4,30 @@ All notable changes to the methodology engine. Versions are this **package's** n
|
|
|
4
4
|
they are distinct from the **deployment-lineage** stamp written into a project's `docs/ai/`
|
|
5
5
|
(which tracks the shared `agent-workflow` lineage, head `1.3.0`).
|
|
6
6
|
|
|
7
|
+
## 1.3.0 — Activity procedures: named, recipe-aware playbooks
|
|
8
|
+
|
|
9
|
+
The engine now also owns the **activity-procedures** canon — *how to perform* a named workflow
|
|
10
|
+
activity, as ordered steps with **typed recipe slots** that bind to the orchestration recipes (Solo /
|
|
11
|
+
Reviewed / Council / Delegated). Two v1 activities: **`plan-authoring`** (slot: `review`) and
|
|
12
|
+
**`plan-execution`** (slots: `execute`, `review`). The canon composes with `planning.md` (it binds to
|
|
13
|
+
the §7 structure, §8 self-review, and §4 Cleanup without restating them) and stays **generic** — it
|
|
14
|
+
bakes in no single project's stages, deferring any project-declared release/publishing to that
|
|
15
|
+
project's `workflow:methodology` slot. The kit reads this canon **live** and surfaces a read-only
|
|
16
|
+
`/agent-workflow-kit procedures <activity>` that renders the steps + the resolved effective recipe per
|
|
17
|
+
slot (from `docs/ai/orchestration.json` + backend readiness).
|
|
18
|
+
|
|
19
|
+
### Added
|
|
20
|
+
- **`references/procedures.md`** — the canonical activity-procedures canon: `plan-authoring` +
|
|
21
|
+
`plan-execution` as `## <activity>` sections, each opening with a machine-parseable `Slots:` line
|
|
22
|
+
(the only line the kit parses, drift-guarded against its activity table). It carries the
|
|
23
|
+
load-bearing "Delegated → dispatch execution first" rule and restates the commit contract as a
|
|
24
|
+
commit-BOUNDARY rule (when an activity has a commit boundary the orchestrator owns that commit; a
|
|
25
|
+
backend never commits — `plan-authoring` ends at approval with no commit, `plan-execution` commits
|
|
26
|
+
per Step).
|
|
27
|
+
|
|
28
|
+
The deployment-lineage head stays **`1.3.0`** (no `docs/ai` structural change; no migration file). The
|
|
29
|
+
npm package version is a separate axis.
|
|
30
|
+
|
|
7
31
|
## 1.2.0 — Orchestration recipes: a named vocabulary for composing the bridges
|
|
8
32
|
|
|
9
33
|
The engine now also owns the **orchestration-recipe** canon — the named patterns an agent uses to
|
package/README.md
CHANGED
|
@@ -50,12 +50,15 @@ the canonical methodology reference on disk:
|
|
|
50
50
|
- [`references/orchestration-slot.md`](references/orchestration-slot.md) — the **bounded** one-line
|
|
51
51
|
orchestration fragment the composition root injects into a deployed `AGENTS.md`, routing to the
|
|
52
52
|
in-project recipes surface.
|
|
53
|
+
- [`references/procedures.md`](references/procedures.md) — the canonical **activity-procedures** canon:
|
|
54
|
+
the named activities (`plan-authoring`, `plan-execution`) as ordered steps with typed recipe slots,
|
|
55
|
+
read live and rendered by the read-only `/agent-workflow-kit procedures <activity>`.
|
|
53
56
|
|
|
54
57
|
## What this package ships
|
|
55
58
|
|
|
56
|
-
`SKILL.md` (the canon overview + ownership rule), `references/` (the full methodology +
|
|
57
|
-
references + the two bounded slot fragments), `capability.json`
|
|
58
|
-
installer. It ships **no** family-wide tooling (the schema/validator/injection live in the
|
|
59
|
+
`SKILL.md` (the canon overview + ownership rule), `references/` (the full methodology + the
|
|
60
|
+
orchestration + activity-procedures references + the two bounded slot fragments), `capability.json`
|
|
61
|
+
(the family manifest), and this installer. It ships **no** family-wide tooling (the schema/validator/injection live in the
|
|
59
62
|
composition root) and mutates nothing — preserving "knows nobody".
|
|
60
63
|
|
|
61
64
|
## License
|
package/SKILL.md
CHANGED
|
@@ -1,9 +1,9 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: agent-workflow-engine
|
|
3
|
-
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,
|
|
3
|
+
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.
|
|
4
4
|
disable-model-invocation: true
|
|
5
5
|
metadata:
|
|
6
|
-
version: '1.
|
|
6
|
+
version: '1.3.0'
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
# agent-workflow-engine
|
|
@@ -34,6 +34,11 @@ slot fill is needed but the engine is absent, the kit's reconcile **fails loudly
|
|
|
34
34
|
orchestration fragment the composition root injects into a deployed `AGENTS.md`, between the
|
|
35
35
|
`<!-- workflow:orchestration:start -->` / `<!-- workflow:orchestration:end -->` markers. It names the
|
|
36
36
|
four recipes and routes to `/agent-workflow-kit recipes`, never to this engine-internal reference.
|
|
37
|
+
- [`references/procedures.md`](references/procedures.md) — the canonical **activity-procedures** canon:
|
|
38
|
+
the ordered steps of the named activities (`plan-authoring`, `plan-execution`) with **typed recipe
|
|
39
|
+
slots** that bind to the orchestration recipes, composing with `planning.md` without restating it. It
|
|
40
|
+
stays generic (no project-specific stages baked in). The kit reads it live and renders the steps +
|
|
41
|
+
the resolved effective recipe per slot via the read-only `/agent-workflow-kit procedures <activity>`.
|
|
37
42
|
|
|
38
43
|
## Ownership rule (the engine knows nobody)
|
|
39
44
|
|
package/capability.json
CHANGED
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@sabaiway/agent-workflow-engine",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.3.0",
|
|
4
4
|
"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.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"ai-agents",
|
|
@@ -1 +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.
|
|
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.
|
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
# Activity Procedures
|
|
2
|
+
|
|
3
|
+
Canonical, on-demand reference for **how an orchestrating agent performs a named activity** — the
|
|
4
|
+
ordered steps of a workflow activity with **typed recipe slots** that bind to the
|
|
5
|
+
[orchestration recipes](orchestration.md) (Solo / Reviewed / Council / Delegated). This is the
|
|
6
|
+
*how to perform* source of truth; it composes with — and never restates — the plan structure and
|
|
7
|
+
lifecycle in [`planning.md`](planning.md). The composition root (`agent-workflow-kit`) reads this
|
|
8
|
+
canon LIVE and renders the requested activity's steps + the resolved effective recipe per slot via
|
|
9
|
+
the read-only `/agent-workflow-kit procedures <activity>`; it parses ONLY each section's `Slots:`
|
|
10
|
+
line (drift-guarded against its activity table), never the steps.
|
|
11
|
+
|
|
12
|
+
A **recipe slot** is a point in an activity where a recipe applies: `review` accepts
|
|
13
|
+
`solo | reviewed | council`; `execute` accepts `solo | delegated`. The per-project default lives in
|
|
14
|
+
`docs/ai/orchestration.json` and is resolved against backend readiness by the kit — never decided in
|
|
15
|
+
this canon. Each activity section below begins with a machine-parseable `Slots:` line (the only line
|
|
16
|
+
the kit parses) and then its ordered steps. Terse by design: it points at the canon it binds to, it
|
|
17
|
+
does not restate it.
|
|
18
|
+
|
|
19
|
+
The commit rule holds across every activity: **when an activity has a commit boundary, the
|
|
20
|
+
orchestrator owns that commit; a backend is advisory or delegated, never autonomous, and never
|
|
21
|
+
commits** (see [`orchestration.md`](orchestration.md) §6). Not every activity commits —
|
|
22
|
+
`plan-authoring` ends at **approval** and produces **no** commit (plans are ephemeral, never
|
|
23
|
+
committed); `plan-execution` commits **per Step**. Any project-declared release/publishing or extra
|
|
24
|
+
stages are honored per the project's `workflow:methodology` slot — this generic canon bakes in no
|
|
25
|
+
single project's stages.
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
## plan-authoring
|
|
30
|
+
|
|
31
|
+
Slots: review
|
|
32
|
+
|
|
33
|
+
Produce a self-contained, cold-readable plan, reviewed to the configured depth before approval.
|
|
34
|
+
|
|
35
|
+
1. **Research** — gather the exact files, contracts, and constraints the plan will touch.
|
|
36
|
+
2. **Draft** — write the plan to the document structure defined in [`planning.md`](planning.md) §7,
|
|
37
|
+
with exact paths and commands per Step. Bind to that structure; do not restate it here.
|
|
38
|
+
3. **Self-review** — run the [`planning.md`](planning.md) §8 checklist (exact paths/commands, strict
|
|
39
|
+
vocabulary, every out-of-plan recommendation folded into a Step, `queue.md` updated for a series).
|
|
40
|
+
4. **review {recipe}** — review the draft at the depth the resolved `review` recipe selects: Solo
|
|
41
|
+
(self-review only), Reviewed (one backend reviews), or Council (both backends review, you
|
|
42
|
+
synthesize). The kit resolves the effective recipe from `docs/ai/orchestration.json` + readiness.
|
|
43
|
+
5. **Fold + loop** — fold every finding back into the draft and re-review until the review is clean.
|
|
44
|
+
6. **Present for approval** — surface the finished plan to the user; do not begin execution here.
|
|
45
|
+
|
|
46
|
+
The plan MUST end with the mandatory **Phase: Cleanup** ([`planning.md`](planning.md) §4) — a plan
|
|
47
|
+
without it is not done.
|
|
48
|
+
|
|
49
|
+
## plan-execution
|
|
50
|
+
|
|
51
|
+
Slots: execute, review
|
|
52
|
+
|
|
53
|
+
Execute an approved plan Step by Step; each Step is one logical commit.
|
|
54
|
+
|
|
55
|
+
1. **Per Step, resolve the recipe** — the kit resolves `execute` and `review` for this run from
|
|
56
|
+
`docs/ai/orchestration.json` + readiness (a per-run `--override <slot>=<recipe>` is allowed).
|
|
57
|
+
2. **If `execute` resolved to Delegated, dispatch execution FIRST** — hand the bounded sub-task to the
|
|
58
|
+
backend (codex-exec → a diff) *before* integrating; otherwise the orchestrator implements the Step
|
|
59
|
+
directly.
|
|
60
|
+
3. **Implement / integrate** — apply the change (your own edits, or the reviewed delegated diff),
|
|
61
|
+
following the project's reuse + clean-code rules.
|
|
62
|
+
4. **Self-review** — run the [`planning.md`](planning.md) §8 self-review on the change.
|
|
63
|
+
5. **review {recipe}** — review the result at the resolved `review` depth (Solo / Reviewed / Council),
|
|
64
|
+
exactly as in plan-authoring.
|
|
65
|
+
6. **Gates** — run the project's verification gate (tests + checks) to green before committing.
|
|
66
|
+
7. **Commit boundary** — the orchestrator makes the single commit for the Step; a backend never
|
|
67
|
+
commits. The project's commit-approval policy (e.g. ask first) lives in the project's own rules.
|
|
68
|
+
|
|
69
|
+
Honor any project-declared release/publishing or extra stages (per the `workflow:methodology` slot)
|
|
70
|
+
before the plan's Cleanup — this generic canon does not enumerate them.
|