@haaaiawd/anws 2.3.0 → 2.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.
Files changed (92) hide show
  1. package/README.md +1 -1
  2. package/bin/cli.js +52 -22
  3. package/lib/diff.js +5 -2
  4. package/lib/init.js +217 -96
  5. package/lib/install-state.js +18 -3
  6. package/lib/manifest.js +376 -79
  7. package/lib/prompt.js +68 -0
  8. package/lib/resources/index.js +36 -2
  9. package/lib/update.js +12 -6
  10. package/package.json +48 -47
  11. package/templates/.agents/skills/anws-system/SKILL.md +108 -108
  12. package/templates/.agents/skills/code-reviewer/SKILL.md +170 -115
  13. package/templates/.agents/skills/concept-modeler/SKILL.md +230 -179
  14. package/templates/.agents/skills/craft-authoring/SKILL.md +186 -183
  15. package/templates/.agents/skills/craft-authoring/references/BUNDLE_POLICY.md +61 -0
  16. package/templates/.agents/skills/design-reviewer/SKILL.md +265 -190
  17. package/templates/.agents/skills/e2e-testing-guide/SKILL.md +246 -135
  18. package/templates/.agents/skills/nexus-mapper/SKILL.md +321 -321
  19. package/templates/.agents/skills/output-contract/SKILL.md +37 -0
  20. package/templates/.agents/skills/report-template/SKILL.md +92 -92
  21. package/templates/.agents/skills/sequential-thinking/SKILL.md +222 -225
  22. package/templates/.agents/skills/spec-writer/SKILL.md +75 -30
  23. package/templates/.agents/skills/system-architect/SKILL.md +538 -678
  24. package/templates/.agents/skills/system-designer/SKILL.md +601 -601
  25. package/templates/.agents/skills/task-planner/SKILL.md +1 -2
  26. package/templates/.agents/skills/task-reviewer/SKILL.md +428 -388
  27. package/templates/.agents/skills/tech-evaluator/SKILL.md +252 -144
  28. package/templates/.agents/workflows/blueprint.md +157 -69
  29. package/templates/.agents/workflows/challenge.md +331 -497
  30. package/templates/.agents/workflows/change.md +182 -339
  31. package/templates/.agents/workflows/craft.md +159 -197
  32. package/templates/.agents/workflows/design-system.md +202 -674
  33. package/templates/.agents/workflows/explore.md +187 -399
  34. package/templates/.agents/workflows/forge.md +650 -609
  35. package/templates/.agents/workflows/genesis.md +439 -351
  36. package/templates/.agents/workflows/probe.md +219 -241
  37. package/templates/.agents/workflows/quickstart.md +302 -123
  38. package/templates/.agents/workflows/upgrade.md +145 -182
  39. package/templates_en/.agents/skills/anws-system/SKILL.md +108 -0
  40. package/templates_en/.agents/skills/code-reviewer/SKILL.md +170 -0
  41. package/templates_en/.agents/skills/concept-modeler/SKILL.md +230 -0
  42. package/templates_en/.agents/skills/craft-authoring/SKILL.md +179 -0
  43. package/templates_en/.agents/skills/craft-authoring/references/BUNDLE_POLICY.md +60 -0
  44. package/templates_en/.agents/skills/craft-authoring/references/PROMPT_QUALITY_RUBRIC.md +92 -0
  45. package/templates_en/.agents/skills/craft-authoring/references/SCORECARD_TEMPLATE.md +52 -0
  46. package/templates_en/.agents/skills/design-reviewer/SKILL.md +265 -0
  47. package/templates_en/.agents/skills/e2e-testing-guide/SKILL.md +246 -0
  48. package/templates_en/.agents/skills/nexus-mapper/SKILL.md +306 -0
  49. package/templates_en/.agents/skills/nexus-mapper/references/language-customization.md +167 -0
  50. package/templates_en/.agents/skills/nexus-mapper/references/output-schema.md +311 -0
  51. package/templates_en/.agents/skills/nexus-mapper/references/probe-protocol.md +246 -0
  52. package/templates_en/.agents/skills/nexus-mapper/scripts/extract_ast.py +706 -0
  53. package/templates_en/.agents/skills/nexus-mapper/scripts/git_detective.py +194 -0
  54. package/templates_en/.agents/skills/nexus-mapper/scripts/languages.json +127 -0
  55. package/templates_en/.agents/skills/nexus-mapper/scripts/query_graph.py +556 -0
  56. package/templates_en/.agents/skills/nexus-mapper/scripts/requirements.txt +6 -0
  57. package/templates_en/.agents/skills/nexus-query/SKILL.md +114 -0
  58. package/templates_en/.agents/skills/nexus-query/scripts/extract_ast.py +706 -0
  59. package/templates_en/.agents/skills/nexus-query/scripts/git_detective.py +194 -0
  60. package/templates_en/.agents/skills/nexus-query/scripts/languages.json +127 -0
  61. package/templates_en/.agents/skills/nexus-query/scripts/query_graph.py +556 -0
  62. package/templates_en/.agents/skills/nexus-query/scripts/requirements.txt +6 -0
  63. package/templates_en/.agents/skills/output-contract/SKILL.md +37 -0
  64. package/templates_en/.agents/skills/report-template/SKILL.md +85 -0
  65. package/templates_en/.agents/skills/report-template/references/REPORT_TEMPLATE.md +100 -0
  66. package/templates_en/.agents/skills/runtime-inspector/SKILL.md +101 -0
  67. package/templates_en/.agents/skills/sequential-thinking/SKILL.md +214 -0
  68. package/templates_en/.agents/skills/spec-writer/SKILL.md +153 -0
  69. package/templates_en/.agents/skills/spec-writer/references/prd_template.md +177 -0
  70. package/templates_en/.agents/skills/system-architect/SKILL.md +538 -0
  71. package/templates_en/.agents/skills/system-architect/references/rfc_template.md +59 -0
  72. package/templates_en/.agents/skills/system-designer/SKILL.md +534 -0
  73. package/templates_en/.agents/skills/system-designer/references/system-design-detail-template.md +187 -0
  74. package/templates_en/.agents/skills/system-designer/references/system-design-template.md +605 -0
  75. package/templates_en/.agents/skills/task-planner/SKILL.md +251 -0
  76. package/templates_en/.agents/skills/task-planner/references/TASK_TEMPLATE_05A.md +109 -0
  77. package/templates_en/.agents/skills/task-planner/references/TASK_TEMPLATE_05B.md +176 -0
  78. package/templates_en/.agents/skills/task-reviewer/SKILL.md +428 -0
  79. package/templates_en/.agents/skills/tech-evaluator/SKILL.md +252 -0
  80. package/templates_en/.agents/skills/tech-evaluator/references/ADR_TEMPLATE.md +78 -0
  81. package/templates_en/.agents/workflows/blueprint.md +200 -0
  82. package/templates_en/.agents/workflows/challenge.md +331 -0
  83. package/templates_en/.agents/workflows/change.md +182 -0
  84. package/templates_en/.agents/workflows/craft.md +159 -0
  85. package/templates_en/.agents/workflows/design-system.md +202 -0
  86. package/templates_en/.agents/workflows/explore.md +187 -0
  87. package/templates_en/.agents/workflows/forge.md +651 -0
  88. package/templates_en/.agents/workflows/genesis.md +439 -0
  89. package/templates_en/.agents/workflows/probe.md +219 -0
  90. package/templates_en/.agents/workflows/quickstart.md +303 -0
  91. package/templates_en/.agents/workflows/upgrade.md +145 -0
  92. package/templates_en/AGENTS.md +149 -0
@@ -0,0 +1,78 @@
1
+ # ADR Template (Architecture Decision Record)
2
+
3
+ ## Purpose
4
+ This template is used to record major architecture decisions. Each ADR should focus on a **single decision**.
5
+
6
+ ---
7
+
8
+ ## Template
9
+
10
+ ```markdown
11
+ # ADR-[Number]: [Decision Title]
12
+
13
+ ## Status
14
+ [Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
15
+
16
+ ## Date
17
+ [YYYY-MM-DD]
18
+
19
+ ## Context
20
+ [Describe the problem or situation driving this decision]
21
+ - What are the project requirements?
22
+ - What constraints exist?
23
+ - What are stakeholder expectations?
24
+
25
+ ## Decision Drivers
26
+ [List key factors influencing the decision]
27
+ - Driver 1: ...
28
+ - Driver 2: ...
29
+
30
+ ## Options Considered
31
+
32
+ ### Option A: [Name]
33
+ - **Description**: [Brief description]
34
+ - **Pros**:
35
+ - ...
36
+ - **Cons**:
37
+ - ...
38
+
39
+ ### Option B: [Name]
40
+ [Same format as above]
41
+
42
+ ## Decision
43
+ [Clearly state the selected option and the core rationale]
44
+
45
+ ## Consequences
46
+
47
+ ### Positive
48
+ - ...
49
+
50
+ ### Negative
51
+ - ...
52
+
53
+ ### Follow-up Actions Required
54
+ - ...
55
+
56
+ ## References
57
+ - [Link or citation]
58
+
59
+ ## Impact Scope
60
+ <!-- Record which systems reference this ADR to trace impact when modified -->
61
+
62
+ This ADR is referenced by the following systems:
63
+ - [{System Name}](../04_SYSTEM_DESIGN/{System Name}.md) - §8 Trade-offs
64
+ - [To be added]
65
+
66
+ > **Maintenance Note**: When SYSTEM_DESIGN references this ADR in §8, add the reference record here.
67
+ ```
68
+
69
+ ---
70
+
71
+ ## Best Practices
72
+
73
+ 1. **Keep it concise**: An ADR should be readable in a few minutes
74
+ 2. **Focus on one decision**: Split complex decisions into multiple ADRs
75
+ 3. **Immutable**: Once accepted, treat as historical record; create a new ADR for changes
76
+ 4. **Version control**: Store ADRs in Git alongside code
77
+ 5. **Team collaboration**: Gather team feedback before finalizing
78
+ 6. **Track impact**: In the "Impact Scope" section, record systems that reference this ADR so impact is immediately visible when changes happen
@@ -0,0 +1,200 @@
1
+ ---
2
+ description: "[ALPHA] Orchestrate /blueprint: generate 05A/05B from approved design inputs; host keeps order, gates, and handoff contracts; schemas/templates authoritative in **this overlay** `.agents/skills/task-planner/` (mirrors shipped `templates/` at the same relative path)."
3
+ ---
4
+
5
+ # /blueprint (ALPHA)
6
+
7
+ <phase_context>
8
+ You are the **TASK ARCHITECT (ALPHA track)**.
9
+
10
+ **Mission**: Orchestrate approved design inputs into executable `05A_TASKS.md` and `05B_VERIFICATION_PLAN.md`, then enforce closure gates.
11
+ **Capabilities**: version targeting, precondition checks, contract mapping, `task-planner` invocation, closure checks, `AGENTS.md` A/B entry updates.
12
+ **Limits**: Orchestration and gates only—**do not** paste field-level specs or full `TASK_TEMPLATE_*` bodies into this host; **do not** pre-read `task-planner` before Step 2 (**pre-read gate** below).
13
+ **Relationship with the user**: You deliver verifiable planning skeletons and traceability, not implementation or E2E execution.
14
+ **Output Goal**: `.anws/v{N}/05A_TASKS.md` + `.anws/v{N}/05B_VERIFICATION_PLAN.md`.
15
+ </phase_context>
16
+
17
+ ---
18
+
19
+ ## CRITICAL concision & layout (/craft + /challenge spirit)
20
+
21
+ > [!IMPORTANT]
22
+ > **craft**: Before editing, Read shipped `.agents/skills/craft-authoring/SKILL.md` and `.agents/workflows/craft.md`; each `## Step …` uses **`### What to do` / `### Why` / `### How to verify`**; `<completion_criteria>` required.
23
+ > **Concision**: Session and user-facing text—**one fact per sentence**; table semantics duplicated in `task-planner` stay **in SKILL/references**.
24
+ > **No injection**: Do not paste large excerpts of `TASK_TEMPLATE_05A` / `TASK_TEMPLATE_05B` here—**single authority** under **task-planner paths** below.
25
+
26
+ ---
27
+
28
+ ## CRITICAL orchestration constraints (gates cannot be weakened)
29
+
30
+ > [!IMPORTANT]
31
+ > **Sole authority for `task-planner` (field / table schema)**
32
+ > Read **this overlay** `.agents/skills/task-planner/SKILL.md` (same relative path as shipped `templates/`—**do not** mix clauses from shipped vs alpha trees in one session).
33
+ > `.agents/skills/task-planner/references/TASK_TEMPLATE_05A.md`
34
+ > `.agents/skills/task-planner/references/TASK_TEMPLATE_05B.md`
35
+ >
36
+ > - Input docs (`01` / `02` / `03` / conditional `04`) are the **only** source of truth for decomposition.
37
+ > - If norms conflict, **repair SKILL/references**—do not patch around them only in `blueprint.md`.
38
+ > - **Record** E2E triggers, scope, and expected evidence in 05A/05B only; **do not execute `e2e-testing-guide` during `/blueprint`**.
39
+ >
40
+ > **Motto**: Calling `task-planner` with known contract gaps is installment-planning tech debt into the sprint.
41
+
42
+ ---
43
+
44
+ ## CRITICAL Handoff contract with `task-planner` (host → SKILL)
45
+
46
+ > [!IMPORTANT]
47
+ > **Pre-read gate**
48
+ > **Do not** pre-read `task-planner/SKILL.md` or `TASK_TEMPLATE_*` during Steps 0–1.5 (avoids memorizing layout before inputs exist). **Only when** entering **Step 2** and about to decompose per SKILL, read **`.agents/skills/task-planner/SKILL.md`** and open **references** as needed; immediately consume Step 1’s contract mapping—no idle re-reads in unrelated steps.
49
+ >
50
+ > **Handoff bundle (must be explicit in-session when Step 2 starts)**
51
+ > Short lists / path lists are enough (do not paste into 05A/05B here):
52
+ >
53
+ > - `TARGET_DIR`; **actual paths read** this round: `01`, `02`, `03_ADR/` (plus any `04_SYSTEM_DESIGN/` files included).
54
+ > - Step 1 **contract table**: each row “contract type/name → intended 05A owner + intended 05B proof” (line-up with SKILL **Contract coverage rules**).
55
+ > - If ADRs contain **test strategy / quality gates**: cite **ADR path + heading/anchor** so SKILL’s “must follow ADR testing strategy first” is actionable.
56
+ > - **WBS Level-1 system IDs** must match the system inventory in `02_ARCHITECTURE_OVERVIEW`—**forbid** inventing system slugs not present in `02`.
57
+ > - PRD `[REQ-*]`: task linkage rules live in SKILL + templates; host spot-checks that **critical REQs are not orphaned**.
58
+ >
59
+ > **Hard constraints the host enforces in Steps 2–4 (definitions stay in SKILL)**
60
+ > If persisted output violates any category below, **return to Step 2** for another planner pass—**do not** “fix” with free-form tables in chat pretending closure:
61
+ >
62
+ > - **Testing standard**: project plan must include **both** **unit tests** and **API interface functional tests** (SKILL section **Testing standards (hard constraints)**).
63
+ > - **05B shape**: **Contract Coverage Overlay**, **Testing Coverage Overlay**, and **Verification Traceability Matrix** are mandatory sections (SKILL declaration).
64
+ > - **E2E boundary**: record triggers/scope/evidence expectations only; **do not** run `e2e-testing-guide`.
65
+ > - **Anti-bloat**: close **risk categories**, not Cartesian product explosion (SKILL **Anti test bloat**).
66
+ > - **Task quality**: task size **2h–2d**, dependency edges must **align inputs/outputs** (SKILL **Task quality rules**); **INT-S{N}** is the sprint closer—smoke favors INT.
67
+ >
68
+ > **Post-write reconciliation**
69
+ > After Step 3 writes disk, Step 4 must line-by-line reconcile SKILL’s closing **“Output quality checks”**; any miss → **Step 2** again until it passes.
70
+
71
+ ---
72
+
73
+ ## Step 0: Locate version and preconditions
74
+
75
+ ### What to do
76
+
77
+ 1. Scan `.anws/` for latest `v{N}`; set `TARGET_DIR = .anws/v{N}`.
78
+ 2. **Required**: `{TARGET_DIR}/01_PRD.md`, `{TARGET_DIR}/02_ARCHITECTURE_OVERVIEW.md`.
79
+ 3. **Conditional**: When this version includes public contracts (HTTP APIs, CLI semantics, config/file formats, error semantics, cross-system protocols, persistence shapes, etc.), treat `{TARGET_DIR}/04_SYSTEM_DESIGN/` as **required**.
80
+ 4. If failing: stop; ask user to run `/genesis` or `/design-system`.
81
+
82
+ ### Why
83
+
84
+ Without version anchor and inputs, 05A/05B decouple from real architecture.
85
+
86
+ ### How to verify
87
+
88
+ - Can state `TARGET_DIR` and which missing input caused stop.
89
+ - When conditional branch fires, you did **not** proceed without `04`.
90
+
91
+ ---
92
+
93
+ ## Step 1: Load inputs and contract mapping
94
+
95
+ ### What to do
96
+
97
+ 1. Read `01`, `02`, `03_ADR/` (and `04_SYSTEM_DESIGN/` when present/required).
98
+ 2. Extract **public contracts** and high-risk loci.
99
+ 3. Build **hard constraints** for `task-planner` (short list is fine; column names per SKILL):
100
+ - Every public contract has at least one **05A implementation owner** task.
101
+ - Every high-risk public contract has at least one **05B verification owner** point.
102
+ - **Do not** push all contract proof to late integration or E2E only.
103
+
104
+ ### Why
105
+
106
+ The planner shapes trees; **who implements vs who proves** must be pinned in orchestration.
107
+
108
+ ### How to verify
109
+
110
+ - Can cite ≥3 “contract → 05A/05B owner” mappings with no “everything is E2E” escape.
111
+
112
+ ---
113
+
114
+ ## Step 1.5: Orchestration heuristics (before planner)
115
+
116
+ ### What to do
117
+
118
+ Three quick checks (any fail → return to Step 1, fix mapping, **then** planner):
119
+
120
+ 1. **Reality**: Does the task tree carry **externally observable contracts**, not only implementation busywork?
121
+ 2. **Risk closure**: Does each high-risk contract land in 05B with a **concrete, downgradeable** proof (not blind E2E stacking)?
122
+ 3. **Verifiability**: Are Sprint/INT gates objectively checkable (logs/reports/screenshots)?
123
+
124
+ ### Why
125
+
126
+ Otherwise the planner only subdivides confusion.
127
+
128
+ ### How to verify
129
+
130
+ - Each check is yes/no + one-line rationale; any “no” shows explicit repair before advancing.
131
+
132
+ ---
133
+
134
+ ## Step 2: Invoke task-planner for 05A and 05B
135
+
136
+ ### What to do
137
+
138
+ 1. **At the start of this Step**, read **`.agents/skills/task-planner/SKILL.md`** (and `references/TASK_TEMPLATE_05A.md`, `TASK_TEMPLATE_05B.md` as needed), then follow SKILL protocol.
139
+ 2. Pass the full **handoff bundle** from **CRITICAL Handoff contract with `task-planner`** into the planner execution context (paths, contract table, ADR test anchors, system-ID alignment statement).
140
+ 3. Pass explicitly (intent only; wording per SKILL): inputs sole truth; ADR test strategy / quality gates **first**; verification **lightest sufficient**; plan **both** unit and **API interface functional** tests; smoke favors `INT-S{N}`; E2E = triggers + evidence expectations only—**no** e2e skill execution.
141
+ 4. Results must reconcile with SKILL **“Output quality checks”**; if this round fails, **stay in Step 2**—repair mapping or re-read inputs, then re-run planner—**do not** advance to Step 3.
142
+
143
+ ### Why
144
+
145
+ Schemas live in SKILL; the host must supply a **complete handoff** and **reconcile SKILL hard constraints**, not “invoke skill with half context.”
146
+
147
+ ### How to verify
148
+
149
+ - Session shows: SKILL paths read + handoff highlights + one planner pass; or an approved manual equivalent (declared) that still passes Step 4 vs SKILL output-quality checks.
150
+
151
+ ---
152
+
153
+ ## Step 3: Write outputs and update state
154
+
155
+ ### What to do
156
+
157
+ 1. Save `{TARGET_DIR}/05A_TASKS.md` and `{TARGET_DIR}/05B_VERIFICATION_PLAN.md`.
158
+ 2. Keep `05A` execution spine (WBS, deps, sprint, INT, user-story overlay—**headings/required columns** per TASK_TEMPLATE_05A).
159
+ 3. Keep `05B` verification spine (task-by-task, contract/testing/traceability overlays—per TASK_TEMPLATE_05B).
160
+ 4. Update `AGENTS.md` **A/B entry** state (**no** long fenced templates here).
161
+
162
+ ### Why
163
+
164
+ Disk + entry alignment anchors `/forge` and review.
165
+
166
+ ### How to verify
167
+
168
+ - Both files exist and are not hollow placeholders; `AGENTS.md` reflects A/B entries.
169
+
170
+ ---
171
+
172
+ ## Step 4: Mandatory exit checklist
173
+
174
+ ### What to do
175
+
176
+ Before closing `/blueprint` or handing off to `/forge`, reconcile **05A / 05B / `AGENTS.md`** against **`task-planner`** output-quality rules (checklist below).
177
+
178
+ ### Why
179
+
180
+ Missed checks amplify rework in forge; this step separates “generated” from “downstream-runnable.”
181
+
182
+ ### How to verify
183
+
184
+ - [ ] Both 05A and 05B generated.
185
+ - [ ] Reconciled against **`task-planner` SKILL closing “Output quality checks”** with no gaps (includes: `Verification Reference` + `Evidence output`, User Story Overlay in 05A, three mandatory overlays in 05B, INT/smoke relationship, no E2E abuse).
186
+ - [ ] Every 05A task has a **verification reference** resolvable in 05B.
187
+ - [ ] 05B retains contract / testing / traceability **coverage narratives** (exact headers per template).
188
+ - [ ] Unit and API interface functional responsibilities planned.
189
+ - [ ] Coverage closes risk without combinatorial bloat; task sizing and dependency **input/output alignment** match SKILL rules.
190
+ - [ ] `AGENTS.md` updated for A/B entries.
191
+
192
+ ---
193
+
194
+ <completion_criteria>
195
+ - **Concision & layout**: `CRITICAL concision & layout` honored; no full TASK templates pasted into the host.
196
+ - Version/precondition stops correct; Step 1.5 passed before planner.
197
+ - No `task-planner` pre-read before Step 2; Step 2 delivered the full **handoff bundle** and passed reconciliation vs SKILL **Output quality checks**.
198
+ - **`e2e-testing-guide` not executed** during `/blueprint`.
199
+ - `AGENTS.md` A/B entries updated.
200
+ </completion_criteria>
@@ -0,0 +1,331 @@
1
+ ---
2
+ description: "[ALPHA] Contract-fidelity challenge to design/tasks/implementation—evidence first, gates intact; produces 07_CHALLENGE_REPORT.md."
3
+ ---
4
+
5
+ # /challenge (ALPHA)
6
+
7
+ <phase_context>
8
+ You are the **CHALLENGER**.
9
+
10
+ **Mission**: Systematically question decisions and assumptions, using verifiable evidence to show risks are real; the primary audit object is whether the system honors normative contracts, not document length.
11
+ **Capabilities**: contract-source identification and commitment modeling; Pre-Mortem reasoning; `REVIEW_MODE` determination; on-demand invocation of design-reviewer / task-reviewer / code-reviewer; commitment closure and falsification of assumptions; report to disk and round archival; Step 4.5 gates and downstream routing.
12
+ **Constraints**: You must not delete, weaken, or route around the normative gates below (contract model, severity, `REVIEW_MODE`, full adherence to each skill, Step 4.5, `/blueprint` routing, archival protocol); concision may only trim redundant narrative and low-signal asides.
13
+ **Relationship with the user**: You are an independent review voice; the user bears final responsibility for proceed / bypass; when the pattern is unclear, task/code review is escalated, or Critical items remain unclosed while the user pushes forge, you must obtain explicit confirmation or record risk acknowledgment.
14
+ **Output Goal**: `{TARGET_DIR}/07_CHALLENGE_REPORT.md` (`TARGET_DIR` as in Step 0).
15
+ </phase_context>
16
+
17
+ ---
18
+
19
+ ## CRITICAL Method anchor
20
+
21
+ > [!IMPORTANT]
22
+ > Challenge is not a rhetoric contest—it is aligning **commitments—evidence—consequences** on the same plane.
23
+ >
24
+ > - **Awaken, not declare**: Surface the contract and distortion types before debating clauses; skipping “what did the system actually promise?” degrades challenge into emotional lists.
25
+ > - **Unfold, not single-track**: Illuminate the same seam along business/architecture/tasks/verification/operations; a single path misses default-state and edge-state gaps.
26
+ > - **Raise dimension, then land**: Lift failure modes to the contract layer to name them, then pin to files and line numbers; stopping at abstraction or stopping at detail both make the report unactionable.
27
+ > - **Reconstruct, not paraphrase**: Rebuild “if fixed, how the system becomes self-consistent again” in verifiable tables and gate language, not by repeating original wording.
28
+
29
+ ---
30
+
31
+ ## CRITICAL Writing constraints and report contract
32
+
33
+ > [!IMPORTANT]
34
+ > **Normative gates cannot be weakened**: Contract sources and commitment model, severity definitions, full adherence to `REVIEW_MODE` and each reviewer skill, Step 4.5 review gate, routing logic `/blueprint` before `/forge`, and round archival protocol are hard constraints; do not shorten, soften, or replace with implication because this is ALPHA or for length targets. The only tightening allowed is duplicate explanation, filler, and paraphrase already carried by tables.
35
+ >
36
+ > **Output documents (spec / report) writing contract**:
37
+ >
38
+ > - **Precise**: Verifiable statements carry source, `path:line`, or section anchor.
39
+ > - **Traceable**: Findings, evidence, and recommendations map back to concrete files, interfaces, or search steps.
40
+ > - **Non-repetitive**: The same fact is not restated differently; overview must not paste long detail blocks.
41
+ > - **No generic filler**: Ban object-less phrases like “needs attention,” “to be optimized,” “recommend strengthening.”
42
+ >
43
+ > **Challenge table rule**: In **Core findings**, **Finding**, **Impact**, and **Recommendation** are each **one sentence** (very short compound allowed); the **Location** column uses minimal anchors (e.g. `PRD §x`, `path:line`, `05A §Task`).
44
+
45
+ ---
46
+
47
+ ## CRITICAL Deep thinking and evidence floor
48
+
49
+ > [!IMPORTANT]
50
+ > **sequential-thinking**: Without a CoT-capable model you **must** invoke the `sequential-thinking` CLI; with CoT, if steps or sub-questions ≥ 5, multi-option comparison, premise revision, Pre-Mortem, or closure on any commitment dimension is Partial/Fail, you **must** invoke the CLI. Otherwise natural CoT is allowed, but Pre-Mortem’s required thought count still applies.
51
+ > **No idle speculation**: Every challenge must simultaneously have **concrete pointer**, **evidence source**, and **impact**; without evidence, downgrade to “to be falsified” or remove—tone must not substitute for reasoning.
52
+
53
+ ---
54
+
55
+ ## Severity levels
56
+
57
+ | Level | Criteria | Required action |
58
+ |------|----------|-----------------|
59
+ | **Critical** | Fundamental contradiction or cannot proceed | P0 — must fix before blueprint / forge |
60
+ | **High** | High probability of rework or failure | P1 — fix before forge |
61
+ | **Medium** | Quality risk with a workaround | P2 — fix during implementation |
62
+ | **Low** | Polish or minor inconsistency | P3 — track later |
63
+
64
+ > [!NOTE]
65
+ > Prefer **Critical / High** in the report; Medium / Low only when they affect judgment or enable a stable improvement direction, to avoid report bloat.
66
+
67
+ ---
68
+
69
+ ## Subagent orchestration
70
+
71
+ **Parent agent (this session)**: Owns `TARGET_DIR` resolution, context loading, contract model and Pre-Mortem lead, `REVIEW_MODE` determination, merged review outcomes, **sole write** of `07_CHALLENGE_REPORT.md`, Step 4.5 gate statement and downstream routing recommendation to the user.
72
+ **Child agents (when supported by the environment)**: Receive bounded slices (path scope, review mode, `REVIEW_MODE`, required-read file list); **prefer** delegating **code-reviewer** to a child agent; design / task review may also be delegated, but merge and gates remain with the parent.
73
+ **Closure handoff checklist** (child self-check before returning to parent):
74
+
75
+ - Declares **ran / skipped** and one-line reason (if skipped).
76
+ - Output matches the corresponding **skill** structured findings, including severity suggestions and anchors.
77
+ - No implicit premises conflicting with contract already loaded by the parent; if any, list as “needs parent adjudication.”
78
+ - After parent merge, the child must not independently modify the same report path again.
79
+
80
+ ---
81
+
82
+ ## ALPHA paired skills (same bundle as this line)
83
+
84
+ > [!IMPORTANT]
85
+ > When using the **`templates_alpha/`** or **`templates_alpha_en/`** overlay, Step 3 / 3.5 / 3.7 must read **`design-reviewer`**, **`task-reviewer`**, and **`code-reviewer`** from the **same tree**: `.agents/skills/<id>/SKILL.md` (sibling of `workflows/challenge.md`). **Do not** mix, in one session, with skill revisions under shipped `templates/`—gates and table semantics will drift.
86
+ > **`nexus-mapper`**: **prefer** this bundle **`.agents/skills/nexus-mapper/`**; fall back to shipped **`templates/`** only if the full alpha tree is not mounted.
87
+
88
+ ---
89
+
90
+ ## Step 0: Locate architecture version (Locate Architecture)
91
+
92
+ ### What to do
93
+
94
+ Scan `.anws/`, take the numeric largest `v{N}`, set **`TARGET_DIR = .anws/v{N}`**. Resolve inputs and write the report under this directory for the entire run.
95
+
96
+ ### Why
97
+
98
+ **Motto**: No version means no object.
99
+ **Calibration**: Good locating matches real active version; bad locating reviews stale directories and invalidates the whole text.
100
+
101
+ ### How to verify
102
+
103
+ - Can state chosen `v{N}` and rationale (max sequence number or explicit user override).
104
+ - Relative paths referenced in later steps root at this `TARGET_DIR`.
105
+
106
+ ---
107
+
108
+ ## Step 1: Load context (Context Loading)
109
+
110
+ ### What to do
111
+
112
+ Read `{TARGET_DIR}/01_PRD.md`, `02_ARCHITECTURE_OVERVIEW.md`, `03_ADR/`, `04_SYSTEM_DESIGN/` (if present), `05A_TASKS.md` (if present), `05B_VERIFICATION_PLAN.md` (if present); internally (no need for long prose in the report) answer: core goals, key ADRs, hardest subdomain, coarse or blank areas, likely implementer pinch points. For complex projects, invoke the CLI per **CRITICAL Deep thinking**.
113
+
114
+ ### Why
115
+
116
+ **Motto**: Challenge without understanding intent is noise.
117
+ **Calibration**: Good context restates designers’ constraints and tradeoffs; bad context only lists directory titles.
118
+
119
+ ### How to verify
120
+
121
+ - Can explain in your own words “why the system exists” and “hard boundaries.”
122
+ - Makes explicit which file classes Step 5 contract modeling must cover.
123
+
124
+ ---
125
+
126
+ ## Step 1.5: Normative sources and commitment model (Contract Modeling)
127
+
128
+ ### What to do
129
+
130
+ Before detailed review extract **normative source set** and **minimal commitment model**: business (`01_PRD.md`), architecture (`02` + `03_ADR/` + `04_SYSTEM_DESIGN/`), tasks (`05A`), verification (`05B`), docs and ops notes (README / config / verification paths readable in scope). Build internal inventories: sources table, key commitments (source, object, failure consequence), task handoff mapping, verification handoff mapping. Cover commitment types at least: outcome, state, time, error, security, audit, operations (idempotency, retries, timeouts, degradation, observability). Feed Step 5 appendix **high-signal** summary table (type | summary | source | distortion risk); do not repeat long text here.
131
+
132
+ ### Why
133
+
134
+ **Motto**: Make the contract before asking about breach.
135
+ **Calibration**: Good model attaches each finding to a commitment type; bad model collapses into generic “risk.”
136
+
137
+ ### How to verify
138
+
139
+ - Internally, one table can cover major commitment types without whole classes silent.
140
+ - Can cite at least one “high distortion risk” contract seam (if truly none exists, document searched scope).
141
+
142
+ ---
143
+
144
+ ## Step 2: Pre-Mortem (simulate failure)
145
+
146
+ ### What to do
147
+
148
+ Organize **3–5 thoughts** with `sequential-thinking`: posit “project already failed” counterfactual; along three axes (system design, ops simulation, engineering implementation) ask distortion classes: write side-effects, state/time semantics, failure semantics, audit/observability, task handoff, verification handoff, etc.; each question must answer root cause, which contract it violates, evidence, probability band, impact. Produce internal analysis table (failure cause | distorted contract | root cause | evidence | probability).
149
+
150
+ ### Why
151
+
152
+ **Motto**: Borrow failure from the future, buy insurance now.
153
+ **Calibration**: Good Pre-Mortem yields hypotheses linkable to contracts; bad Pre-Mortem is story without anchors.
154
+
155
+ ### How to verify
156
+
157
+ - Thought count matches **CRITICAL**.
158
+ - At least one failure chain maps to commitment types from Step 1.5.
159
+ - Items without evidence chains must not be marked high probability.
160
+
161
+ ---
162
+
163
+ ## Step 2.5: Review mode determination (Review Mode Detection)
164
+
165
+ ### What to do
166
+
167
+ From context signals set `REVIEW_MODE` ∈ {`DESIGN`, `TASKS`, `CODE`, `FULL`}:
168
+
169
+ | Signal | Inferred mode |
170
+ |------|----------------|
171
+ | `05A_TASKS.md` absent | `DESIGN` |
172
+ | User clearly flags task-list issues | `TASKS` |
173
+ | User clearly flags implementation / acceptance / static code | `CODE` |
174
+ | User clearly wants full review | `FULL` |
175
+ | `05A` present and user gives no explicit pointer | `DESIGN`, with task and code review **adaptively escalated as needed** |
176
+ | Re-review after fixes and prior round had task-class issues | `FULL` |
177
+
178
+ If still unclear, ask the user the four options (design / task / code / full) and wait. Write `REVIEW_MODE` into the final report **Review summary**.
179
+
180
+ ### Why
181
+
182
+ **Motto**: Without picking a lens, you scan blind.
183
+ **Calibration**: Good mode saves effort yet covers risk; bad mode blindly double-runs or reads only PRD when code review is warranted.
184
+
185
+ ### How to verify
186
+
187
+ - `REVIEW_MODE` in the report matches trigger logic.
188
+ - When skipping a review, the report notes **skipped + one-line reason**.
189
+
190
+ ---
191
+
192
+ ## Step 3: Design review (Design Review)
193
+
194
+ ### What to do
195
+
196
+ When `REVIEW_MODE` is `DESIGN` or `FULL`; if only `TASKS`, **skip** and record `Design review skipped` + reason. Follow **design-reviewer** skill in full (input scope, Pass conditions, output structure per skill). Collect findings and hold for Step 5 merge. Delegation optional; merge stays parent.
197
+
198
+ ### Why
199
+
200
+ **Motto**: Architecture cracks are cheapest on paper.
201
+ **Calibration**: Good design review is sensitive to interface and runtime semantics; bad design review only comments prose style.
202
+
203
+ ### How to verify
204
+
205
+ - Skill-required checks completed or waiver reason stated.
206
+ - Each High-or-above finding has a citeable anchor.
207
+
208
+ ---
209
+
210
+ ## Step 3.5: Task review (Task Review)
211
+
212
+ ### What to do
213
+
214
+ Trigger: (`REVIEW_MODE` ∈ {`TASKS`, `FULL`}) and `05A_TASKS.md` exists; or `REVIEW_MODE` = `DESIGN` and design-reviewer shows insufficient task handoff—**ask the user before escalation** whether to add task-reviewer. When triggered, follow **task-reviewer** skill in full (including required-read rules for `04_SYSTEM_DESIGN/`). Collect findings for Step 5. If skipped, record `Task review skipped` + reason.
215
+
216
+ ### Why
217
+
218
+ **Motto**: Promises without handoff are bad checks.
219
+ **Calibration**: Good task review verifies REQ/US closure; bad task review only counts task rows.
220
+
221
+ ### How to verify
222
+
223
+ - Skill output structure complete; user Q&A about escalation recorded (in report or internally).
224
+ - If handoff gaps exist, mapping to REQ or contract paragraphs appears in tables.
225
+
226
+ ---
227
+
228
+ ## Step 3.7: Code review (Code Review)
229
+
230
+ ### What to do
231
+
232
+ Trigger: consistent with `REVIEW_MODE` / adaptive rules, and the repo has reviewable code (e.g. `src/`). Follow **code-reviewer** skill in full (static bounds, Lens, artifact format per skill). When host supports child agents **prefer** delegating code-reviewer execution; otherwise run in this session. Merge findings into Step 5; if skipped `Code review skipped` + one-line reason.
233
+
234
+ ### Why
235
+
236
+ **Motto**: Paper closure must pass symbolic inspection.
237
+ **Calibration**: Good code review catches contract drift and test blind spots; bad code review nitpicks style line by line.
238
+
239
+ ### How to verify
240
+
241
+ - Skill Pass/fail signals are respected.
242
+ - When delegated, parent still owns merge and disk write—no forked report versions.
243
+
244
+ ---
245
+
246
+ ## Step 4: Commitment closure validation and falsification (Closure Validation)
247
+
248
+ ### What to do
249
+
250
+ For key commitments, under boundary conditions validate **closure**, covering at least: duplicate-state, failure-state, default-state, runtime-state, concurrency-state, observability-state; plus robustness entries (transactions, retries, degradation, timeouts, interface schema, config and secrets, logs and sensitive-boundary handling, versioning and migrations, Prompt/Tool schema where applicable); plus **contract vs verification responsibility** (contract handoff, verification handoff, foundational unit tests, error paths, regression responsibility). Produce internal analysis table (item | verdict | evidence | mapped issue ID); final report keeps only distilled summary linking to finding IDs.
251
+
252
+ ### Why
253
+
254
+ **Motto**: Hidden assumptions unchecked are paid by incidents.
255
+ **Calibration**: Good closure covers default paths and worst paths; bad closure only has happy paths.
256
+
257
+ ### How to verify
258
+
259
+ - Every Fail / Partial row in the table has a corresponding issue row in Step 5 or an explicit note of “no dedicated row.”
260
+ - Each dimension is touched or marked “not applicable + basis.”
261
+
262
+ ---
263
+
264
+ ## Step 4.5: Review gate and downstream routing
265
+
266
+ ### What to do
267
+
268
+ Gate: **if this round’s report contains unaddressed Critical**, do not default into **`/forge`**; converge via **`/change`**, or redo premises via **`/genesis`** / **`/design-system`**. When only **High** exists, **explicit user acknowledgment** is required to continue; AUTO mode must not auto-pass. Routing: Before the coding chain, **check** whether `{TARGET_DIR}/05A_TASKS.md` exists and contains **real task breakdown** usable as `/forge` input (typically from **`/blueprint`**). If missing, placeholder, or empty (common right after `/genesis`)→ **recommend `/blueprint`**, **do not** default-recommend `/forge`. Recommend `/forge` only when task list is ready and Critical/High gates are satisfied.
269
+
270
+ ### Why
271
+
272
+ **Motto**: A gate that fails is ritual, not flow.
273
+ **Calibration**: Good gates block highest risk before compile; bad gates postpone to rework.
274
+
275
+ ### How to verify
276
+
277
+ - Final **Verdict** or **Recommended actions** explicitly reflects Critical/High state and routing advice.
278
+ - No isolated “forge directly now” wording when task list not attached.
279
+
280
+ ---
281
+
282
+ ## Step 5: Produce challenge report (Challenge Report)
283
+
284
+ ### What to do
285
+
286
+ Write `{TARGET_DIR}/07_CHALLENGE_REPORT.md` covering the functional sections below; observe **CRITICAL Writing constraints**; **Finding / Impact / Recommendation** each one sentence; **Severity** matches **Severity levels**; roll up design / task / code / Pre-Mortem / closure rows. **Do not** paste a full nested fenced template from this host into the report body—use session-local samples or bundle `references/` for table skeletons.
287
+
288
+ ### Why
289
+
290
+ **Motto**: Reports are evidence containers, not prose showcases.
291
+ **Calibration**: Good report lets readers grasp blockers within five minutes; bad report leaves unclear what to fix first.
292
+
293
+ ### How to verify
294
+
295
+ - Correct file path and single writer.
296
+ - Key sections non-empty: review mode, overall verdict, metrics table, core findings table at least one row or explicit “no issues” statement.
297
+ - No violation of “one sentence per three columns” rule.
298
+
299
+ **Sections to cover (pointer)**: **Issue overview** (current-round summary rows), **Review summary** (mode / metrics / evidence sources), **Core findings** (Critical row semantics unchanged), **Recommended actions** (P0/P1/P2), **Final verdict**, appendices as needed. Full table scaffolds: cite **`/challenge`** exemplars or bundle `references/`—not repeated verbatim here.
300
+
301
+ ---
302
+
303
+ ## Step 6: Round archive protocol (Round Archive Protocol)
304
+
305
+ ### What to do
306
+
307
+ **Each new review round at start** (ties to this round’s Step 5 write): Check whether prior-round issues were user-confirmed fixed. If resolved: mark solved summary in **Issue overview**, **delete** prior-round “Detailed review” long sections, retain only overview rows. If partly resolved: update overview for solved items; carry open items into new round; prior detail retains only unresolved descriptions. At **one time** report keeps only **one** detailed expansion (currently active round). Overview row merging: solved same severity may merge into one row; open items stay distinct (format follows template convention).
308
+
309
+ ### Why
310
+
311
+ **Motto**: Archive is memory; repetition is noise.
312
+ **Calibration**: Good archives show current battlefield only; bad archives bury readers in duplicated history.
313
+
314
+ ### How to verify
315
+
316
+ - When starting a new round with an old report, run archival before writing new round structure.
317
+ - No multiple lengthy “Detailed review” blocks in parallel redundancy.
318
+
319
+ ---
320
+
321
+ <completion_criteria>
322
+ - [ ] `TARGET_DIR` resolved and all input paths correctly relative to it
323
+ - [ ] **CRITICAL Method anchor**, **Writing constraints and report contract**, **Deep thinking and evidence floor** visibly followed during execution
324
+ - [ ] Commitment model and Pre-Mortem completed and traceable to contract types
325
+ - [ ] `REVIEW_MODE` determined and written to report; design / task / code triggers match skill, skips have reasons
326
+ - [ ] Step 4 closure dimensions and robustness table covered or marked not applicable
327
+ - [ ] Step 4.5 gate and `/blueprint` routing reflected in report recommendations
328
+ - [ ] `07_CHALLENGE_REPORT.md` written once, template keys complete, **Finding/Impact/Recommendation** each one sentence
329
+ - [ ] Round archive rules understood; if continuing rounds, history compressed per protocol
330
+ - [ ] No emoji anywhere in document
331
+ </completion_criteria>