coaiajs 0.5.0 → 0.5.2
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/README.md +22 -3
- package/dist/src/cli.d.ts +9 -1
- package/dist/src/cli.d.ts.map +1 -1
- package/dist/src/cli.js +79 -7
- package/dist/src/cli.js.map +1 -1
- package/dist/src/index.d.ts +1 -0
- package/dist/src/index.d.ts.map +1 -1
- package/dist/src/index.js +1 -0
- package/dist/src/index.js.map +1 -1
- package/dist/src/narrative/tool-definitions.d.ts +9 -1
- package/dist/src/narrative/tool-definitions.d.ts.map +1 -1
- package/dist/src/narrative/tool-definitions.js +10 -1
- package/dist/src/narrative/tool-definitions.js.map +1 -1
- package/dist/src/skill.d.ts +98 -0
- package/dist/src/skill.d.ts.map +1 -0
- package/dist/src/skill.js +396 -0
- package/dist/src/skill.js.map +1 -0
- package/dist/src/version.d.ts +9 -0
- package/dist/src/version.d.ts.map +1 -1
- package/dist/src/version.js +30 -14
- package/dist/src/version.js.map +1 -1
- package/docs/LINEAGE-COAIA-NARRATIVE.md +150 -0
- package/llms-full.txt +29 -2
- package/llms.txt +2 -0
- package/package.json +7 -1
- package/skills/coaiajs/SKILL.md +165 -0
- package/skills/coaiajs/references/beyond-narrative.md +71 -0
- package/skills/coaiajs/references/creative-orientation.md +42 -0
- package/skills/coaiajs/references/delayed-resolution.md +48 -0
- package/skills/coaiajs/references/install-and-environment.md +85 -0
- package/skills/coaiajs/references/mcp-tools.md +83 -0
- package/skills/coaiajs/references/narrative-beats.md +44 -0
- package/skills/coaiajs/references/reading-the-store.md +66 -0
- package/skills/coaiajs/references/structural-tension-charting.md +71 -0
- package/skills/coaiajs/references/wampum-belts.md +72 -0
|
@@ -0,0 +1,150 @@
|
|
|
1
|
+
# Lineage: coaia-narrative → coaiajs
|
|
2
|
+
|
|
3
|
+
## What the relationship is
|
|
4
|
+
|
|
5
|
+
`coaiajs` is the package we maintain. `avadisabelle/coaia-narrative` is where several of
|
|
6
|
+
these ideas were first built and several of these bugs were first paid for.
|
|
7
|
+
|
|
8
|
+
That makes this a **one-way port, not a mirror**. We read that repository for corrections
|
|
9
|
+
worth carrying, we decide what shape they take here, and we own the result. Nothing in
|
|
10
|
+
this package is expected to stay byte-identical to anything over there, and a future
|
|
11
|
+
instance should not treat a difference as drift to be undone.
|
|
12
|
+
|
|
13
|
+
The direction never reverses. We do not push changes back, and we do not wait on that
|
|
14
|
+
repository before fixing something here.
|
|
15
|
+
|
|
16
|
+
## Ported through
|
|
17
|
+
|
|
18
|
+
| | |
|
|
19
|
+
|---|---|
|
|
20
|
+
| Upstream repo | `avadisabelle/coaia-narrative` (`git@github.com:avadisabelle/coaia-narrative.git`) |
|
|
21
|
+
| Original snapshot taken at | `12c60f8` (2026-03-08) — landed here as `d6a544e`, 2026-03-11 |
|
|
22
|
+
| **Ported through** | **`68f6e2f`** — merge of PR #55, upstream v0.16.2, 2026-08-11 |
|
|
23
|
+
| Landed here as | `03658fa` (narrative parity) and the commit adding this file |
|
|
24
|
+
| Tracking issue | jgwill/coaiajs#13 |
|
|
25
|
+
|
|
26
|
+
**Update the "Ported through" row in the same commit that lands the next port.** It is the
|
|
27
|
+
only record of where the last one stopped, and a port that does not update it costs the
|
|
28
|
+
next instance the whole diff again.
|
|
29
|
+
|
|
30
|
+
## How to find the next port
|
|
31
|
+
|
|
32
|
+
```bash
|
|
33
|
+
UPSTREAM=/path/to/coaia-narrative # or: git clone git@github.com:avadisabelle/coaia-narrative.git
|
|
34
|
+
PORTED_THROUGH=68f6e2f
|
|
35
|
+
|
|
36
|
+
cd "$UPSTREAM" && git fetch --all
|
|
37
|
+
|
|
38
|
+
# What changed in code since we last looked
|
|
39
|
+
git diff --stat "$PORTED_THROUGH..origin/main" -- '*.ts'
|
|
40
|
+
|
|
41
|
+
# Release-shaped commits carry their reason in the subject line — read these first,
|
|
42
|
+
# they are usually one measured failure each
|
|
43
|
+
git log --oneline "$PORTED_THROUGH..origin/main"
|
|
44
|
+
|
|
45
|
+
# The full text of one change, with its comments, which is where the reasoning lives
|
|
46
|
+
git show <sha>
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
Upstream writes its commit subjects as the failure that was found, not as the change that
|
|
50
|
+
was made ("a --memory-path carrying an unexpanded shell variable is refused"). Read the
|
|
51
|
+
subject lines before the diff — they tell you which changes carry a real finding and which
|
|
52
|
+
are packaging.
|
|
53
|
+
|
|
54
|
+
## How to port
|
|
55
|
+
|
|
56
|
+
The two trees are not diff-compatible. When the March snapshot was taken it was
|
|
57
|
+
reformatted (single quotes, trailing commas, prettier widths), types were moved to
|
|
58
|
+
`src/types.ts`, and `LLM_GUIDANCE` was inlined. `git apply` will not work and should not
|
|
59
|
+
be attempted. Port **semantically**: read the upstream change, understand the finding
|
|
60
|
+
behind it, then write it here in this codebase's shape.
|
|
61
|
+
|
|
62
|
+
Rules that have held so far:
|
|
63
|
+
|
|
64
|
+
1. **Carry the reasoning, not just the code.** Upstream comments name the date, the
|
|
65
|
+
measurement, and the cost of the bug. Those comments are the most valuable part of the
|
|
66
|
+
change — a future reader who does not know why a guard exists will delete it. Rewrite
|
|
67
|
+
them for this package's context rather than dropping them.
|
|
68
|
+
2. **Adapt anything that names the other package.** Binary names, MCP server names,
|
|
69
|
+
environment variables, and example issue references all differ. A copy that still says
|
|
70
|
+
`cnarrative` or `COAIA_TOOLS` is wrong here even if it compiles.
|
|
71
|
+
3. **Put the change where this codebase already puts that kind of thing.** Shared types go
|
|
72
|
+
in `src/types.ts`, not a per-module types file. The memory-path guard belongs in the
|
|
73
|
+
`KnowledgeGraphManager` constructor here, because that covers the CLI, the MCP server,
|
|
74
|
+
and library consumers at once — upstream put it in its single entry point because that
|
|
75
|
+
is all it has.
|
|
76
|
+
4. **Write a test per finding.** `tests/narrative-parity.test.js` is organised as one
|
|
77
|
+
`describe` per finding, named for the behaviour it holds. A ported correction with no
|
|
78
|
+
test is a correction that will be un-ported by the next refactor.
|
|
79
|
+
5. **Update the docs in the same commit.** `test/docs.test.mjs` fails the build when
|
|
80
|
+
`README.md` / `llms.txt` / `llms-full.txt` disagree with the served tool surface, so
|
|
81
|
+
this is enforced, not optional.
|
|
82
|
+
|
|
83
|
+
## What has been adapted rather than copied
|
|
84
|
+
|
|
85
|
+
### The skill (`src/skill.ts`, `skills/coaiajs/`)
|
|
86
|
+
|
|
87
|
+
Upstream ships `cnarrative skill show|install`. We ship `coaia skill show|install|check`.
|
|
88
|
+
Four deliberate differences:
|
|
89
|
+
|
|
90
|
+
| | upstream | here | why |
|
|
91
|
+
|---|---|---|---|
|
|
92
|
+
| Content location | ~250 lines of markdown as a TypeScript string array | real `.md` files under `skills/coaiajs/`, shipped via `files` | a doc change should read as a doc diff, and markdown tooling should be able to see it |
|
|
93
|
+
| Tool map | hand-written table | generated from `ALL_TOOL_DEFINITIONS` at render time | a hand-written map advertises tools the server does not serve the moment one is added |
|
|
94
|
+
| Subject | `coaia-narrative`, `cnarrative`, `COAIA_TOOLS` | `coaiajs`, `coaia`, `coaiajs-mcp`, `COAIAJS_FEATURES` | it has to describe the surface it actually installs next to |
|
|
95
|
+
| Staleness | not detectable | `coaia skill check`, plus `packageVersion` in the installed frontmatter | a skill installed by an older version describes an older surface and nothing else says so |
|
|
96
|
+
|
|
97
|
+
The reference set is also larger, because this package has more surface: `wampum-belts.md`,
|
|
98
|
+
`reading-the-store.md`, and `beyond-narrative.md` (PDE, planning, Langfuse, pipeline) have
|
|
99
|
+
no upstream counterpart.
|
|
100
|
+
|
|
101
|
+
**If upstream changes its skill content, do not copy the change in.** Read what it learned
|
|
102
|
+
and decide whether it applies to our surface. These are two skills describing two packages.
|
|
103
|
+
|
|
104
|
+
### The read contract subpath
|
|
105
|
+
|
|
106
|
+
Upstream publishes `coaia-narrative/contract` because its package root **is** the MCP
|
|
107
|
+
server bootstrap — importing it starts a stdio server, so a renderer must have a separate
|
|
108
|
+
door. Our root is a plain library and has no such hazard. We publish
|
|
109
|
+
`coaiajs/narrative/contract` anyway, because the other reason holds: a renderer should be
|
|
110
|
+
able to pull the store's shape without pulling the whole package.
|
|
111
|
+
|
|
112
|
+
## Deliberately not ported
|
|
113
|
+
|
|
114
|
+
| Upstream | Why not |
|
|
115
|
+
|---|---|
|
|
116
|
+
| `index.ts` / `cli.ts` entry points | We have our own, with a different command surface and argument style |
|
|
117
|
+
| `generated-llm-guidance.ts` | Inlined here as `LLM_GUIDANCE_FULL` / `_QUICK` / `_SAVE_DIRECTIVE` in `src/narrative/tool-handlers.ts` |
|
|
118
|
+
| `src/help.ts`, `src/tool-groups.ts` | Commander provides help; the groups live in `src/narrative/tool-definitions.ts` |
|
|
119
|
+
| `handlers/` (push, issues, ceremony, story-engine) | Webhook event handlers for that repo's deployment, not library capability |
|
|
120
|
+
| `types.ts`'s `Direction = 'EAST' \| 'SOUTH' \| ...` | Unused upstream, and the name is already taken here by the PDE lowercase direction type |
|
|
121
|
+
| `scripts/check-schema-parity.cjs` | Bound to that repo's `schema/` fixtures |
|
|
122
|
+
|
|
123
|
+
Revisit any of these if the reason stops being true. Record the decision here when you do.
|
|
124
|
+
|
|
125
|
+
## Where this package is deliberately ahead or different
|
|
126
|
+
|
|
127
|
+
Do not "correct" these back toward upstream:
|
|
128
|
+
|
|
129
|
+
- **`setDueDate` goes through `updateChartDueDate`.** It used to re-serialise the store by
|
|
130
|
+
hand with `writeFileSync`, which ignored `--memory-path` and dropped unmodelled fields.
|
|
131
|
+
- **The memory-path guard is in the constructor**, so it covers library consumers, not only
|
|
132
|
+
a CLI entry point.
|
|
133
|
+
- **`mcp/server.ts` catches that guard** and exits 1 with a one-line refusal rather than an
|
|
134
|
+
unhandled throw.
|
|
135
|
+
- **`src/version.ts` exports `getPackageRoot()`**, which is how anything shipped beside
|
|
136
|
+
`dist/` (the skill, the Custom GPT specs) is located. Do not reach for `process.cwd()`.
|
|
137
|
+
- **Tool counts in the docs are enforced by `test/docs.test.mjs`.** Upstream has no
|
|
138
|
+
equivalent; do not relax ours to match.
|
|
139
|
+
|
|
140
|
+
## Checklist for the next port
|
|
141
|
+
|
|
142
|
+
- [ ] `git log --oneline <PORTED_THROUGH>..origin/main` in the upstream checkout; read the subjects
|
|
143
|
+
- [ ] `git diff --stat <PORTED_THROUGH>..origin/main -- '*.ts'`
|
|
144
|
+
- [ ] For each change: is it a finding, packaging, or entry-point specific?
|
|
145
|
+
- [ ] Port the findings semantically, carrying their reasoning as comments
|
|
146
|
+
- [ ] One `describe` block per finding in `tests/narrative-parity.test.js`
|
|
147
|
+
- [ ] `npm run build && npm test` — the docs suite will catch a stale tool count
|
|
148
|
+
- [ ] `coaia skill check` after a local install, if the tool surface changed
|
|
149
|
+
- [ ] Update **Ported through** above, and the "not ported" table if a decision changed
|
|
150
|
+
- [ ] Bump the version, publish, and note the upstream range in the commit body
|
package/llms-full.txt
CHANGED
|
@@ -110,9 +110,10 @@ EnvironmentManager, createEnvironment, findEnvironment
|
|
|
110
110
|
|
|
111
111
|
```
|
|
112
112
|
getPackageVersion
|
|
113
|
+
getPackageRoot
|
|
113
114
|
```
|
|
114
115
|
|
|
115
|
-
|
|
116
|
+
`getPackageVersion` returns the resolved version of the installed package, read from `package.json` at runtime. `getPackageRoot` returns the directory holding that `package.json` — the way anything shipped beside `dist/` (the packaged skill under `skills/`, the Custom GPT specs) is located. Do not use `process.cwd()` for that; it is the caller's directory and says nothing about where the package was installed.
|
|
116
117
|
|
|
117
118
|
### `coaiajs/narrative`
|
|
118
119
|
|
|
@@ -174,6 +175,26 @@ const store = parseStore(await readFile('./memory.jsonl', 'utf8'));
|
|
|
174
175
|
const work = getWork(store, 'chart_1757200000000');
|
|
175
176
|
```
|
|
176
177
|
|
|
178
|
+
### `coaiajs/skill`
|
|
179
|
+
|
|
180
|
+
The agent skill this package ships, describing its own surface.
|
|
181
|
+
|
|
182
|
+
```
|
|
183
|
+
SKILL_NAME, SKILL_FILES, getPackagedSkillDir,
|
|
184
|
+
renderSkill, renderSkillFile, renderToolMap,
|
|
185
|
+
showSkill, installSkill, checkSkill, formatSkillCheck,
|
|
186
|
+
getSkillInstallDir, getClaudeSkillLinkPath
|
|
187
|
+
```
|
|
188
|
+
|
|
189
|
+
```bash
|
|
190
|
+
coaia skill show # print the packaged SKILL.md, rendered
|
|
191
|
+
coaia skill install --yes # ./.agents/skills/coaiajs + the .claude/skills symlink
|
|
192
|
+
coaia skill install --global # ~/.agents/skills/coaiajs
|
|
193
|
+
coaia skill check # current / stale / missing; exits non-zero unless current
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
The content lives as real markdown under `skills/coaiajs/` rather than as strings in the TypeScript, so a documentation change reads as a documentation diff. The `{{TOOL_MAP}}` placeholder inside `SKILL.md` is rendered from `ALL_TOOL_DEFINITIONS` — the same array the MCP server registers — so an installed skill cannot advertise a tool the server does not serve. The version it was rendered from is recorded in the installed frontmatter as `packageVersion`, which is what `checkSkill` reads.
|
|
197
|
+
|
|
177
198
|
### `coaiajs/pde`
|
|
178
199
|
|
|
179
200
|
```
|
|
@@ -367,6 +388,7 @@ Global options: `--env <path>` · `-M, --memory-path <path>` · `--json` · `--n
|
|
|
367
388
|
| `p <tag> [text]` | | Process text with a custom tag |
|
|
368
389
|
| `init` | | Create a sample `coaia.json` |
|
|
369
390
|
| `fuse` | | Langfuse operations |
|
|
391
|
+
| `skill` | | The packaged agent skill: show, install, check |
|
|
370
392
|
| `narrative` | `n` | Structural tension chart operations |
|
|
371
393
|
| `pde` | | Prompt Decomposition Engine |
|
|
372
394
|
| `plan` | | Structural tension plan operations |
|
|
@@ -377,7 +399,8 @@ Global options: `--env <path>` · `-M, --memory-path <path>` · `--json` · `--n
|
|
|
377
399
|
Subcommands:
|
|
378
400
|
|
|
379
401
|
- **`fuse`** — `traces`, `prompts`, `datasets`, `sessions`, `scores` (`sc`), `score-configs` (`scc`), `comments`, `media`, `dataset-items`, `projects`
|
|
380
|
-
- **`
|
|
402
|
+
- **`skill`** — `show`, `install` (`--global`, `--yes`, `--force`), `check` (`--global`)
|
|
403
|
+
- **`narrative`** — `list` (`ls`), `view` (`v`), `current` (`cur`), `update` (`up`), `add-action` (`aa`), `add-obs` (`ao`), `complete` (`done`), `export` (`exp`), `export-all`, `stats` (`st`), `progress` (`pg`), `mmot`, `set-date` (`sd`, `--redistribute`), `link-issue`
|
|
381
404
|
- **`pde`** — `import <pdeId>`, `list`, `sessions`, `show <sessionId>`
|
|
382
405
|
- **`plan`** — `parse <planPath>`, `convert <planPath>`, `sync-to-chart <planPath> <chartsPath>`, `sync-to-plan <chartsPath> <planPath>`
|
|
383
406
|
- **`pipeline`** — `list`, `show <name>`, `create <name>`, `init <name>`
|
|
@@ -428,3 +451,7 @@ npm run dev # tsc --watch
|
|
|
428
451
|
Conventions: ESM only, relative imports end in `.js` · `strict: true`, no unjustified `any` · shared types live in `src/types.ts` · clients lazy, each module exports `resetClient()` · no side effects at import time.
|
|
429
452
|
|
|
430
453
|
Per-module RISE specifications live in `rispecs/`, one file per module.
|
|
454
|
+
|
|
455
|
+
### Carrying corrections forward from coaia-narrative
|
|
456
|
+
|
|
457
|
+
`src/narrative/` began as a snapshot of `avadisabelle/coaia-narrative` and still takes corrections from it — one way. `docs/LINEAGE-COAIA-NARRATIVE.md` records where the last port stopped (upstream `68f6e2f`, v0.16.2), how to compute the next diff, what was adapted rather than copied and why, and what is deliberately not ported. Read it before porting anything from that repository. The two trees are not diff-compatible; port semantically and carry the reasoning, not just the code.
|
package/llms.txt
CHANGED
|
@@ -17,6 +17,7 @@ Key facts an agent usually needs first:
|
|
|
17
17
|
- [llms-full.txt](./llms-full.txt): complete API surface — every export, every MCP tool, every CLI command, in one file
|
|
18
18
|
- [CLAUDE.md](./CLAUDE.md): repository conventions for agents working *on* this codebase
|
|
19
19
|
- [KINSHIP.md](./KINSHIP.md): lineage and type provenance from the four origin projects
|
|
20
|
+
- [docs/LINEAGE-COAIA-NARRATIVE.md](./docs/LINEAGE-COAIA-NARRATIVE.md): how corrections are carried forward from `avadisabelle/coaia-narrative` — where the last port stopped, how to find the next one, and what is deliberately not copied
|
|
20
21
|
|
|
21
22
|
## Entry points
|
|
22
23
|
|
|
@@ -32,6 +33,7 @@ Key facts an agent usually needs first:
|
|
|
32
33
|
- `coaiajs/media-upload-proxy`: deployable `openaiFileIdRefs` to Langfuse media upload bridge (`coaiajs-media-proxy` binary)
|
|
33
34
|
- `coaiajs/narrative`: `KnowledgeGraphManager`, structural tension charts, markdown export, Wampum Belt sequencing, GitHub issue linkage, loss-free JSONL round-tripping
|
|
34
35
|
- `coaiajs/narrative/contract`: the store read contract for renderers — zero I/O, tolerant of a bad line
|
|
36
|
+
- `coaiajs/skill`: the packaged agent skill — render, install, and check it (`coaia skill show|install|check`)
|
|
35
37
|
- `coaiajs/pde`: Prompt Decomposition Engine — sessions, STC mapping
|
|
36
38
|
- `coaiajs/planning`: `parsePlan`, `planToSTC`, `syncToChart`, `syncToPlan`
|
|
37
39
|
- `coaiajs/pipeline`: pipeline template engine
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "coaiajs",
|
|
3
|
-
"version": "0.5.
|
|
3
|
+
"version": "0.5.2",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"description": "CoAIA unified TypeScript monorepo — CLI, MCP server, and library consolidating coaia-narrative, coaia-pde, coaia-planning, and coaiapy patterns into one package.",
|
|
6
6
|
"main": "./dist/src/index.js",
|
|
@@ -54,6 +54,10 @@
|
|
|
54
54
|
"types": "./dist/src/narrative/contract.d.ts",
|
|
55
55
|
"import": "./dist/src/narrative/contract.js"
|
|
56
56
|
},
|
|
57
|
+
"./skill": {
|
|
58
|
+
"types": "./dist/src/skill.d.ts",
|
|
59
|
+
"import": "./dist/src/skill.js"
|
|
60
|
+
},
|
|
57
61
|
"./pde": {
|
|
58
62
|
"types": "./dist/src/pde/index.d.ts",
|
|
59
63
|
"import": "./dist/src/pde/index.js"
|
|
@@ -70,6 +74,8 @@
|
|
|
70
74
|
},
|
|
71
75
|
"files": [
|
|
72
76
|
"dist",
|
|
77
|
+
"skills",
|
|
78
|
+
"docs",
|
|
73
79
|
"agents/custom_gpt",
|
|
74
80
|
"rispecs",
|
|
75
81
|
"README.md",
|
|
@@ -0,0 +1,165 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: coaiajs
|
|
3
|
+
description: Create and manage Structural Tension Charts, narrative beats, Wampum Belts, MMOT evaluations, PDE decompositions, action plans, and Langfuse-traced pipelines over a JSONL knowledge graph. Use when working with desired outcomes and current reality, telescoping action steps, creative orientation, chart memory, or the coaia CLI and coaiajs-mcp MCP server.
|
|
4
|
+
license: MIT
|
|
5
|
+
compatibility: Requires the coaiajs package. CLI: coaia. MCP server: coaiajs-mcp.
|
|
6
|
+
metadata:
|
|
7
|
+
author: Guillaume D. Isabelle
|
|
8
|
+
package: coaiajs
|
|
9
|
+
packageVersion: "{{VERSION}}"
|
|
10
|
+
allowed-tools: Bash(coaia:*), Bash(coaiajs-mcp:*)
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# coaiajs
|
|
14
|
+
|
|
15
|
+
`coaiajs` is the structural tension surface of the COAIA family, consolidated into one
|
|
16
|
+
installable unit: a library, a CLI (`coaia`), and an MCP server (`coaiajs-mcp`). Use it when
|
|
17
|
+
an assistant should help create outcomes, hold current reality clearly, track strategic
|
|
18
|
+
secondary choices, archive significant learning, and keep that work traced.
|
|
19
|
+
|
|
20
|
+
The MCP server serves {{TOOL_COUNT}} tools at the default `STANDARD` level, of which
|
|
21
|
+
{{NARRATIVE_TOOL_COUNT}} are the chart and knowledge-graph surface. The rest are Redis and
|
|
22
|
+
Langfuse, prompt decomposition, and planning — all mapped below.
|
|
23
|
+
|
|
24
|
+
Its core data model is the structural tension chart — desired outcome, current reality,
|
|
25
|
+
telescoping action steps — backed by a JSONL knowledge graph. Everything else either feeds
|
|
26
|
+
that model or observes it.
|
|
27
|
+
|
|
28
|
+
## Status
|
|
29
|
+
|
|
30
|
+
!`coaia --version 2>/dev/null || echo "Not installed: npm install -g coaiajs"`
|
|
31
|
+
|
|
32
|
+
## First Principles
|
|
33
|
+
|
|
34
|
+
- Work from creative orientation: ask what result the user wants to create, not what
|
|
35
|
+
problem should disappear.
|
|
36
|
+
- Hold desired outcome and current reality at the same time. Do not collapse the tension
|
|
37
|
+
with "ready to begin" defaults.
|
|
38
|
+
- Treat action steps as strategic secondary choices. They are not a to-do list.
|
|
39
|
+
- Every action step is also a telescoped chart with its own desired outcome and current
|
|
40
|
+
reality.
|
|
41
|
+
- Use narrative beats for significant learning moments, not routine task tracking.
|
|
42
|
+
- Use a Wampum Belt when the sequence is not linear and position carries meaning.
|
|
43
|
+
|
|
44
|
+
## MCP Setup
|
|
45
|
+
|
|
46
|
+
Use the MCP server when the assistant needs write access to chart memory:
|
|
47
|
+
|
|
48
|
+
```json
|
|
49
|
+
{
|
|
50
|
+
"mcpServers": {
|
|
51
|
+
"coaiajs": {
|
|
52
|
+
"command": "npx",
|
|
53
|
+
"args": ["-y", "coaiajs", "coaiajs-mcp", "--memory-path", "/absolute/path/to/memory.jsonl"],
|
|
54
|
+
"env": {
|
|
55
|
+
"COAIAJS_FEATURES": "STANDARD"
|
|
56
|
+
}
|
|
57
|
+
}
|
|
58
|
+
}
|
|
59
|
+
}
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
`--memory-path` must be a real, expanded path. A path still carrying `${VAR}` is refused
|
|
63
|
+
at startup rather than opened — see `references/install-and-environment.md` for why that
|
|
64
|
+
refusal is the kind answer.
|
|
65
|
+
|
|
66
|
+
When a new session connects, call `init_llm_guidance` first: `format: "full"` for first
|
|
67
|
+
use, `format: "quick"` for a refresh.
|
|
68
|
+
|
|
69
|
+
## CLI
|
|
70
|
+
|
|
71
|
+
The CLI is for quick inspection, exports, local chart context, and everything that is
|
|
72
|
+
easier to type than to call.
|
|
73
|
+
|
|
74
|
+
```bash
|
|
75
|
+
coaia narrative list -M ./memory.jsonl
|
|
76
|
+
coaia narrative view <chartId> -M ./memory.jsonl
|
|
77
|
+
coaia narrative export <chartId> --output chart.md -M ./memory.jsonl
|
|
78
|
+
coaia narrative link-issue <chartId> owner/repo#123 -M ./memory.jsonl
|
|
79
|
+
coaia fuse traces list
|
|
80
|
+
coaia tash mykey "value" && coaia fetch mykey
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
{{CLI_MAP}}
|
|
84
|
+
|
|
85
|
+
## Core Workflow
|
|
86
|
+
|
|
87
|
+
1. Read chart state before writing anything:
|
|
88
|
+
|
|
89
|
+
```text
|
|
90
|
+
list_active_charts
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
2. Create a chart only when there is a new primary desired outcome:
|
|
94
|
+
|
|
95
|
+
```json
|
|
96
|
+
{
|
|
97
|
+
"tool": "create_structural_tension_chart",
|
|
98
|
+
"arguments": {
|
|
99
|
+
"desiredOutcome": "A release process that runs the same way every time",
|
|
100
|
+
"currentReality": "Build and publish steps are manual and easy to miss",
|
|
101
|
+
"dueDate": "2027-06-01T00:00:00.000Z",
|
|
102
|
+
"actionSteps": ["Document release checks", "Verify npm package contents"],
|
|
103
|
+
"githubIssue": "jgwill/coaiajs#13"
|
|
104
|
+
}
|
|
105
|
+
}
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
`githubIssue` is optional and takes the FULL `owner/repo#number` path. A bare `#number`
|
|
109
|
+
is refused: charts travel between repositories, and a bare number cites the wrong project
|
|
110
|
+
as soon as the chart is read somewhere else.
|
|
111
|
+
|
|
112
|
+
3. Add or expand action steps with `manage_action_step`:
|
|
113
|
+
|
|
114
|
+
```json
|
|
115
|
+
{
|
|
116
|
+
"tool": "manage_action_step",
|
|
117
|
+
"arguments": {
|
|
118
|
+
"parentReference": "chart_123",
|
|
119
|
+
"actionDescription": "Verify npm package contents",
|
|
120
|
+
"currentReality": "No package dry-run has been inspected for this release"
|
|
121
|
+
}
|
|
122
|
+
}
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
4. Track advancement without pretending completion:
|
|
126
|
+
|
|
127
|
+
```text
|
|
128
|
+
update_action_progress
|
|
129
|
+
update_current_reality
|
|
130
|
+
mark_action_complete
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
5. Move a date with `update_chart_due_date` rather than editing the JSONL by hand. Several
|
|
134
|
+
MCP instances can point at one store with no lock, which is how a hand-edit becomes a
|
|
135
|
+
lost write.
|
|
136
|
+
|
|
137
|
+
6. Use `perform_mmot_evaluation` when output and expected performance diverge, or when a
|
|
138
|
+
chart needs a truth-based review.
|
|
139
|
+
|
|
140
|
+
7. Create a narrative beat when the work produced a significant learning moment across
|
|
141
|
+
engineer-world, ceremony-world, and story-engine-world.
|
|
142
|
+
|
|
143
|
+
## Tool Map
|
|
144
|
+
|
|
145
|
+
Generated from the server's own tool definitions, so it cannot list a tool that is not
|
|
146
|
+
served or omit one that is.
|
|
147
|
+
|
|
148
|
+
{{TOOL_MAP}}
|
|
149
|
+
|
|
150
|
+
Two names appear in both the narrative and PDE groups with different meaning.
|
|
151
|
+
`add_action_step`, `update_action_progress`, `mark_action_complete`, and
|
|
152
|
+
`update_current_reality` target the narrative chart; their `pde_`-prefixed twins target
|
|
153
|
+
the PDE session. Calling the wrong one writes to the wrong store and reports success.
|
|
154
|
+
|
|
155
|
+
## References
|
|
156
|
+
|
|
157
|
+
- `references/creative-orientation.md` — the creation-vs-problem-solving distinction
|
|
158
|
+
- `references/structural-tension-charting.md` — chart and action-step rules
|
|
159
|
+
- `references/delayed-resolution.md` — current reality discipline
|
|
160
|
+
- `references/narrative-beats.md` — story archive usage
|
|
161
|
+
- `references/wampum-belts.md` — non-linear mnemonic sequencing
|
|
162
|
+
- `references/reading-the-store.md` — reading a chart store without re-deriving its shape
|
|
163
|
+
- `references/beyond-narrative.md` — PDE, planning, Langfuse, pipeline
|
|
164
|
+
- `references/mcp-tools.md` — feature levels and environment variables
|
|
165
|
+
- `references/install-and-environment.md` — install, run, and the refusals worth knowing
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
# Beyond Narrative
|
|
2
|
+
|
|
3
|
+
`coaiajs` consolidates four CoAIA sub-projects. The chart engine is the centre, but three
|
|
4
|
+
other surfaces feed it and one observes it.
|
|
5
|
+
|
|
6
|
+
The tools themselves are in SKILL.md's generated Tool Map. This file is what the map cannot
|
|
7
|
+
tell you: when to reach for each surface, and where they overlap dangerously.
|
|
8
|
+
|
|
9
|
+
## PDE — Prompt Decomposition Engine
|
|
10
|
+
|
|
11
|
+
Decomposes a complex prompt into an intent map — primary intent, secondary intents,
|
|
12
|
+
context requirements, expected outputs, and the four directions — then turns that map into
|
|
13
|
+
a chart.
|
|
14
|
+
|
|
15
|
+
Four of its tools carry a `pde_` prefix — `pde_add_action_step`,
|
|
16
|
+
`pde_update_action_progress`, `pde_mark_action_complete`, `pde_update_current_reality` —
|
|
17
|
+
because their unprefixed names belong to the narrative group. `add_action_step` targets the
|
|
18
|
+
narrative chart; `pde_add_action_step` targets the PDE session. Getting this wrong writes
|
|
19
|
+
to the wrong store and reports success.
|
|
20
|
+
|
|
21
|
+
```bash
|
|
22
|
+
coaia pde --help
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
## Planning
|
|
26
|
+
|
|
27
|
+
Parses a structured plan file into structural tension form and keeps it in sync with a
|
|
28
|
+
chart store, in both directions.
|
|
29
|
+
|
|
30
|
+
Choose the sync direction deliberately: `sync_plan_to_chart` treats the plan as
|
|
31
|
+
authoritative, `sync_chart_to_plan` treats the chart as authoritative. Both write.
|
|
32
|
+
|
|
33
|
+
```bash
|
|
34
|
+
coaia plan --help
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## Langfuse
|
|
38
|
+
|
|
39
|
+
Traces, observations, scores, prompts, datasets, comments, and media, over the Langfuse
|
|
40
|
+
REST API. Use it to make the chart work observable rather than to store it — the JSONL
|
|
41
|
+
store remains the record.
|
|
42
|
+
|
|
43
|
+
```bash
|
|
44
|
+
coaia fuse traces list
|
|
45
|
+
coaia fuse trace view <traceId>
|
|
46
|
+
coaia fuse prompts get <name>
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
The `coaia_fuse_*` MCP tools mirror these. Media tools are `FULL`-level only.
|
|
50
|
+
|
|
51
|
+
## Pipeline
|
|
52
|
+
|
|
53
|
+
A Jinja2-style template engine for prompt pipelines, exposed as the `coaia://templates/`
|
|
54
|
+
MCP resources and the `coaia pipeline` commands.
|
|
55
|
+
|
|
56
|
+
```bash
|
|
57
|
+
coaia pipeline list
|
|
58
|
+
coaia pipeline run <name>
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
## Redis shorthand
|
|
62
|
+
|
|
63
|
+
`tash` / `fetch` are the COAIA SET/GET shorthand, used for stashing plan perspectives and
|
|
64
|
+
intermediate content:
|
|
65
|
+
|
|
66
|
+
```bash
|
|
67
|
+
coaia tash mykey "value"
|
|
68
|
+
coaia fetch mykey
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
Prefer the CLI over the MCP tool for these — it is the more reliable path.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
# Creative Orientation
|
|
2
|
+
|
|
3
|
+
Creative orientation focuses on bringing desired results into being. Reactive orientation
|
|
4
|
+
focuses on removing unwanted conditions. `coaiajs` biases toward creation.
|
|
5
|
+
|
|
6
|
+
Ask: "What do you want to create?" Then define current reality in relation to that
|
|
7
|
+
desired outcome.
|
|
8
|
+
|
|
9
|
+
Structural tension is not a gap to bridge. It is the active disequilibrium created by
|
|
10
|
+
holding desired outcome and current reality clearly at the same time.
|
|
11
|
+
|
|
12
|
+
Use this language:
|
|
13
|
+
|
|
14
|
+
| Avoid | Prefer |
|
|
15
|
+
|---|---|
|
|
16
|
+
| bridge the gap | resolve the tension |
|
|
17
|
+
| close the gap | advance toward the desired outcome |
|
|
18
|
+
| tasks to fix the problem | strategic secondary choices |
|
|
19
|
+
| ready to begin | factual current reality |
|
|
20
|
+
|
|
21
|
+
A useful chart advances toward a created result. It does not merely remove a discomfort.
|
|
22
|
+
|
|
23
|
+
## The guard, and what it does not do
|
|
24
|
+
|
|
25
|
+
`create_structural_tension_chart` refuses a desired outcome containing `fix`, `solve`,
|
|
26
|
+
`eliminate`, `prevent`, `stop`, `avoid`, `reduce`, or `remove`, and answers with the
|
|
27
|
+
teaching above.
|
|
28
|
+
|
|
29
|
+
It matches on **word boundaries**, not substrings. This matters: an earlier version used
|
|
30
|
+
`.includes()` and so read the letters of those words inside longer ones. Two measured
|
|
31
|
+
refusals, on outcomes already written in creative orientation:
|
|
32
|
+
|
|
33
|
+
- "a fixed ladder of named rungs" — refused for `fix`
|
|
34
|
+
- "carry one to completion or resolve it" — refused for `solve`
|
|
35
|
+
|
|
36
|
+
Both authors rephrased around the error without asking why, which is the quiet cost: a
|
|
37
|
+
guard that fires on innocent text teaches the caller to edit for the checker rather than
|
|
38
|
+
for the reader. Sharper still, the second example is the phrasing the COAIA guidance
|
|
39
|
+
itself prescribes.
|
|
40
|
+
|
|
41
|
+
The word list is unchanged. An outcome that genuinely says "eliminate" or "reduce" should
|
|
42
|
+
still be met with the teaching. Only the matching was corrected.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# Delayed Resolution
|
|
2
|
+
|
|
3
|
+
Tolerate discrepancy and delayed resolution. Do not smooth over the contradiction between
|
|
4
|
+
desired outcome and current reality.
|
|
5
|
+
|
|
6
|
+
When information is missing, ask for current reality or name the missing reality
|
|
7
|
+
explicitly. Do not invent readiness.
|
|
8
|
+
|
|
9
|
+
`create_structural_tension_chart` refuses a current reality containing "ready to",
|
|
10
|
+
"prepared to", "all set", "ready for", or "set to", and answers with the principle. That
|
|
11
|
+
refusal exists because a readiness assumption prematurely resolves the tension the chart
|
|
12
|
+
was created to hold.
|
|
13
|
+
|
|
14
|
+
## MMOT — the Managerial Moment of Truth
|
|
15
|
+
|
|
16
|
+
Run `perform_mmot_evaluation` when output and expected performance diverge. Four phases,
|
|
17
|
+
in order:
|
|
18
|
+
|
|
19
|
+
1. **Acknowledge** the difference between expected and delivered.
|
|
20
|
+
2. **Analyze** how it came to pass.
|
|
21
|
+
3. **Update** the chart and current reality.
|
|
22
|
+
4. **Recommit** or redirect based on what is now true.
|
|
23
|
+
|
|
24
|
+
Call with `phase` set to one of those, or omit it for `full`.
|
|
25
|
+
|
|
26
|
+
## What `updateReality` governs
|
|
27
|
+
|
|
28
|
+
`updateReality` controls **one** record: the append into current reality. The chart's own
|
|
29
|
+
`metadata.mmotEvaluations[]` trail is a separate record and is written whenever an
|
|
30
|
+
assessment was made.
|
|
31
|
+
|
|
32
|
+
An earlier version gated both on that one flag, so a caller who only asked to leave
|
|
33
|
+
current reality alone lost the evaluation entirely — while still being handed a full
|
|
34
|
+
phase response that read like a success. The response line now names which records were
|
|
35
|
+
actually written:
|
|
36
|
+
|
|
37
|
+
- `✅ Evaluation stored: chart MMOT trail + current reality.`
|
|
38
|
+
- `✅ Evaluation stored: chart MMOT trail (current reality left untouched, as requested).`
|
|
39
|
+
|
|
40
|
+
Read that line. A success line that names the wrong record is the same failure class as a
|
|
41
|
+
success line over zero bytes.
|
|
42
|
+
|
|
43
|
+
## Elements of Performance
|
|
44
|
+
|
|
45
|
+
Pass `elementsOfPerformance` when creating a chart to define what the MMOT will evaluate
|
|
46
|
+
against. Each is `{ description, type }` where `type` is `DESIGN` (structural intent,
|
|
47
|
+
architecture) or `EXECUTION` (delivery, implementation quality). Without them, MMOT still
|
|
48
|
+
runs, but it has nothing concrete to compare the work to.
|
|
@@ -0,0 +1,85 @@
|
|
|
1
|
+
# Install And Environment
|
|
2
|
+
|
|
3
|
+
## Install
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
npm install -g coaiajs
|
|
7
|
+
coaia --version
|
|
8
|
+
```
|
|
9
|
+
|
|
10
|
+
## The skill
|
|
11
|
+
|
|
12
|
+
```bash
|
|
13
|
+
coaia skill show # print the packaged SKILL.md
|
|
14
|
+
coaia skill install # write ./.agents/skills/coaiajs
|
|
15
|
+
coaia skill install --global # write ~/.agents/skills/coaiajs
|
|
16
|
+
coaia skill install --yes # also create the .claude/skills/coaiajs symlink
|
|
17
|
+
coaia skill install --force # replace an existing install
|
|
18
|
+
coaia skill check # is the installed skill current?
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
`coaia skill check` compares an installed skill against the packaged one and reports
|
|
22
|
+
`current`, `stale`, or `missing`. Run it after upgrading `coaiajs`: a skill installed by an
|
|
23
|
+
older version describes an older tool surface, and nothing else will tell you.
|
|
24
|
+
|
|
25
|
+
The tool map inside `SKILL.md` is generated from the server's own tool definitions at
|
|
26
|
+
install time, so an installed skill cannot advertise a tool this package does not serve.
|
|
27
|
+
The version it was generated from is recorded in the frontmatter as `packageVersion`.
|
|
28
|
+
|
|
29
|
+
## Run the MCP server
|
|
30
|
+
|
|
31
|
+
```bash
|
|
32
|
+
coaiajs-mcp --memory-path ./memory.jsonl
|
|
33
|
+
COAIAJS_FEATURES=FULL coaiajs-mcp --memory-path ./memory.jsonl
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
## Inspect from the CLI
|
|
37
|
+
|
|
38
|
+
```bash
|
|
39
|
+
coaia narrative list -M ./memory.jsonl
|
|
40
|
+
coaia narrative view <chartId> -M ./memory.jsonl
|
|
41
|
+
coaia narrative stats -M ./memory.jsonl
|
|
42
|
+
coaia narrative progress <chartId> -M ./memory.jsonl
|
|
43
|
+
coaia narrative export <chartId> --output chart.md -M ./memory.jsonl
|
|
44
|
+
coaia narrative set-date <chartId> 2027-06-01T00:00:00Z --redistribute -M ./memory.jsonl
|
|
45
|
+
coaia narrative link-issue <chartId> owner/repo#123 -M ./memory.jsonl
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
## Refusals worth knowing about
|
|
49
|
+
|
|
50
|
+
### A memory path carrying an unexpanded shell variable
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
Refusing to open memory store: the path contains an unexpanded shell variable.
|
|
54
|
+
got: ${MIADI_CHART_MEMORY_PATH}
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
A seat once booted with that variable unset, so its `.mcp.json` handed the process the
|
|
58
|
+
placeholder verbatim. The server started happily and wrote live charts into a file
|
|
59
|
+
literally named `${MIADI_CHART_MEMORY_PATH}`. Nothing failed — the charts were simply
|
|
60
|
+
somewhere nobody would look, and another seat auditing the boot found them.
|
|
61
|
+
|
|
62
|
+
The sibling failure is worse and is why this is fatal rather than a warning: had the
|
|
63
|
+
variable been set to a path that does not exist, the server would have started **clean and
|
|
64
|
+
empty**, and the seat would have reported its whole store lost. A store is the one input
|
|
65
|
+
where "start anyway" is never the kind answer.
|
|
66
|
+
|
|
67
|
+
`$` is legal in a filename, so a path containing `$` alone is fine. Only `${` is refused —
|
|
68
|
+
a caller writing that is quoting a shell it expected to have run.
|
|
69
|
+
|
|
70
|
+
### A bare GitHub issue number
|
|
71
|
+
|
|
72
|
+
`githubIssue` and `link_chart_to_github_issue` require the full `owner/repo#number` path.
|
|
73
|
+
A bare `#42` resolves against whichever repository the reader happens to be in, which is
|
|
74
|
+
how an issue from one project ends up cited as another project's.
|
|
75
|
+
|
|
76
|
+
### A malformed tool call
|
|
77
|
+
|
|
78
|
+
See `mcp-tools.md`. Nothing is written and the offending fragment is quoted back.
|
|
79
|
+
|
|
80
|
+
## What this package does not lock
|
|
81
|
+
|
|
82
|
+
Writes are atomic — temp file, then rename — so a reader never sees a torn store. That
|
|
83
|
+
removes torn **reads**; it does not provide compare-and-swap. Two processes that both
|
|
84
|
+
load, then both write, still lose the earlier update, and both report success. If several
|
|
85
|
+
MCP instances point at one store, keep their write windows apart.
|