@wairon/cli 5.1.1-dev.100 → 5.1.1-dev.102

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 CHANGED
@@ -3,22 +3,25 @@
3
3
  **Waffle AIron** — an AI-Driven Development (AIDD) support tool built around
4
4
  **Spec-Driven Development (SDD)**.
5
5
 
6
- > **Status:** stable, actively developed — the SDD spec tree, the conformance gate (a 40-plus-rule
7
- > registry with narrative control-flow validation, technology
8
- > boundaries, and per-spec `lint.allow`), spec-derived agent topology,
9
- > skills, the MCP server, diagrams (Mermaid, interactive canvas + ERD,
10
- > draw.io/Excalidraw), extension packs (injectable profiles, language
11
- > tables, and rules), and a self-hostable HTTP **hosting server**
12
- > (`wairon serve` — HTTP MCP for many isolated projects) are working. See the
13
- > [roadmap](docs/roadmap.md) for what's next.
6
+ > **Status:** stable, actively developed — the SDD spec tree, the conformance gate (a
7
+ > documented rule registry — `wairon rules list` — with narrative control-flow
8
+ > validation, code↔spec conformance, technology boundaries, and per-spec
9
+ > `lint.allow`), human approval (`wairon lock`) with a CI merge gate
10
+ > (`wairon lock-check`), members and cross-project references, live agent
11
+ > briefs and skills, the MCP server, the design export, diagrams (Mermaid,
12
+ > interactive canvas + ERD, draw.io/Excalidraw), extension packs (injectable
13
+ > profiles, language tables, and rules), and a self-hostable HTTP **hosting
14
+ > server** (`wairon serve` — HTTP MCP for many isolated projects, with a web UI)
15
+ > are working. See the [roadmap](docs/roadmap.md) for what's next.
14
16
 
15
17
  ---
16
18
 
17
19
  ## What is it?
18
20
 
19
21
  `wairon` turns a validated **spec tree** into (a) an enforced architecture
20
- **conformance gate** and (b) a ready-made **agent topology + skills** that any AI
21
- coding tool (Claude Code, Gemini CLI, …) consumes to do the work itself.
22
+ **conformance gate**, (b) a recorded **approval** that CI can check, and (c) a
23
+ ready-made **agent topology + skills** that any AI coding tool (Claude Code,
24
+ Gemini CLI, …) consumes to do the work itself.
22
25
 
23
26
  It is optional and additive: if a project has a `.wai/specs/` tree the workflow
24
27
  is active; otherwise you ignore wairon and work normally. wairon does **not** run
@@ -27,17 +30,22 @@ or orchestrate AI sessions — it *equips* the session you already use.
27
30
  ```
28
31
  .wai/specs/ (the SDD spec tree — source of truth)
29
32
  │
30
- ├── wairon validate ──▶ architecture-conformance gate
31
- │ (stereotype dependency rules, contract↔impl
32
- │ symmetry, reference integrity, cycle detection)
33
+ ├── wairon validate ────▶ architecture-conformance gate
34
+ │ (stereotype dependency rules, contract↔impl
35
+ │ symmetry, reference integrity, cycle detection)
33
36
  │
34
- └── wairon generate ──▶ .claude/agents/ .gemini/agents/ (derived subagents)
35
- + SDD skills installed into each tool
36
- + wairon MCP server (sdd_* tools)
37
+ ├── wairon lock ────────▶ .wai/lock.json (the human approval, committed)
38
+ │ └ wairon lock-check ▶ CI merge gate: is this the approved design?
39
+ │
40
+ └── wairon MCP server ──▶ sdd_* tools + live agent briefs (sdd_get_agent_brief)
41
+ + SDD skills installed into each tool
37
42
  ```
38
43
 
39
- The host AI tool spawns the generated agents as its **own native subagents**,
40
- guided by the SDD skills and the `sdd_*` MCP tools.
44
+ The host AI tool spawns subagents of its own from the **live briefs** — each
45
+ composed from the current spec tree on every call — guided by the SDD skills
46
+ and the `sdd_*` MCP tools. Agent files on disk (`.claude/agents/`,
47
+ `.gemini/agents/`) are an optional materialized view of the same topology:
48
+ off by default, on with `rules.materializeAgentFiles: true`.
41
49
 
42
50
  ---
43
51
 
@@ -49,7 +57,7 @@ A complete system is specified top-down across six levels:
49
57
  |-------|------|-----------------|
50
58
  | **L0 System** | `.wai/specs/.index.yaml` | Vision, boundaries, global requirements, target language |
51
59
  | **L1 Subsystem** | `.wai/specs/<sub>/.index.yaml` | An isolated software service, its public interfaces, and trusted links |
52
- | **L2 Component** | `…/<component>/.index.yaml` | A building block (Portal, Orchestrator, Supervisor, Actor, Store, Index, Registry, Adapter, Observer, Specialist) or pattern (Repository, Gateway) + `owns`/`dependsOn` |
60
+ | **L2 Component** | `…/<component>/.index.yaml` | A building block (Portal, Orchestrator, Supervisor, Actor, Store, Index, Query, Registry, Adapter, Observer, and View for UIs) or pattern (Repository; FeatureComponent and RouterComponent for UIs) + `owns`/`dependsOn`. A gateway is a Portal with the `gateway` variant; logic is an Orchestrator whose `dependencyClass` bounds what it may depend on |
53
61
  | **L3 Interface** | `…/<component>/.interface.yaml` | Method signatures & structured params (+ optional wire endpoint bindings) |
54
62
  | **L4 Implementation** | `…/<component>/.implementation.yaml` | Concrete implementation of a contract: narrative detail level, bound `technologies` (the swap seam for vendors/engines), optional source path |
55
63
  | **L5 Narrative** | (within L4) | Step-by-step method logic as a flat numbered list — `call` steps resolve to real dependency methods, and flow steps (`branch`/`switch`/`loop`/`try`/`jump`/`return`/`throw`) jump by step number |
@@ -76,7 +84,13 @@ registry:
76
84
 
77
85
  - a **`system-architect`** from L0,
78
86
  - a **`<subsystem>-owner`** per subsystem,
79
- - a **`<component>-implementer`** per component.
87
+ - a **`<component>-implementer`** per component, when
88
+ `rules.generateComponentImplementers` is on.
89
+
90
+ Each agent is served as a **live brief** (`sdd_get_agent_brief`, or
91
+ `wairon agent brief <id>`), composed from the current tree whenever it is
92
+ asked for, so it is never stale. Writing them to disk as agent files is opt-in
93
+ (`rules.materializeAgentFiles: true`).
80
94
 
81
95
  A **domain** is a unit of ownership. Subsystems yield spec-backed domains
82
96
  automatically; you can also declare **free-standing domains** (docs, infra,
@@ -102,8 +116,19 @@ irm https://raw.githubusercontent.com/SYW-Apps/Waffle-AIron/main/install.ps1 | i
102
116
  curl -fsSL https://raw.githubusercontent.com/SYW-Apps/Waffle-AIron/main/install.sh | sh
103
117
  ```
104
118
 
105
- Both `wairon` and `wai` are registered as commands. (wairon is distributed
106
- as standalone binaries — it is not published to npm.)
119
+ Both `wairon` and `wai` are registered as commands.
120
+
121
+ ### npm
122
+
123
+ wairon is also published to npm as `@wairon/cli` (Node 18+):
124
+
125
+ ```sh
126
+ npm install --save-dev @wairon/cli # per project; run it with npx wairon
127
+ npm install --global @wairon/cli # or machine-wide
128
+ ```
129
+
130
+ The dist-tags are the release channels: `latest` (stable), `beta`, `preview`
131
+ and `dev`, e.g. `npm install -D @wairon/cli@dev`.
107
132
 
108
133
  ### Local development
109
134
 
@@ -138,15 +163,28 @@ merge to `dev`. Installing from npm, the channels are the dist-tags:
138
163
 
139
164
  ```sh
140
165
  cd my-project
141
- wairon init # bootstrap .wai/ (spec tree, context, skills, MCP-ready)
166
+ wairon init # bootstrap .wai/ (spec tree, context, skills, MCP registration)
167
+
168
+ # 1. Design: in your AI tool, use the sdd-architect skill, which authors the
169
+ # spec tree through the sdd_* MCP tools.
170
+
171
+ wairon status # the tree, its authoring readiness, and its approval state
172
+ wairon validate # architecture-conformance gate (--ci in CI)
173
+
174
+ # 2. Approve: once it validates, a human approves the design.
175
+ wairon lock # records the approval in .wai/lock.json
176
+ git add .wai && git commit -m "Approve the design"
177
+
178
+ # 3. Gate: in CI, check that what merges is the approved design
179
+ # (or use the reusable workflow — see docs/cli.md#wairon-lock-check---strict).
180
+ wairon lock-check
142
181
 
143
- # Design the system with the SDD architect skill (in your AI tool), or via the
144
- # sdd_* MCP tools. Then:
182
+ # 4. Implement: your AI tool delegates each component with the sdd-delegate
183
+ # skill, from its live brief (sdd_get_agent_brief).
145
184
 
146
- wairon status # spec-tree completeness dashboard
147
- wairon validate # architecture-conformance gate
148
- wairon generate # regenerate agent files + (re)install skills
149
- wairon list # agents resolved from the spec tree
185
+ # Optional
186
+ wairon export --out design.json # the whole resolved design as JSON
187
+ wairon diagram # interactive canvas in .wai/docs/diagrams/
150
188
  ```
151
189
 
152
190
  ---
@@ -165,20 +203,26 @@ See [docs/cli.md](docs/cli.md). Summary:
165
203
  | Command | Description |
166
204
  |---------|-------------|
167
205
  | `wairon init` | Bootstrap `.wai/` and the SDD spec tree |
168
- | `wairon status` | Spec-tree completeness dashboard |
169
- | `wairon validate [--ci]` | Architecture-conformance gate |
170
- | `wairon generate [--target] [--domain] [--dry-run]` | Regenerate agent files + install skills |
171
- | `wairon list` / `wairon show <id>` | Inspect agents resolved from the spec tree |
206
+ | `wairon status` | The spec tree, its authoring readiness, and its approval state |
207
+ | `wairon validate [--ci] [--all]` | Architecture-conformance gate (the family run at a project with members) |
208
+ | `wairon doctor [--fix]` | Health check and upgrade repairs |
209
+ | `wairon generate [--target] [--domain] [--dry-run]` | Reconcile guides, skills and context; agent files only when `rules.materializeAgentFiles` is on |
210
+ | `wairon list` / `wairon show <id>` / `wairon agent brief <id>` | Inspect agents resolved from the spec tree; print one's live brief |
211
+ | `wairon export [--out <file>]` | The whole design, resolved, as one JSON document ([format](docs/design-export.md)) |
172
212
  | `wairon diagram [--all] [--canvas] [--drawio] [--excalidraw] [--sequence <comp:method>]` | Mermaid, interactive canvas, and editable draw.io/Excalidraw exports |
173
213
  | `wairon rules list` | The conformance rule registry (the architecture linter) |
174
- | `wairon packs add \| list \| remove [--global]` | Extension packs: injected profiles, language tables, and rules |
214
+ | `wairon pack init \| build \| install \| use \| unuse \| impact \| sync \| bundle \| which \| list \| add \| remove` | Extension packs: injected profiles, language tables, and rules |
215
+ | `wairon member …` / `wairon subsystem externalize` / `wairon project rename` | Members (parts and projects) and the family migrations |
216
+ | `wairon externals pin \| status \| list` | Pin and check the externals a project consumes |
175
217
  | `wairon domains list \| scan \| add \| remove` | Domains (subsystem-derived + free-standing) |
176
218
  | `wairon skills list \| install` | Manage the SDD skills installed into your tools |
177
- | `wairon lock [-y]` | Validate the design as-complete and record its approval, code findings beside it (generates the implementer agents) |
219
+ | `wairon lock [-y]` | Validate the design as complete and record its approval in `.wai/lock.json`, code findings beside it; no spec file is rewritten |
178
220
  | `wairon lock-check [--strict]` | Merge gate: is the design in this tree the design that was approved? Importable as a [reusable workflow](.github/workflows/lock-check.yml) |
179
221
  | `wairon mcp serve \| install \| status` | The wairon MCP server (`sdd_*` tools) |
180
222
  | `wairon serve [--port] [--data-dir] [--no-auth]` | Self-host: HTTP MCP for many isolated projects + admin plane |
181
- | `wairon host project \| key \| lock \| promote` | Administer the hosting server (projects, keys, state-scoped lock/promote) |
223
+ | `wairon host unit \| project \| permission \| key \| lock \| doctor \| packs \| git \| producer \| secret \| demo` | Administer the hosting server (units, projects, permissions, keys, the state-scoped lock) |
224
+ | `wairon login` / `wairon remote` / `wairon mcp install --hosted` | Connect a checkout or an AI tool to a hosted instance |
225
+ | `wairon dev` | Local single-project web UI over the current project |
182
226
  | `wairon update` / `wairon aliases` | Self-update / command aliases |
183
227
 
184
228
  ---
@@ -189,7 +233,9 @@ See [docs/cli.md](docs/cli.md). Summary:
189
233
  - [Requirements](docs/requirements.md) — goals, non-goals, scope
190
234
  - [Roadmap](docs/roadmap.md) — what's done and what's next
191
235
  - [Vision](docs/vision.md) — long-term direction
192
- - [CLI Reference](docs/cli.md) — all commands
236
+ - [CLI Reference](docs/cli.md) — all commands and MCP tools
237
+ - [Design export](docs/design-export.md) — the `wairon export` JSON format for generators and translators
238
+ - [Supervisor doctrine](docs/design/supervisor-doctrine.md) — how Supervisors and Actors may depend on data and effects
193
239
  - [Hosted server](docs/design/hosted-mcp-server.md) — self-host wairon over HTTP (Docker, auth, sizing)
194
240
  - [Pack scoping](docs/design/pack-scoping.md) — the pack store, per-project selection, and reproducibility (design)
195
241
  - [Connecting-agent entrypoint](docs/design/connecting-agent-entrypoint.md) — MCP `instructions`, prompts, and skill composition