@jaimevalasek/aioson 1.23.3 → 1.28.1
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 +56 -0
- package/docs/en/4-agents/README.md +11 -8
- package/docs/en/4-agents/forge-run.md +165 -0
- package/docs/en/5-reference/README.md +1 -0
- package/docs/en/5-reference/cli-reference.md +199 -85
- package/docs/en/5-reference/executable-verification.md +165 -0
- package/docs/pt/4-agentes/README.md +2 -1
- package/docs/pt/4-agentes/forge-run.md +150 -0
- package/docs/pt/4-agentes/pm.md +8 -0
- package/docs/pt/4-agentes/qa.md +2 -0
- package/docs/pt/4-agentes/scope-check.md +19 -1
- package/docs/pt/4-agentes/sheldon.md +2 -0
- package/docs/pt/4-agentes/validator.md +20 -0
- package/docs/pt/5-referencia/autopilot-handoff.md +33 -0
- package/docs/pt/5-referencia/comandos-cli.md +64 -9
- package/docs/pt/5-referencia/fluxo-artefatos.md +40 -15
- package/docs/pt/5-referencia/loop-guardrails.md +19 -0
- package/docs/pt/5-referencia/sdd-automation-scripts.md +130 -26
- package/package.json +1 -1
- package/src/cli.js +70 -54
- package/src/commands/forge-compile.js +330 -0
- package/src/commands/harness-check.js +159 -0
- package/src/commands/harness.js +37 -2
- package/src/commands/spec-analyze.js +324 -0
- package/src/constants.js +118 -108
- package/src/harness/contract-schema.js +8 -0
- package/src/harness/plan-waves.js +77 -0
- package/src/harness/review-payload.js +230 -0
- package/src/i18n/messages/en.js +21 -15
- package/src/i18n/messages/es.js +15 -13
- package/src/i18n/messages/fr.js +15 -13
- package/src/i18n/messages/pt-BR.js +21 -15
- package/src/parser.js +3 -1
- package/template/.aioson/agents/dev.md +67 -66
- package/template/.aioson/agents/forge-run.md +57 -0
- package/template/.aioson/agents/pm.md +51 -45
- package/template/.aioson/agents/qa.md +22 -22
- package/template/.aioson/agents/scope-check.md +49 -46
- package/template/.aioson/agents/sheldon.md +1 -1
- package/template/.aioson/agents/validator.md +16 -5
- package/template/.aioson/docs/autopilot-handoff.md +34 -32
- package/template/.aioson/docs/sheldon/harness-contract.md +19 -2
- package/template/.claude/commands/aioson/agent/forge-run.md +17 -0
- package/template/AGENTS.md +15 -13
- package/template/CLAUDE.md +10 -9
- package/template/OPENCODE.md +24 -23
|
@@ -272,7 +272,7 @@ Run after writing `sheldon-enrichment-{slug}.md` only when `classification: MEDI
|
|
|
272
272
|
|
|
273
273
|
Goal: convert binary ACs from the enriched PRD into a machine-checkable contract consumed by `@validator`. Implements AC-HD-06 of `harness-driven-aioson`.
|
|
274
274
|
|
|
275
|
-
Load `.aioson/docs/sheldon/harness-contract.md` for the full procedure: init via `aioson harness:init`, criteria population (binary vs advisory), `contract_mode`/governor selection by risk, and canonical schemas. Mention the contract path in the post-enrichment handoff; the user approves before the contract is final.
|
|
275
|
+
Load `.aioson/docs/sheldon/harness-contract.md` for the full procedure: init via `aioson harness:init`, criteria population (binary vs advisory), `verification` command authoring (every `binary: true` criterion carries an executable check when mechanically possible — exit 0 = pass, run via `aioson harness:check`), `contract_mode`/governor selection by risk, and canonical schemas. Mention the contract path in the post-enrichment handoff; the user approves before the contract is final.
|
|
276
276
|
|
|
277
277
|
## Retro dossier analysis (on-demand)
|
|
278
278
|
|
|
@@ -25,6 +25,7 @@ Rules and governance docs may *add* binary criteria but never override the expli
|
|
|
25
25
|
- `.aioson/plans/{slug}/progress.json` — current state and `completed_steps`
|
|
26
26
|
- Files listed in `progress.json.completed_steps` — the only delivered artifacts in scope
|
|
27
27
|
- Diagnostic tool output — linters, test runners, compilers for deterministic verification
|
|
28
|
+
- `.aioson/plans/{slug}/validator-prompt.txt` (when generated by `aioson harness:validate`) — self-contained review payload: deterministic check results, changed-file list, and unified diff vs base. **Preferred activation: run from this prompt in a fresh, isolated context** (subagent or separate session) — never inline in the session that implemented the feature.
|
|
28
29
|
> Strict sandbox: read ONLY the above. Never read other agents' history, PRDs/requirements/architecture, or unrelated code — see **Context restrictions (mandatory)** below.
|
|
29
30
|
|
|
30
31
|
## Context restrictions (mandatory)
|
|
@@ -50,13 +51,23 @@ To preserve impartiality and avoid continuity hallucinations, you operate in a *
|
|
|
50
51
|
Locate `harness-contract.json` for the current feature. Identify criteria with `binary: true`.
|
|
51
52
|
|
|
52
53
|
### Step 2 — Deterministic verification
|
|
53
|
-
|
|
54
|
+
First, run the executable checks declared in the contract:
|
|
55
|
+
|
|
56
|
+
```bash
|
|
57
|
+
aioson harness:check . --slug={slug} --json
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
For every criterion that has a `verification` command, the check's exit code **is** the verdict — copy `ok` into `passed` verbatim (reason = the check's stderr first line on failure). Never override a deterministic result with judgment. The report is also persisted at `.aioson/plans/{slug}/last-check-output.json` (allowed reading — it is diagnostic tool output).
|
|
61
|
+
|
|
62
|
+
For criteria **without** `verification` that are still mechanically checkable, run (or request execution of) local tools yourself:
|
|
54
63
|
- `ls -l {path}` to check file existence.
|
|
55
64
|
- `cat {path}` to validate patterns or content.
|
|
56
65
|
- `npm test` or equivalent for execution criteria.
|
|
57
66
|
|
|
67
|
+
If the `aioson` CLI is unavailable, fall back to running each criterion's `verification` command directly and use its exit code.
|
|
68
|
+
|
|
58
69
|
### Step 3 — Semantic verification
|
|
59
|
-
|
|
70
|
+
Only for criteria with no `verification` command that require understanding (e.g., "API follows REST conventions"): analyze the delivered code strictly against what the contract requires — nothing more.
|
|
60
71
|
|
|
61
72
|
### Step 4 — Verdict generation
|
|
62
73
|
Your output must be **EXCLUSIVELY** a structured JSON object designed to be parsed by a machine. Do not add preambles or explanations outside the JSON.
|
|
@@ -100,12 +111,12 @@ aioson dossier:add-finding . --slug={slug} --agent=validator --section="Agent Tr
|
|
|
100
111
|
|
|
101
112
|
Skip silently when the dossier is absent — `progress.json` remains the canonical machine output.
|
|
102
113
|
|
|
103
|
-
## Observability
|
|
104
|
-
At session end, register: `aioson agent:epilogue . --agent=validator --feature=<slug> --summary="Validated <slug> phase <N>: score=<0|1>, ready_for_done=<bool>" --no-dossier 2>/dev/null || aioson agent:done . --agent=validator --summary="Validated <slug> phase <N>: score=<0|1>, ready_for_done=<bool>" 2>/dev/null || true`
|
|
114
|
+
## Observability
|
|
115
|
+
At session end, register: `aioson agent:epilogue . --agent=validator --feature=<slug> --summary="Validated <slug> phase <N>: score=<0|1>, ready_for_done=<bool>" --no-dossier 2>/dev/null || aioson agent:done . --agent=validator --summary="Validated <slug> phase <N>: score=<0|1>, ready_for_done=<bool>" 2>/dev/null || true`
|
|
105
116
|
|
|
106
117
|
## Autopilot handoff (post-dev cycle)
|
|
107
118
|
|
|
108
|
-
When `auto_handoff: true` is set in `project.context.md`, after the verdict and `agent:epilogue`/`agent:done` (`.aioson/docs/autopilot-handoff.md`):
|
|
119
|
+
When `auto_handoff: true` is set in `project.context.md`, after the verdict and `agent:epilogue`/`agent:done` (`.aioson/docs/autopilot-handoff.md`):
|
|
109
120
|
- Score 0 / FAIL → `Skill(aioson:agent:dev)` with `"fix @validator findings — autopilot handoff"`.
|
|
110
121
|
- Score 1 / PASS → **STOP**. The feature is verification-clean; recommend the human run `aioson feature:close . --feature={slug}`. **Never auto-run `feature:close`** — the close is the human gate.
|
|
111
122
|
|
|
@@ -9,21 +9,21 @@ Opt-in protocol that removes manual handoff confirmations in the deterministic s
|
|
|
9
9
|
1. **Pre-dev chain (`@analyst` → `@dev`):** `@analyst`, `@scope-check`, `@architect`, `@discovery-design-doc`, and `@pm` (MEDIUM only). Upstream agents (`@briefing`, `@product`, `@sheldon`) always stay manual — they end on genuine human decisions.
|
|
10
10
|
2. **Post-dev review cycle (`@dev` → `@qa` → `@tester`/`@pentester` → `@validator`):** once a human starts `@dev`, the implementation and review agents chain automatically until the feature is ready to close. `@qa` is the hub: it owns the routing to the specialized agents and the corrections loop.
|
|
11
11
|
|
|
12
|
-
## Activation
|
|
13
|
-
|
|
14
|
-
Autopilot is active only when ALL are true:
|
|
15
|
-
|
|
16
|
-
1. `project.context.md` frontmatter has `auto_handoff: true` (absent or `false` = manual handoffs, current behavior).
|
|
17
|
-
2. A feature workflow is active (feature slug known, classification SMALL or MEDIUM).
|
|
18
|
-
3. The current agent's own gate/verdict passed (see stop conditions).
|
|
19
|
-
|
|
20
|
-
Preferred runtime entrypoint:
|
|
21
|
-
|
|
22
|
-
```bash
|
|
23
|
-
aioson workflow:execute . --feature={slug} --tool=<tool> --agentic
|
|
24
|
-
```
|
|
25
|
-
|
|
26
|
-
`workflow:execute --agentic` is the central orchestration contract. It writes `.aioson/context/workflow-execute.json` with `agentic_policy`, including the review-loop caps, sidecar/scout policy, lane guard, current checkpoint, and resumable command. Prompt-level `Skill(aioson:agent:<next>)` chaining remains a compatibility fallback for clients that cannot let the gateway consume this checkpoint.
|
|
12
|
+
## Activation
|
|
13
|
+
|
|
14
|
+
Autopilot is active only when ALL are true:
|
|
15
|
+
|
|
16
|
+
1. `project.context.md` frontmatter has `auto_handoff: true` (absent or `false` = manual handoffs, current behavior).
|
|
17
|
+
2. A feature workflow is active (feature slug known, classification SMALL or MEDIUM).
|
|
18
|
+
3. The current agent's own gate/verdict passed (see stop conditions).
|
|
19
|
+
|
|
20
|
+
Preferred runtime entrypoint:
|
|
21
|
+
|
|
22
|
+
```bash
|
|
23
|
+
aioson workflow:execute . --feature={slug} --tool=<tool> --agentic
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
`workflow:execute --agentic` is the central orchestration contract. It writes `.aioson/context/workflow-execute.json` with `agentic_policy`, including the review-loop caps, sidecar/scout policy, lane guard, current checkpoint, and resumable command. Prompt-level `Skill(aioson:agent:<next>)` chaining remains a compatibility fallback for clients that cannot let the gateway consume this checkpoint.
|
|
27
27
|
|
|
28
28
|
## Routing — deterministic, never LLM-chosen
|
|
29
29
|
|
|
@@ -34,22 +34,22 @@ The next agent comes from the workflow state machine and on-disk evidence, not f
|
|
|
34
34
|
|
|
35
35
|
Never skip a stage, reorder, or pick an agent the state machine / routing table did not name.
|
|
36
36
|
|
|
37
|
-
## Auto-invoke pattern
|
|
38
|
-
|
|
39
|
-
When autopilot is active and no stop condition applies:
|
|
40
|
-
|
|
41
|
-
1. Finish your own closing duties first (artifacts on disk, gate registration, dossier/spec updates, `agent:epilogue`; `agent:done` remains the fallback).
|
|
42
|
-
2. If the runtime checkpoint contains `agentic_policy.enabled=true`, let the gateway continue from `.aioson/context/workflow-execute.json`; do not ask the user to confirm the next deterministic stage.
|
|
43
|
-
3. If no runtime gateway is available, emit a one-line transition notice: `Autopilot: @<current> done → invoking @<next> (Ctrl+C to interrupt)`.
|
|
44
|
-
4. Invoke `Skill(aioson:agent:<next>)` with the task `"continue feature {slug} — autopilot handoff from @<current>"`. No user prompt — Ctrl+C interrupts.
|
|
37
|
+
## Auto-invoke pattern
|
|
38
|
+
|
|
39
|
+
When autopilot is active and no stop condition applies:
|
|
40
|
+
|
|
41
|
+
1. Finish your own closing duties first (artifacts on disk, gate registration, dossier/spec updates, `agent:epilogue`; `agent:done` remains the fallback).
|
|
42
|
+
2. If the runtime checkpoint contains `agentic_policy.enabled=true`, let the gateway continue from `.aioson/context/workflow-execute.json`; do not ask the user to confirm the next deterministic stage.
|
|
43
|
+
3. If no runtime gateway is available, emit a one-line transition notice: `Autopilot: @<current> done → invoking @<next> (Ctrl+C to interrupt)`.
|
|
44
|
+
4. Invoke `Skill(aioson:agent:<next>)` with the task `"continue feature {slug} — autopilot handoff from @<current>"`. No user prompt — Ctrl+C interrupts.
|
|
45
45
|
|
|
46
46
|
## Segment 1 — pre-dev chain (`@analyst` → `@dev`)
|
|
47
47
|
|
|
48
|
-
SMALL feature: `@analyst` → `@scope-check` → `@architect` → `@discovery-design-doc` → `@dev`.
|
|
49
|
-
|
|
50
|
-
MEDIUM feature: `@analyst` → `@architect` → `@discovery-design-doc` → `@pm` → `@scope-check` → `@dev`.
|
|
51
|
-
|
|
52
|
-
The prompt-only fallback still stops before the FIRST `@dev` activation because `@dev` is a heavy phase and benefits from a fresh context window. Runtime agentic mode may cross this boundary only by starting a fresh `@dev` activation from the checkpoint/context package, not by carrying the upstream chat context forward. If the gateway cannot start that fresh activation, stop with the normal `/clear` + `/dev` recommendation.
|
|
48
|
+
SMALL feature: `@analyst` → `@scope-check` → `@architect` → `@discovery-design-doc` → `@dev`.
|
|
49
|
+
|
|
50
|
+
MEDIUM feature: `@analyst` → `@architect` → `@discovery-design-doc` → `@pm` → `@scope-check` → `@dev`.
|
|
51
|
+
|
|
52
|
+
The prompt-only fallback still stops before the FIRST `@dev` activation because `@dev` is a heavy phase and benefits from a fresh context window. Runtime agentic mode may cross this boundary only by starting a fresh `@dev` activation from the checkpoint/context package, not by carrying the upstream chat context forward. If the gateway cannot start that fresh activation, stop with the normal `/clear` + `/dev` recommendation.
|
|
53
53
|
|
|
54
54
|
## Segment 2 — post-dev review cycle (hub = `@qa`)
|
|
55
55
|
|
|
@@ -60,8 +60,8 @@ Routing table (each row is followed only when autopilot is active and no stop co
|
|
|
60
60
|
| Current | Condition | Auto-invoke |
|
|
61
61
|
|---|---|---|
|
|
62
62
|
| `@dev` (first pass) | tests green, gates clear, no open corrections cycle | `@qa` |
|
|
63
|
-
| `@dev` (corrections) | corrections applied, tests green (`review-cycle:status` active; `qa-dev-cycle.json` is legacy QA compatibility) | `@qa` (re-verify) |
|
|
64
|
-
| `@qa` | verdict **FAIL** (Critical/High) | `@dev` via the corrections auto-cycle (cap 3, security gate) |
|
|
63
|
+
| `@dev` (corrections) | corrections applied, tests green (`review-cycle:status` active; `qa-dev-cycle.json` is legacy QA compatibility) | `@qa` (re-verify) |
|
|
64
|
+
| `@qa` | verdict **FAIL** (Critical/High) | `@dev` via the corrections auto-cycle (cap 3, security gate) |
|
|
65
65
|
| `@qa` | verdict **PASS** + `@tester` trigger fires AND `@tester` not yet run clean | `@tester` |
|
|
66
66
|
| `@qa` | verdict **PASS** + `@pentester` trigger fires AND `@pentester` not yet run clean | `@pentester` |
|
|
67
67
|
| `@qa` | verdict **PASS** + harness contract present AND `@validator` not yet PASS | `@validator` |
|
|
@@ -77,11 +77,13 @@ Routing table (each row is followed only when autopilot is active and no stop co
|
|
|
77
77
|
|
|
78
78
|
**Re-entry guard (no infinite loops):** before auto-invoking a specialized agent, `@qa` checks on-disk evidence that it already ran clean this cycle (e.g. `security-findings-{slug}.json` clean → `@pentester` done; a tester coverage artifact present with no new gap → `@tester` done; `progress.json.ready_for_done_gate` / validator PASS recorded → `@validator` done). An agent that already returned clean is not re-invoked.
|
|
79
79
|
|
|
80
|
+
**`@validator` runs fresh-context:** when routing to `@validator` with a harness contract present, do not run it inline in the current session — the implementation history biases the verdict. Instead: (1) `aioson harness:check . --slug={slug}` (deterministic checks), (2) `aioson harness:validate . --slug={slug}` — the generated `validator-prompt.txt` is self-contained (criteria + check results + diff vs base), (3) execute that prompt in an **isolated subagent** (Task tool, no conversation context) that writes its JSON verdict to `last-validator-output.json`, (4) re-run `aioson harness:validate` to consume the verdict through the circuit breaker. Clients without subagent support fall back to `Skill(aioson:agent:validator)` in a fresh session, as before.
|
|
81
|
+
|
|
80
82
|
## Stop conditions — break the chain and emit the normal manual handoff
|
|
81
83
|
|
|
82
84
|
1. **`feature:close` / publish** — ALWAYS the human gate. When `@qa` (PASS, nothing pending) or `@validator` (PASS) is the last clean step, STOP and recommend `aioson feature:close . --feature={slug}`. Never auto-run `feature:close`, `feature:archive`, `npm publish`, or any publish/close action.
|
|
83
|
-
2. **First `@dev` entry without runtime gateway** — prompt-only clients stop here (Segment 1). Runtime agentic mode may continue only through a fresh checkpointed `@dev` activation.
|
|
84
|
-
3. **Corrections cap reached** — review cycles are bounded by `agentic_policy.review_cycle` (default 3); when `review-cycle:advance` returns `stop_cycle_limit`, stop and escalate to the human.
|
|
85
|
+
2. **First `@dev` entry without runtime gateway** — prompt-only clients stop here (Segment 1). Runtime agentic mode may continue only through a fresh checkpointed `@dev` activation.
|
|
86
|
+
3. **Corrections cap reached** — review cycles are bounded by `agentic_policy.review_cycle` (default 3); when `review-cycle:advance` returns `stop_cycle_limit`, stop and escalate to the human.
|
|
85
87
|
4. **Critical security finding** — the `@qa` corrections security gate (auth/secret/credential/session/password/token/PII/encryption keywords) blocks the auto-loop; stop and require human intervention.
|
|
86
88
|
5. **Verdict not clean / gate or readiness blocked** — `@scope-check` not `approved`/`patched`, `@architect` Gate B blocked, `@discovery-design-doc` readiness `blocked`, `@pm` Gate C blocked, `@validator` FAIL with no safe corrections path: stop and route to the owner manually.
|
|
87
89
|
6. **Context budget** — estimated usage ≥ `context_warning_threshold` (`.aioson/config.md`): write the compaction checkpoint to `.aioson/context/last-handoff.json`, stop, and recommend `/clear`. The workflow resumes from `workflow.state.json` — the next session re-enters autopilot automatically.
|
|
@@ -37,7 +37,8 @@ For every AC in the enriched PRD with an objective, mechanically verifiable asse
|
|
|
37
37
|
"id": "C1",
|
|
38
38
|
"description": "<AC text — human-readable for PR review>",
|
|
39
39
|
"assertion": "<machine-verifiable expression — e.g. 'tests/foo.test.js passes' or 'src/x/y.js exports parseX'>",
|
|
40
|
-
"binary": true
|
|
40
|
+
"binary": true,
|
|
41
|
+
"verification": "<shell command whose exit code 0 = pass — e.g. 'node --test tests/foo.test.js'>"
|
|
41
42
|
}
|
|
42
43
|
```
|
|
43
44
|
|
|
@@ -45,6 +46,19 @@ ACs that are subjective (UX feel, code style preference) get `binary: false` and
|
|
|
45
46
|
|
|
46
47
|
**Rule of thumb:** if the assertion can be answered by a single shell command exit code or a single test, it qualifies as `binary: true`. Otherwise mark it advisory and let `@qa` cover it.
|
|
47
48
|
|
|
49
|
+
### 2b. Author `verification` commands
|
|
50
|
+
|
|
51
|
+
Every `binary: true` criterion **must** carry a `verification` shell command whenever one is mechanically possible. Exit code 0 = pass; anything else = fail. These commands are executed deterministically by `aioson harness:check . --slug={slug}` (and by `self:loop`) — `@validator` only LLM-judges criteria that have no `verification`.
|
|
52
|
+
|
|
53
|
+
Authoring rules for `verification`:
|
|
54
|
+
|
|
55
|
+
- **Prefer the project's own test runner** (`node --test tests/x.test.js`, `npm test -- --grep "..."`, `pytest tests/test_x.py`). A criterion backed by a real test is the gold standard.
|
|
56
|
+
- **One-liner assertions** when no test exists yet: `node -e "const m = require('./src/x'); process.exit(typeof m.parseX === 'function' ? 0 : 1)"`.
|
|
57
|
+
- **Deterministic only**: no network calls, no wall-clock dependence, no interactive prompts.
|
|
58
|
+
- **Cross-platform**: single commands or npm scripts — avoid shell chaining (`&&`, `||`) and POSIX-only utilities (`grep`, `test -f`) on Windows-first projects; use `node -e` for file/shape assertions instead.
|
|
59
|
+
- **Self-contained**: the command must pass/fail on a clean checkout after install — no hidden setup steps.
|
|
60
|
+
- A `binary: true` criterion **without** `verification` remains valid (judged by `@validator`, as before), but the contract schema emits a coverage warning — treat each one as debt and justify it in the enrichment log.
|
|
61
|
+
|
|
48
62
|
### 3. Set `contract_mode`
|
|
49
63
|
|
|
50
64
|
By classification and risk surface:
|
|
@@ -90,12 +104,15 @@ Safe defaults for `BALANCED`:
|
|
|
90
104
|
"id": "C1",
|
|
91
105
|
"description": "...",
|
|
92
106
|
"assertion": "...",
|
|
93
|
-
"binary": true
|
|
107
|
+
"binary": true,
|
|
108
|
+
"verification": "node --test tests/foo.test.js"
|
|
94
109
|
}
|
|
95
110
|
]
|
|
96
111
|
}
|
|
97
112
|
```
|
|
98
113
|
|
|
114
|
+
`verification` is optional per criterion (legacy contracts remain valid), executed via `aioson harness:check` with exit code 0 = pass.
|
|
115
|
+
|
|
99
116
|
### `progress.json`
|
|
100
117
|
|
|
101
118
|
```json
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "AIOSON — Compile and run the Lane B workflow harness for a MEDIUM feature"
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
If $ARGUMENTS is exactly "--help" or starts with "--help":
|
|
6
|
+
Do NOT activate the agent. Instead, display this help and stop:
|
|
7
|
+
|
|
8
|
+
@forge-run — Compile specs into a workflow harness and execute it (Lane B)
|
|
9
|
+
Usage: /aioson:agent:forge-run [feature slug]
|
|
10
|
+
Requires:
|
|
11
|
+
.aioson/plans/{slug}/harness-contract.json (with verification commands)
|
|
12
|
+
.aioson/context/implementation-plan-{slug}.md (with Wave column)
|
|
13
|
+
Produces: .aioson/plans/{slug}/forge-run.workflow.js + a workflow run ending before feature:close
|
|
14
|
+
Instruction file: .aioson/agents/forge-run.md
|
|
15
|
+
CLI help: aioson agent:help forge-run
|
|
16
|
+
|
|
17
|
+
Otherwise: Read `.aioson/agents/forge-run.md` and follow all instructions. $ARGUMENTS
|
package/template/AGENTS.md
CHANGED
|
@@ -2,12 +2,12 @@
|
|
|
2
2
|
|
|
3
3
|
You operate as AIOSON — an AI development squad with specialized agents.
|
|
4
4
|
|
|
5
|
-
## Mandatory first action
|
|
6
|
-
1. Check whether `.aioson/context/project.context.md` exists
|
|
7
|
-
- If missing: activate @setup agent immediately
|
|
8
|
-
- If present: read it before any action
|
|
9
|
-
2. Read `.aioson/config.md` only if project context is missing/invalid, setup/routing policy is needed, or the active agent explicitly asks for config details.
|
|
10
|
-
3. If `.aioson/rules/` contains `.md` files, note silently that project rules are active — each agent will load applicable rules automatically via its "Project rules, docs & design docs" section. Do not alarm if the directory is absent or empty.
|
|
5
|
+
## Mandatory first action
|
|
6
|
+
1. Check whether `.aioson/context/project.context.md` exists
|
|
7
|
+
- If missing: activate @setup agent immediately
|
|
8
|
+
- If present: read it before any action
|
|
9
|
+
2. Read `.aioson/config.md` only if project context is missing/invalid, setup/routing policy is needed, or the active agent explicitly asks for config details.
|
|
10
|
+
3. If `.aioson/rules/` contains `.md` files, note silently that project rules are active — each agent will load applicable rules automatically via its "Project rules, docs & design docs" section. Do not alarm if the directory is absent or empty.
|
|
11
11
|
|
|
12
12
|
## Project knowledge
|
|
13
13
|
|
|
@@ -88,6 +88,7 @@ Describe your intent. The agent system will match and execute.
|
|
|
88
88
|
| @design-hybrid-forge | "create hybrid design skill", "combine two design skills", "use the design-hybrid-forge agent" |
|
|
89
89
|
| @site-forge | "clone this site with [skill]", "rebuild [url] using [skill]", "[url] in the style of [skill]", "extract the design from [url] as a skill", "use the site-forge agent" |
|
|
90
90
|
| @discover | "discover the system", "scan and understand the project", "build semantic knowledge cache", "refresh bootstrap", "use the discover agent" |
|
|
91
|
+
| @forge-run | "compile the workflow harness for [slug]", "run lane B for [slug]", "execute the compiled harness", "use the forge-run agent" |
|
|
91
92
|
|
|
92
93
|
When an agent file is included via @ or described via natural language, read the corresponding file and execute its instructions immediately from the first step.
|
|
93
94
|
Do not answer with "I will open/read/show the file" unless the user explicitly asked to inspect that file.
|
|
@@ -148,6 +149,7 @@ When running Codex directly (without `aioson workflow:next`), these rules apply:
|
|
|
148
149
|
- @orache → `.aioson/agents/orache.md`
|
|
149
150
|
- @design-hybrid-forge → `.aioson/agents/design-hybrid-forge.md`
|
|
150
151
|
- @site-forge → `.aioson/agents/site-forge.md`
|
|
152
|
+
- @forge-run → `.aioson/agents/forge-run.md`
|
|
151
153
|
|
|
152
154
|
## Spec-Driven Development (SDD)
|
|
153
155
|
|
|
@@ -167,8 +169,8 @@ AIOSON uses the `aioson-spec-driven` process skill to enforce specification-firs
|
|
|
167
169
|
|
|
168
170
|
Gates are blocking in MEDIUM, informational in MICRO/SMALL.
|
|
169
171
|
|
|
170
|
-
### How agents load SDD
|
|
171
|
-
For concrete spec/workflow work, the active agent checks for `aioson-spec-driven` in `.aioson/installed-skills/` or `.aioson/skills/process/` and loads only its role-specific reference file (e.g., `references/dev.md`, `references/qa.md`). A bare `@deyvin` activation is not spec work: follow Deyvin's activation-only fast path and do not open this skill.
|
|
172
|
+
### How agents load SDD
|
|
173
|
+
For concrete spec/workflow work, the active agent checks for `aioson-spec-driven` in `.aioson/installed-skills/` or `.aioson/skills/process/` and loads only its role-specific reference file (e.g., `references/dev.md`, `references/qa.md`). A bare `@deyvin` activation is not spec work: follow Deyvin's activation-only fast path and do not open this skill.
|
|
172
174
|
|
|
173
175
|
### Project pulse convention
|
|
174
176
|
Every agent updates `project-pulse.md` at session end with: last_agent, last_gate, active features, blockers, and next recommended action. This enables crash recovery — any agent can read project-pulse.md and know where to resume.
|
|
@@ -179,9 +181,9 @@ Located at: `.aioson/skills/process/aioson-spec-driven/SKILL.md`
|
|
|
179
181
|
|
|
180
182
|
This is a first-party process skill. It teaches agents how phases connect, when to apply which depth, and how to prepare clean handoffs.
|
|
181
183
|
|
|
182
|
-
Agents that load it: @product, @analyst, @scope-check, @architect, @sheldon, @dev, @deyvin, @qa, @tester, @orchestrator, @pm
|
|
183
|
-
When to load: at the start of concrete spec work (PRD, requirements, architecture, implementation, testing); not during `@deyvin` activation-only recovery
|
|
184
|
-
What to load: `SKILL.md` first, then only the `references/` file relevant to the current phase
|
|
184
|
+
Agents that load it: @product, @analyst, @scope-check, @architect, @sheldon, @dev, @deyvin, @qa, @tester, @orchestrator, @pm
|
|
185
|
+
When to load: at the start of concrete spec work (PRD, requirements, architecture, implementation, testing); not during `@deyvin` activation-only recovery
|
|
186
|
+
What to load: `SKILL.md` first, then only the `references/` file relevant to the current phase
|
|
185
187
|
|
|
186
188
|
## Process skill: design-hybrid-forge
|
|
187
189
|
|
|
@@ -225,8 +227,8 @@ researchs/
|
|
|
225
227
|
Primary recurring writers here: @product, @sheldon, and @squad
|
|
226
228
|
All agents may read from here to avoid redundant searches.
|
|
227
229
|
|
|
228
|
-
## Session protocol
|
|
229
|
-
Do not read `.aioson/context/spec.md` globally at session start. Agents load `spec*.md` only when `context:select`, their SDD reference, or a concrete task selects it; update it at session end only if the active agent loaded and changed that spec context.
|
|
230
|
+
## Session protocol
|
|
231
|
+
Do not read `.aioson/context/spec.md` globally at session start. Agents load `spec*.md` only when `context:select`, their SDD reference, or a concrete task selects it; update it at session end only if the active agent loaded and changed that spec context.
|
|
230
232
|
|
|
231
233
|
## Golden rule
|
|
232
234
|
Small project, small solution.
|
package/template/CLAUDE.md
CHANGED
|
@@ -2,12 +2,12 @@
|
|
|
2
2
|
|
|
3
3
|
You operate as AIOSON.
|
|
4
4
|
|
|
5
|
-
## Mandatory first action
|
|
6
|
-
1. Check whether `.aioson/context/project.context.md` exists
|
|
7
|
-
- If missing: run `/setup`
|
|
8
|
-
- If present: read it before any action
|
|
9
|
-
2. Read `.aioson/config.md` only if project context is missing/invalid, setup/routing policy is needed, or the active agent explicitly asks for config details.
|
|
10
|
-
3. If `.aioson/rules/` contains `.md` files, note silently that project rules are active — each agent will load applicable rules automatically via its "Project rules, docs & design docs" section. Do not alarm if the directory is absent or empty.
|
|
5
|
+
## Mandatory first action
|
|
6
|
+
1. Check whether `.aioson/context/project.context.md` exists
|
|
7
|
+
- If missing: run `/setup`
|
|
8
|
+
- If present: read it before any action
|
|
9
|
+
2. Read `.aioson/config.md` only if project context is missing/invalid, setup/routing policy is needed, or the active agent explicitly asks for config details.
|
|
10
|
+
3. If `.aioson/rules/` contains `.md` files, note silently that project rules are active — each agent will load applicable rules automatically via its "Project rules, docs & design docs" section. Do not alarm if the directory is absent or empty.
|
|
11
11
|
|
|
12
12
|
## Project knowledge
|
|
13
13
|
|
|
@@ -78,14 +78,15 @@ Capture is best-effort — do not crash, retry, or surface failures to the user.
|
|
|
78
78
|
- /design-hybrid-forge -> `.aioson/agents/design-hybrid-forge.md`
|
|
79
79
|
- /site-forge -> `.aioson/agents/site-forge.md`
|
|
80
80
|
- /discover -> `.aioson/agents/discover.md`
|
|
81
|
+
- /forge-run -> `.aioson/agents/forge-run.md`
|
|
81
82
|
|
|
82
83
|
## Spec-Driven Development framework
|
|
83
84
|
|
|
84
85
|
AIOSON follows a Spec-Driven Development (SDD) methodology. Key governance files:
|
|
85
86
|
|
|
86
|
-
- **`.aioson/constitution.md`** — 6 governing principles all agents must respect
|
|
87
|
-
- **`.aioson/context/project-pulse.md`** — global project state; read at session start, update at session end
|
|
88
|
-
- **`.aioson/skills/process/aioson-spec-driven/SKILL.md`** — process methodology; agents load this on demand for concrete spec/workflow work. `/deyvin` activation-only recovery must not load it.
|
|
87
|
+
- **`.aioson/constitution.md`** — 6 governing principles all agents must respect
|
|
88
|
+
- **`.aioson/context/project-pulse.md`** — global project state; read at session start, update at session end
|
|
89
|
+
- **`.aioson/skills/process/aioson-spec-driven/SKILL.md`** — process methodology; agents load this on demand for concrete spec/workflow work. `/deyvin` activation-only recovery must not load it.
|
|
89
90
|
|
|
90
91
|
The process depth scales with project classification:
|
|
91
92
|
- **MICRO** (0-1): lightweight — @product → @dev
|
package/template/OPENCODE.md
CHANGED
|
@@ -1,31 +1,31 @@
|
|
|
1
1
|
# AIOSON - OpenCode
|
|
2
2
|
|
|
3
|
-
## Boot
|
|
4
|
-
1. Check `.aioson/context/project.context.md`
|
|
5
|
-
2. If present, read it before any action
|
|
6
|
-
3. If missing, start with `setup`
|
|
7
|
-
4. Read `.aioson/config.md` only if project context is missing/invalid, setup/routing policy is needed, or the active agent explicitly asks for config details
|
|
8
|
-
|
|
9
|
-
## No agent selected
|
|
10
|
-
|
|
11
|
-
After boot, if the user started the chat without naming an agent and has not given a concrete task yet, do not start implementation or workflow routing. First offer these starting lanes:
|
|
12
|
-
|
|
13
|
-
- Simple Plan with `dev` for bounded technical work, small fixes, refactors, or directly verifiable implementation.
|
|
14
|
-
- Pair programming with `deyvin` for continuity, debugging together, or a small validated slice with known context.
|
|
15
|
-
- Briefing with `briefing` to frame and evaluate an early feature idea before committing to a PRD.
|
|
16
|
-
- Product with `product` to start a full feature definition when the user already wants to build a product/feature.
|
|
17
|
-
|
|
18
|
-
## Project knowledge
|
|
19
|
-
|
|
20
|
-
Read `.aioson/learnings/INDEX.md` if it exists. Each line is a project gotcha or recipe with its file path and a one-line summary. Lazy-load individual files only when title/scope matches your current task or files being touched.
|
|
21
|
-
|
|
22
|
-
## Available agents
|
|
3
|
+
## Boot
|
|
4
|
+
1. Check `.aioson/context/project.context.md`
|
|
5
|
+
2. If present, read it before any action
|
|
6
|
+
3. If missing, start with `setup`
|
|
7
|
+
4. Read `.aioson/config.md` only if project context is missing/invalid, setup/routing policy is needed, or the active agent explicitly asks for config details
|
|
8
|
+
|
|
9
|
+
## No agent selected
|
|
10
|
+
|
|
11
|
+
After boot, if the user started the chat without naming an agent and has not given a concrete task yet, do not start implementation or workflow routing. First offer these starting lanes:
|
|
12
|
+
|
|
13
|
+
- Simple Plan with `dev` for bounded technical work, small fixes, refactors, or directly verifiable implementation.
|
|
14
|
+
- Pair programming with `deyvin` for continuity, debugging together, or a small validated slice with known context.
|
|
15
|
+
- Briefing with `briefing` to frame and evaluate an early feature idea before committing to a PRD.
|
|
16
|
+
- Product with `product` to start a full feature definition when the user already wants to build a product/feature.
|
|
17
|
+
|
|
18
|
+
## Project knowledge
|
|
19
|
+
|
|
20
|
+
Read `.aioson/learnings/INDEX.md` if it exists. Each line is a project gotcha or recipe with its file path and a one-line summary. Lazy-load individual files only when title/scope matches your current task or files being touched.
|
|
21
|
+
|
|
22
|
+
## Available agents
|
|
23
23
|
- setup -> `.aioson/agents/setup.md`
|
|
24
24
|
- discovery-design-doc -> `.aioson/agents/discovery-design-doc.md`
|
|
25
25
|
- discover -> `.aioson/agents/discover.md`
|
|
26
|
-
- analyst -> `.aioson/agents/analyst.md`
|
|
27
|
-
- scope-check -> `.aioson/agents/scope-check.md`
|
|
28
|
-
- architect -> `.aioson/agents/architect.md`
|
|
26
|
+
- analyst -> `.aioson/agents/analyst.md`
|
|
27
|
+
- scope-check -> `.aioson/agents/scope-check.md`
|
|
28
|
+
- architect -> `.aioson/agents/architect.md`
|
|
29
29
|
- ux-ui (UI/UX) -> `.aioson/agents/ux-ui.md`
|
|
30
30
|
- product -> `.aioson/agents/product.md`
|
|
31
31
|
- sheldon -> `.aioson/agents/sheldon.md`
|
|
@@ -45,6 +45,7 @@ Read `.aioson/learnings/INDEX.md` if it exists. Each line is a project gotcha or
|
|
|
45
45
|
- orache -> `.aioson/agents/orache.md`
|
|
46
46
|
- design-hybrid-forge -> `.aioson/agents/design-hybrid-forge.md`
|
|
47
47
|
- site-forge -> `.aioson/agents/site-forge.md`
|
|
48
|
+
- forge-run -> `.aioson/agents/forge-run.md`
|
|
48
49
|
|
|
49
50
|
## Rule
|
|
50
51
|
Do not duplicate rules outside `.aioson/`.
|