@sabaiway/agent-workflow-memory 1.2.2 → 1.4.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 +32 -0
- package/SKILL.md +15 -10
- package/capability.json +1 -1
- package/package.json +1 -1
- package/references/templates/agent_rules.md +12 -0
- package/references/templates/orchestration.json +8 -3
package/CHANGELOG.md
CHANGED
|
@@ -4,6 +4,38 @@ All notable changes to the memory substrate. Versions are this **package's** npm
|
|
|
4
4
|
they are distinct from the **deployment-lineage** stamp written into a project's
|
|
5
5
|
`docs/ai/.memory-version` (which tracks the shared `agent-workflow` lineage, head `1.3.0`).
|
|
6
6
|
|
|
7
|
+
## 1.4.0 — §2.6 right-altitude & code-grounded lens (memory)
|
|
8
|
+
|
|
9
|
+
A **feature** release. The `agent_rules.md` substrate gains a **§2.6 Right-altitude & code-grounded
|
|
10
|
+
(planning + review)** self-review subsection — fold by code (read + cite the `file:line`), pin
|
|
11
|
+
intent/invariants/acceptance, and the convergence heuristic. Wording is **path-neutral** (the substrate
|
|
12
|
+
"knows nobody": it points at "the project's planning methodology / workflow-methodology canon", never a
|
|
13
|
+
sibling/engine path). The deployment-lineage head stays **`1.3.0`** (no `docs/ai` structural change, no
|
|
14
|
+
migration file); the npm package version is a separate axis.
|
|
15
|
+
|
|
16
|
+
- **Seed-or-preserve only (unchanged contract).** A NEW deployment gets the §2.6 lens from the seed;
|
|
17
|
+
refreshing an already-deployed file is the composition root's job.
|
|
18
|
+
- **Template parity preserved** — the §2.6 block body stays byte-identical to the kit fallback template
|
|
19
|
+
(only the heading number differs), pinned by the kit's cross-package `lens-mirror.test.mjs`.
|
|
20
|
+
|
|
21
|
+
## 1.3.0 — Agent-writable config note; §2.5 Communication (memory)
|
|
22
|
+
|
|
23
|
+
A **feature** release. The seeded `docs/ai/orchestration.json` note now frames the config as
|
|
24
|
+
agent-writable (via the `set-recipe` writer) **and** still hand-editable — the old "never written for
|
|
25
|
+
you" wording is gone. The `agent_rules.md` substrate gains a **§2.5 Communication** self-review item
|
|
26
|
+
(deliver the artifact inline; lead with the result; large-artifact carve-out). The deployment-lineage
|
|
27
|
+
head stays **`1.3.0`** (no `docs/ai` structural change, no migration file); the npm package version is a
|
|
28
|
+
separate axis.
|
|
29
|
+
|
|
30
|
+
- **Seed-or-preserve only (unchanged contract).** This substrate still only **seeds** the config from its
|
|
31
|
+
template when missing and **preserves** an existing one byte-for-byte — a NEW deployment gets the updated
|
|
32
|
+
note from the seed. Refreshing the note *in place* on an already-deployed file is the **composition
|
|
33
|
+
root's** job (memory stays standalone and owns no cross-package refresh helper).
|
|
34
|
+
- **Template parity preserved** — the seeded `orchestration.json` stays byte-identical to the composition
|
|
35
|
+
root's fallback copy; the new note is identical across both.
|
|
36
|
+
- **Knows-nobody invariant intact** — the note + SKILL.md refer to the writer generically, never naming a
|
|
37
|
+
specific sibling skill.
|
|
38
|
+
|
|
7
39
|
## 1.2.2 — Strip the package's own tests from the npm tarball (memory)
|
|
8
40
|
|
|
9
41
|
Packaging only — no API/behaviour change; removed the package's own colocated tests from the
|
package/SKILL.md
CHANGED
|
@@ -3,7 +3,7 @@ name: agent-workflow-memory
|
|
|
3
3
|
description: Deploy or upgrade a portable AI-agent memory substrate in any project — an entry-point `AGENTS.md` (+ `CLAUDE.md` alias) and a structured `docs/ai/` context store with cap/archive/index enforcement. Use when the user wants to bootstrap `docs/ai/`, set up the Memory Map and session protocols, install the docs-rotation pre-commit hook, or run `/agent-workflow-memory` / `/agent-workflow-memory upgrade`. Triggers on "set up the memory system", "deploy the AI memory here", "bootstrap docs/ai", "upgrade the memory substrate". This is the substrate only — the workflow methodology (plan→execute→review, queue, Cleanup) is owned elsewhere and injected into AGENTS.md by the family composition root.
|
|
4
4
|
disable-model-invocation: true
|
|
5
5
|
metadata:
|
|
6
|
-
version: '1.
|
|
6
|
+
version: '1.4.0'
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
# agent-workflow-memory
|
|
@@ -47,7 +47,7 @@ What this substrate owns vs what it only points at. The methodology + orchestrat
|
|
|
47
47
|
| Deployment-lineage stamp | **memory** | `docs/ai/.memory-version` |
|
|
48
48
|
| Plan→Phase→Step vocabulary, lifecycle, `queue.md`, mandatory Cleanup | **methodology** (not this skill) | the empty `workflow:methodology` slot — filled by the composition root |
|
|
49
49
|
| Orchestration recipes (Solo / Reviewed / Council / Delegated) | **methodology engine** (not this skill) | the empty `workflow:orchestration` slot — filled by the composition root |
|
|
50
|
-
| Per-project recipe **CONFIG** (which recipe each activity/slot uses) | **memory** seeds an *editable default* | `docs/ai/orchestration.json` (hand-edited; the recipe **canon** + the slot **vocabulary** live in the engine / composition root, never here) |
|
|
50
|
+
| Per-project recipe **CONFIG** (which recipe each activity/slot uses) | **memory** seeds an *editable default* | `docs/ai/orchestration.json` (agent-writable via the composition root's `set-recipe` writer, or hand-edited; the recipe **canon** + the slot **vocabulary** live in the engine / composition root, never here) |
|
|
51
51
|
|
|
52
52
|
---
|
|
53
53
|
|
|
@@ -113,7 +113,8 @@ bootstrapping over a live system, but the user makes the final call.
|
|
|
113
113
|
10. **Stamp the deployment lineage.** Write the **deployment-lineage head** into
|
|
114
114
|
`docs/ai/.memory-version` (one semver line). The lineage head is **`1.3.0`** (the
|
|
115
115
|
`LINEAGE_HEAD` constant in `scripts/stamp-takeover.mjs`) — the shared `agent-workflow`
|
|
116
|
-
lineage, **
|
|
116
|
+
lineage, a **separate axis** from this package's npm version (the two may even coincide by
|
|
117
|
+
accident; see *Stamp = lineage head, not package version*). Use the atomic writer in
|
|
117
118
|
`scripts/stamp-takeover.mjs` (write-temp + rename).
|
|
118
119
|
11. **Report & ask.** Show `tree docs/ai/`, 2–3 lines on filled-vs-TODO, then **ask before
|
|
119
120
|
committing** — never auto-commit. **Exception — delegated mode (below): skip this gate.**
|
|
@@ -163,11 +164,14 @@ Fill strategy:
|
|
|
163
164
|
**behind** the never-downgrade STOP above. **Also stamp-independent (same gate, before the equal-head
|
|
164
165
|
short-circuit): ensure `docs/ai/orchestration.json`** — **create it from
|
|
165
166
|
`${CLAUDE_SKILL_DIR}/references/templates/orchestration.json` if missing**, **preserve it byte-for-byte
|
|
166
|
-
if it already exists** (a user may have edited it; never clobber it).
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
|
|
167
|
+
if it already exists** (a user may have edited it; never clobber it). The shipped template's `_README`
|
|
168
|
+
already frames the config as agent-writable (set it with the `set-recipe` writer) and still
|
|
169
|
+
hand-editable. (Refreshing that note in place on an existing file is the **composition root's** job on
|
|
170
|
+
its own reconcile — this substrate is standalone and only seeds-or-preserves; it owns no cross-package
|
|
171
|
+
refresh helper.) This is why an equal-head (`1.3.0`) deployment still gains the config seed **without a
|
|
172
|
+
lineage-head bump or a migration file** (the stamp-independent-reconcile precedent — like the pointer
|
|
173
|
+
slots + the hidden-mode footprint). **Then**, if the stamp **equals** the head → report "up to date"
|
|
174
|
+
(plus any footprint move / config seed just made) and stop.
|
|
171
175
|
3. Show the relevant `${CLAUDE_SKILL_DIR}/CHANGELOG.md` context (entries newer than the stamp).
|
|
172
176
|
4. Apply `${CLAUDE_SKILL_DIR}/migrations/<version>-<slug>.md` in **semver order**, only those
|
|
173
177
|
newer than the stamp. Migrations are **idempotent**.
|
|
@@ -192,8 +196,9 @@ Fill strategy:
|
|
|
192
196
|
|
|
193
197
|
- **Source vs target directory.** Templates/scripts are read from the skill's own dir; the
|
|
194
198
|
**working directory is the target project** — never write substrate files back into the skill.
|
|
195
|
-
- **Stamp = lineage head, not package version.** `.memory-version` carries
|
|
196
|
-
`agent-workflow` lineage)
|
|
199
|
+
- **Stamp = lineage head, not package version.** `.memory-version` carries the **deployment-lineage
|
|
200
|
+
head** (`1.3.0`, the shared `agent-workflow` lineage) — a **separate axis** from this package's npm
|
|
201
|
+
version (the two may even coincide by accident). They move independently.
|
|
197
202
|
- **Both pointer slots ship empty and stay the user's.** Never author methodology or orchestration
|
|
198
203
|
text into them; on upgrade, preserve their content byte-for-byte. The composition root is their only
|
|
199
204
|
writer.
|
package/capability.json
CHANGED
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@sabaiway/agent-workflow-memory",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.4.0",
|
|
4
4
|
"description": "Portable, cross-agent memory substrate for AI coding agents — an AGENTS.md entry point + docs/ai context with cap/archive/index enforcement, deployable standalone or as part of the agent-workflow family. The memory layer of the agent-workflow family.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"ai-agents",
|
|
@@ -63,6 +63,18 @@ Before proposing changes or committing, review against:
|
|
|
63
63
|
### 2.4. Quality Gates
|
|
64
64
|
- Always run type-checker, linter, and all tests before committing.
|
|
65
65
|
|
|
66
|
+
### 2.5. Communication (user-facing messages)
|
|
67
|
+
Apply this as part of §2 before any user-facing summary:
|
|
68
|
+
- **Deliver the artifact IN the message** — paste the prompt / diff / version / command inline; never "see §X / open the file / run it and you'll see" as a *substitute* for showing what was asked.
|
|
69
|
+
- **Lead with the result**, then the details; show exactly what was asked — no deflection, no "almost done" when the ask was the finished thing.
|
|
70
|
+
- **No condescension, no filler.** Own a miss plainly and fix it in the same message.
|
|
71
|
+
- **Large artifact (≈>100 lines):** deliver a real summary or the key excerpt inline **and** link the file — never flood the reader with a 2000-line paste, never hide the answer behind a bare pointer.
|
|
72
|
+
|
|
73
|
+
### 2.6. Right-altitude & code-grounded (planning + review)
|
|
74
|
+
- **Fold by code, not prose.** Before folding a code-touching finding into a plan or change, read the cited `file:line` and cite it — a prose fold drifts from the code and seeds the next bug.
|
|
75
|
+
- **Right altitude.** Pin intent + invariants + acceptance criteria (named tests); leave fine code-mechanics to Execute, where prose cannot diverge from reality.
|
|
76
|
+
- **Convergence heuristic.** When a review round keeps finding mechanism issues on a stable architecture, stop refining prose — raise the altitude or hand it to Execute. (Full canon: the project's planning methodology / workflow-methodology canon.)
|
|
77
|
+
|
|
66
78
|
---
|
|
67
79
|
|
|
68
80
|
## 3. Token & Session Optimization
|
|
@@ -1,5 +1,10 @@
|
|
|
1
1
|
{
|
|
2
|
-
"_README": "Per-project orchestration config: the recipe used at each step (slot) of each named activity.
|
|
3
|
-
"plan-authoring": {
|
|
4
|
-
|
|
2
|
+
"_README": "Per-project orchestration config: the recipe used at each step (slot) of each named activity. Easiest: tell the agent in plain language and run the `set-recipe` writer — it interprets your intent, previews the change, and writes valid JSON for you. You can still hand-edit this file directly whenever you prefer; that option never goes away. Each activity is configured independently (e.g. plan-authoring, plan-execution), and so is each slot within it. A slot's value is a recipe: a 'review' slot accepts solo | reviewed | council (you self-review / one backend reviews / both review and you synthesize); an 'execute' slot accepts solo | delegated (you implement / a backend runs a bounded sub-task). The default below is 'solo' everywhere — no execution backend required. Raise a slot to reviewed or council for a second opinion, or to delegated to hand off execution; those need an execution backend set up first. Remove a slot's line (or run `set-recipe --unset <activity>.<slot>`) to fall back to the computed default (reviewed when a review backend is ready, otherwise solo). Run the read-only procedures advisor to see an activity's steps plus the recipe resolved for your environment. Strict JSON — no comments.",
|
|
3
|
+
"plan-authoring": {
|
|
4
|
+
"review": "solo"
|
|
5
|
+
},
|
|
6
|
+
"plan-execution": {
|
|
7
|
+
"execute": "solo",
|
|
8
|
+
"review": "solo"
|
|
9
|
+
}
|
|
5
10
|
}
|