@wazir-dev/cli 1.0.0

package/docs/readmes/features/tooling/README.md

@@ -0,0 +1,320 @@
+# Wazir CLI
+
+The `wazir` CLI is the validation, indexing, and export tool for the Wazir
+engineering OS kit. It has no background processes and no server — it is a stateless
+command-line utility that operates on the repo and a configurable state root.
+
+**Design principle:** validation is the primary capability. Every command either prevents
+a fake-green state (validate/doctor/export --check) or supports structured run tracking
+(capture/status/index/recall).
+
+---
+
+## Installation
+
+```bash
+# From the repo root
+npm install
+
+# The CLI is available as:
+npx wazir <command>
+
+# Or via the package bin after global install:
+npm install -g .
+wazir <command>
+```
+
+Requires Node.js 18+. No external services required.
+
+---
+
+## Root Discovery
+
+The CLI walks upward from the current working directory until it finds
+`wazir.manifest.yaml`. This means all commands work correctly from any nested
+subdirectory inside the project.
+
+---
+
+## Command Reference
+
+### Validate
+
+Validate sub-commands enforce correctness of the manifest, hooks, docs, and code
+hygiene. All exit `0` on pass, `1` on failure, `2` for reserved/incomplete commands.
+
+```bash
+wazir validate manifest
+```
+Validates `wazir.manifest.yaml` against `schemas/wazir-manifest.schema.json`
+and checks that all required repo paths declared in the manifest actually exist.
+
+```bash
+wazir validate hooks
+```
+Validates every hook definition in `hooks/definitions/` against `schemas/hook.schema.json`
+and checks the manifest hook roster for completeness.
+
+```bash
+wazir validate docs
+```
+Validates `docs/truth-claims.yaml`, cross-checks documented CLI commands against the
+active CLI surface, and rejects broken local Markdown links.
+
+```bash
+wazir validate brand
+```
+Enforces canonical product naming across the Wazir surface — rejects prohibited
+terms listed in the manifest's `prohibited_terms` array.
+
+```bash
+wazir validate runtime
+```
+Rejects non-canonical runtime wrappers, repo-local task/state paths, and forbidden
+runtime-only package surfaces.
+
+```bash
+wazir validate branches [--branch <name>]
+```
+Validates the current (or specified) branch name against allowed git-flow patterns.
+
+```bash
+wazir validate commits [--base <ref>] [--head <ref>]
+```
+Validates conventional commit format for commits in the specified range (or auto-detected
+base to HEAD).
+
+```bash
+wazir validate changelog [--require-entries] [--base <ref>]
+```
+Validates `CHANGELOG.md` structure. With `--require-entries` and `--base`, enforces that
+new entries have been added since the base ref.
+
+```bash
+wazir validate artifacts   # reserved — exits 2
+```
+
+---
+
+### Export
+
+```bash
+wazir export build
+```
+Compiles host packages from canonical sources into `exports/hosts/*`. Validates the
+manifest and hooks first, then reads all declared role and workflow files, writes
+host-specific files, and records SHA-256 source hashes for drift detection.
+
+```bash
+wazir export --check
+```
+Drift check: re-hashes current canonical sources and compares against the stored hashes
+in each `exports/hosts/<host>/export.manifest.json`. Exits non-zero when any source has
+changed since the last build.
+
+---
+
+### Doctor
+
+```bash
+wazir doctor
+```
+Full surface health check: runs manifest validation, hooks validation, state-root policy
+check, and verifies host export directory presence. Recommended before any release or
+major merge.
+
+---
+
+### Index
+
+The index stores a SQLite-backed symbol and outline map under the configured state root.
+Useful for agents that need fast symbol lookup without reading every file.
+
+```bash
+wazir index build [--state-root <path>]
+```
+Builds the local index from scratch. Parses supported languages (JS, TS, Python, Go,
+Rust, Java, SQL, JSON, YAML, Markdown) using built-in heuristic parsers.
+
+```bash
+wazir index refresh [--state-root <path>]
+```
+Incrementally refreshes indexed files using stored content hashes — skips unchanged files.
+
+```bash
+wazir index stats [--state-root <path>]
+```
+Reports file count, symbol count, and outline entry count for the current index.
+
+```bash
+wazir index search-symbols <query> [--state-root <path>]
+```
+Searches indexed symbol names.
+
+```bash
+wazir index get-symbol <name-or-id> [--state-root <path>]
+```
+Returns a stored symbol record by name or ID.
+
+```bash
+wazir index get-file-outline <file-path> [--state-root <path>]
+```
+Returns indexed outline entries for a file.
+
+---
+
+### Recall
+
+```bash
+wazir recall file <file-path> --start <line> --end <line> [--state-root <path>]
+```
+Returns an exact line-bounded slice from an indexed file without reading the whole file
+into context.
+
+```bash
+wazir recall symbol <name-or-id> [--state-root <path>]
+```
+Returns an exact slice for an indexed symbol match — file path, line range, and content.
+
+---
+
+### Status
+
+```bash
+wazir status --run-id <id> [--state-root <path>]
+```
+Reads run status directly from `<state-root>/runs/<run-id>/status.json` and prints
+current phase, status, and loop counts.
+
+---
+
+### Capture
+
+The capture commands support structured run tracking. Agents use these to maintain an
+auditable ledger of events, phase transitions, and large tool outputs.
+
+```bash
+wazir capture init --run-id <id> [--state-root <path>]
+```
+Creates a run ledger: `status.json`, `events.ndjson`, and a `captures/` directory under
+`<state-root>/runs/<run-id>/`.
+
+```bash
+wazir capture event --run-id <id> --type <event-type> [--phase <phase>] \
+  [--status <status>] [--state-root <path>]
+```
+Appends a structured event to `events.ndjson` and can update `phase`, `status`, and
+loop counts in `status.json`.
+
+```bash
+wazir capture route --run-id <id> --name <capture-name> [--state-root <path>]
+```
+Reserves a run-local capture file path for large tool output — returns the path so the
+agent knows where to write.
+
+```bash
+wazir capture output --run-id <id> --name <capture-name> --content <content> \
+  [--state-root <path>]
+```
+Writes captured tool output to the reserved file and records a `post_tool_capture` event.
+
+```bash
+wazir capture summary --run-id <id> --content <content> [--state-root <path>]
+```
+Writes `summary.md` and records the chosen summary or handoff event.
+
+---
+
+## Exit Codes
+
+| Code | Meaning |
+|---|---|
+| `0` | Check passed / command succeeded |
+| `1` | Invalid input or validation failure |
+| `2` | Command surface exists but implementation is intentionally incomplete |
+
+---
+
+## State Root
+
+All index, recall, status, and capture commands accept `--state-root <path>` to override
+where run state lives. The default is `~/.wazir/projects/<project-slug>/` as declared
+in `wazir.manifest.yaml`.
+
+This keeps all run-time state outside the repo, preventing accidental commits of agent
+session data.
+
+---
+
+## Common Workflows
+
+**Before merging a PR:**
+```bash
+wazir validate manifest
+wazir validate hooks
+wazir validate docs
+wazir export --check
+```
+
+**Full health check:**
+```bash
+wazir doctor
+```
+
+**After editing roles or workflows, rebuild exports:**
+```bash
+wazir export build
+wazir export --check   # verify no drift
+```
+
+**Start a new agent run:**
+```bash
+wazir capture init --run-id run-$(date +%s)
+```
+
+---
+
+## Extending the CLI
+
+1. Add a new check file to `tooling/src/checks/` following the pattern of existing
+   check modules.
+2. Register it in `tooling/src/checks/command-registry.js`.
+3. Wire it into `tooling/src/commands/validate.js` as a sub-command.
+4. Document the new command in `docs/tooling-cli.md`.
+5. Add a truth claim entry to `docs/truth-claims.yaml` so `wazir validate docs`
+   can verify the documented command matches the implemented behavior.
+6. Add a test in `tooling/tests/` — all commands must have automated coverage before
+   they leave `reserved` status.
+
+---
+
+## Source Layout
+
+```
+tooling/src/
+  cli.js                  Entry point, argument parsing, command dispatch
+  loaders.js              YAML/JSON file readers
+  schema-validator.js     AJV-backed validator (JSON Schema Draft 2020-12)
+  project-root.js         Upward manifest discovery
+  state-root.js           State root resolution with --state-root override
+  command-options.js      Shared option definitions
+  commands/
+    validate.js           Validate sub-command dispatcher
+  checks/
+    command-registry.js   Registry of all validate sub-commands
+    manifest.js           manifest check
+    branches.js           branch name check
+    commits.js            conventional commit check
+    changelog.js          changelog structure check
+    docs-truth.js         docs truth-claims check
+    brand-truth.js        brand naming check
+    runtime-surface.js    runtime wrapper check
+  export/
+    command.js            export build / --check entry
+    compiler.js           canonical source collector + host package writer
+  index/                  SQLite index build/refresh/search
+  recall/                 Line-bounded file and symbol recall
+  capture/                Run ledger: init/event/route/output/summary
+  doctor/                 Full surface health check
+  status/                 Run status reader
+```

package/docs/readmes/features/workflows/README.md

@@ -0,0 +1,186 @@
+# Wazir Workflows
+
+**The complete engineering pipeline — from raw idea to production-grade code.**
+
+![Phase Count](https://img.shields.io/badge/phases-14-blue)
+![Roles](https://img.shields.io/badge/roles-10-purple)
+![Status](https://img.shields.io/badge/status-stable-green)
+
+Wazir workflows are the sequencing backbone of the engineering OS. Every workflow is a canonical phase entrypoint: host-neutral, artifact-driven, and gated by explicit approval contracts. You don't skip phases. You don't merge ambiguity forward. You ship code that is provably correct against a spec that was adversarially challenged before a line was written.
+
+---
+
+## The Full Pipeline
+
+```
+┌──────────────────────────────────────────────────────────────────┐
+│                     WAZIR PIPELINE                          │
+├──────────────────────────────────────────────────────────────────┤
+│                                                                  │
+│  INPUT                                                           │
+│    │                                                             │
+│    ▼                                                             │
+│  [1] CLARIFY ──────── clarifier ──── scope + questions          │
+│    │                                                             │
+│    ▼                                                             │
+│  [2] DISCOVER ─────── researcher ─── cited findings             │
+│    │                                                             │
+│    ▼                                                             │
+│  [3] SPECIFY ──────── specifier ──── spec + AC           ★ GATE │
+│    │                                                             │
+│    ▼                                                             │
+│  [4] SPEC-CHALLENGE ─ reviewer ───── challenge findings  ★ GATE │
+│    │                                                             │
+│    ▼                                                             │
+│  [5] AUTHOR ───────── content-author microcopy + i18n    ★ GATE │
+│    │                                                             │
+│    ▼                                                             │
+│  [6] DESIGN ───────── designer ───── .fig + tokens + code ★ GATE│
+│    │                                                             │
+│    ▼                                                             │
+│  [7] DESIGN-REVIEW ── reviewer ───── review findings     ★ GATE │
+│    │                                                             │
+│    ▼                                                             │
+│  [8] PLAN ─────────── planner ────── impl. plan          ★ GATE │
+│    │                                                             │
+│    ▼                                                             │
+│  [9] PLAN-REVIEW ──── reviewer ───── plan findings       ★ GATE │
+│    │                                                             │
+│    ▼                                                             │
+│ [10] EXECUTE ──────── executor ───── code + docs                │
+│    │                                                             │
+│    ▼                                                             │
+│ [11] VERIFY ──────── verifier ────── proof artifact      ★ GATE │
+│    │                                                             │
+│    ▼                                                             │
+│ [12] REVIEW ──────── reviewer ────── findings + verdict  ★ GATE │
+│    │                                                             │
+│    ▼                                                             │
+│ [13] LEARN ───────── learner ─────── learning artifacts  ★ GATE │
+│    │                                                             │
+│    ▼                                                             │
+│ [14] PREPARE-NEXT ── planner ─────── handoff                    │
+│    │                                                             │
+│    ▼                                                             │
+│  NEXT RUN / DONE                                                 │
+│                                                                  │
+│  ★ = explicit human approval gate                                │
+└──────────────────────────────────────────────────────────────────┘
+```
+
+> [!NOTE]
+> The `author`, `design`, and `design-review` phases are skippable. `author` is skipped when a project has no user-facing content needs. `design` and `design-review` are skipped when a project has no visual design needs or when the open-pencil MCP adapter is not available. All other phases are mandatory.
+
+---
+
+## Workflow Reference Table
+
+| # | Workflow | Role | Trigger | Key Outputs | Approval Gate |
+|---|----------|------|---------|-------------|---------------|
+| 1 | [clarify](clarify.md) | `clarifier` | Input briefing files arrive | Clarification artifact, unresolved questions, scope summary | Soft — escalate material ambiguity |
+| 2 | [discover](discover.md) | `researcher` | Clarified scope approved | Research artifact, cited findings | Soft — unsupported research blocked |
+| 3 | [specify](specify.md) | `specifier` | Research artifacts ready | Spec artifact, acceptance criteria, assumptions | **Hard — human approval required** |
+| 4 | [spec-challenge](spec-challenge.md) | `reviewer` | Draft spec produced | Challenge findings | **Hard — findings must be resolved** |
+| 5 | [author](author.md) | `content-author` | Spec challenge closed | Microcopy, i18n keys, glossary, seed data, coverage matrix | **Hard — human approval required** |
+| 6 | [design](design.md) | `designer` | Author approved (or skipped) | `.fig` file, exported code, design tokens, screenshots | **Hard — human approval required** |
+| 7 | [design-review](design-review.md) | `reviewer` | Design artifact produced | Review findings with severity | **Hard — blocking findings stop planning** |
+| 8 | [plan](plan.md) | `planner` | Design reviewed (or skipped) | Implementation plan, ordered tasks | **Hard — human approval required** |
+| 9 | [plan-review](plan-review.md) | `reviewer` | Draft plan produced | Plan findings, revised tasks | **Hard — blocking findings stop execution** |
+| 10 | [execute](execute.md) | `executor` | Plan approved | Code changes, docs changes, execution notes | Soft — no new scope without approval |
+| 11 | [verify](verify.md) | `verifier` | Execution batch complete | Verification proof artifact | **Hard — no completion claim without proof** |
+| 12 | [review](review.md) | `reviewer` | Verification proof produced | Findings, no-findings verdict | **Hard — blocking findings stop completion** |
+| 13 | [learn](learn.md) | `learner` | Review verdict accepted | Proposed learning artifacts, experiment summaries | **Hard — explicit review + scope tags required** |
+| 14 | [prepare-next](prepare-next.md) | `planner` | Learn phase complete | Next-step handoff, scoped context summary | Soft — no implicit carry-forward |
+
+### Bonus Workflow
+
+| Workflow | Role | Purpose |
+|----------|------|---------|
+| [run-audit](run-audit.md) *(coming soon)* | `researcher` | Structured codebase/branch audit — produces findings report or plan doc |
+
+---
+
+## Philosophy: Why This Pipeline Exists
+
+### Problems It Solves
+
+Most AI coding loops fail in the same five ways:
+
+1. **Ambiguity laundering** — unclear requirements get papered over and explode in execution
+2. **Spec-less planning** — plans are written before acceptance criteria exist
+3. **Rubber-stamp review** — review phases that generate no findings because the reviewer is also the implementor
+4. **Completion theater** — "done" is declared without runnable proof
+5. **Context rot** — stale assumptions from prior runs silently corrupt the next
+
+Wazir's pipeline is designed to make each of these failure modes structurally impossible or explicitly visible.
+
+### Design Principles
+
+**Artifact-driven handoff.** Every phase produces a named artifact. The next phase consumes it. Nothing is passed via vibes or conversation history.
+
+**Adversarial review at three chokepoints.** `spec-challenge`, `plan-review`, and `review` are all run by the `reviewer` role — never the phase author. Red-teaming is structural, not optional.
+
+**Hard gates before irreversible work.** Approval gates sit precisely at the points where rework cost spikes: before writing a spec into a plan, before writing a plan into code, before declaring code complete.
+
+**Host-neutral contracts.** Workflow files contain zero host-specific syntax. Host adapters (Claude, Codex, Gemini, Cursor) are generated from these canonical contracts at export time.
+
+**No implicit carry-forward.** The `prepare-next` workflow exists precisely to make context handoff explicit. You cannot silently carry stale learnings into the next run.
+
+---
+
+## Entering and Exiting the Pipeline
+
+### Full run (greenfield feature)
+
+Start at `clarify`. Run every phase in order. All gates must be passed.
+
+### Mid-pipeline entry (approved spec exists)
+
+If a spec artifact already exists and has been approved, enter at `author` (or `design` if author is skipped, or `plan` if both are skipped). You must still have valid upstream artifacts — the pipeline checks inputs, not just phase names.
+
+### Execution-only entry (plan exists)
+
+If an approved plan exists from a prior run, enter at `execute`. Wire the plan artifact as the execute input. Do not re-run planning without invalidating the existing plan.
+
+### Audit entry (out-of-band)
+
+`run-audit` is an independent workflow. It does not require prior pipeline state. It produces a report artifact or a plan doc in `docs/plans/` for handoff to `plan`.
+
+### Exiting early
+
+You may exit after any gate with a formal partial-completion artifact. The next session enters at the point of exit. `prepare-next` must always run before session end if the pipeline is incomplete.
+
+---
+
+## Artifact Locations
+
+State and artifacts live outside the repo by default:
+
+```
+~/.wazir/projects/<project-slug>/
+  runs/
+    <run-id>/
+      clarification.md
+      research.md
+      spec.md
+      spec-challenge.md
+      author/
+      design/
+      design-review.md
+      plan.md
+      plan-review.md
+      execution-notes.md
+      verification-proof.md
+      review-findings.md
+      learnings.md
+      prepare-next.md
+```
+
+---
+
+## Related
+
+- [Architecture](../../../concepts/architecture.md)
+- [Roles and Workflows](../../../concepts/roles-and-workflows.md)
+- [Skills](../../../reference/skills.md)
+- [Hooks](../../../reference/hooks.md)

package/docs/readmes/features/workflows/author.md

@@ -0,0 +1,181 @@
+# author
+
+**Phase 5 — From approved spec to production-ready content, before a single pixel is designed.**
+
+![Phase](https://img.shields.io/badge/phase-5%20of%2014-blue)
+![Role](https://img.shields.io/badge/role-content--author-orange)
+![Gate](https://img.shields.io/badge/gate-hard%20%E2%98%85-red)
+![Optional](https://img.shields.io/badge/optional-skippable-yellow)
+![Status](https://img.shields.io/badge/status-stable-green)
+
+---
+
+## One-Line Purpose
+
+Write and package all non-code content artifacts — microcopy, i18n keys, seed data, glossary, asset metadata, notification templates, and a content coverage matrix — so that design and implementation work from real content, not placeholders.
+
+---
+
+## Pipeline Position
+
+```
+  SPEC-CHALLENGE
+    |
+    v
++---------+
+| AUTHOR  |  <-- YOU ARE HERE
++---------+
+    |
+    v
+  DESIGN  (or PLAN if design skipped)
+    |
+    v
+  DESIGN-REVIEW ...
+```
+
+---
+
+## Role Responsible
+
+`content-author`
+
+The content author writes all user-facing text, locale keys, and supporting content from the approved spec. The content author does not design UI or write application code — it produces content artifacts that the designer and executor consume. The distinction matters: a content artifact is the source of truth for all user-facing text; it is not a suggestion.
+
+---
+
+## Trigger
+
+All of the following are true:
+
+- Spec artifact exists and is approved
+- Spec challenge findings are resolved (no outstanding blocking findings)
+- Project has user-facing content needs (this phase is skippable — see Skip Conditions below)
+
+---
+
+## Skip Conditions
+
+`author` may be skipped when:
+
+1. The task has no user-facing text, notifications, or locale-sensitive output (a CLI tool, a background service, a data migration, a purely visual design change with no new copy)
+2. All required content already exists in the project's locale files and only needs wiring
+
+When skipped, proceed directly to `design` (or `plan` if design is also skipped). The plan must note the absence of an author artifact. Any content decisions become the executor's responsibility, constrained by the spec's acceptance criteria.
+
+> [!NOTE]
+> Skipping the author phase is a deliberate trade-off, not a shortcut. Content decisions that should be authored will instead be made ad hoc during design or implementation. This is acceptable for non-content work; it is a risk for user-facing features with multiple locales or brand constraints.
+
+---
+
+## Steps
+
+1. **Load the approved spec and research artifacts.** Identify all UI states, screens, notifications, and interactions that require text content.
+
+2. **Load existing glossary and locale sources** (if available). If no glossary or locale files exist (per research findings), note this and proceed with spec-derived terminology only.
+
+3. **Author microcopy for every UI state.** For each screen and state referenced in the spec:
+   - Empty state, loading state, error state, success state
+   - Edge case states (rate limited, offline, expired, forbidden)
+   - Interactive element labels (buttons, links, tooltips)
+
+4. **Define i18n keys.** Create key definitions with values for every required locale. Use the project's existing key naming convention if one exists.
+
+5. **Write seed and fixture content.** Produce realistic test data values for development, testing, and demo environments. No lorem ipsum, no "test123", no "John Doe".
+
+6. **Build the terminology glossary.** Define domain terms used in this feature's content. Resolve any conflicts with existing glossary entries.
+
+7. **Produce asset metadata.** Write alt text for images, labels for icons, ARIA descriptions for interactive elements.
+
+8. **Write notification templates.** Author email, push, and in-app notification content referenced in the spec.
+
+9. **Generate the content coverage matrix.** Map every screen to every key to every locale. Flag gaps.
+
+10. **Flag layout-sensitive content.** Identify translations or content that is significantly longer than the primary locale and flag for designer awareness.
+
+11. **Produce the author artifact.** Package all content outputs as a single named artifact.
+
+---
+
+## Input Artifacts
+
+| Artifact | Location | Required |
+|----------|----------|----------|
+| Approved spec artifact | Run state | Yes |
+| Research artifact | Run state | Yes |
+| Existing glossary/locale sources | Repo or external | Optional |
+| Brand/style guidelines | Repo or external | Optional |
+
+---
+
+## Output Artifacts
+
+| Artifact | Description |
+|----------|-------------|
+| Microcopy tables | All UI text for every state, screen, and interaction |
+| i18n key definitions | Key-to-value mappings for all required locales |
+| Seed/fixture content | Realistic test data for dev, test, and demo |
+| Terminology glossary | Domain term definitions for consistency |
+| Asset metadata manifest | Alt text, icon labels, ARIA descriptions |
+| Notification templates | Email, push, and in-app transactional content |
+| Content coverage matrix | Screen-to-key-to-locale completeness mapping |
+| Author artifact (combined) | All of the above packaged as a single named artifact |
+
+---
+
+## Approval Gate
+
+> [!IMPORTANT]
+> **Explicit human approval is required before design begins.** The human reviews the authored content at this gate. Content informs every visual decision — button widths, banner heights, text wrapping behavior. Errors here cascade through design, planning, and execution. The cost of fixing a copy mistake increases at every downstream phase.
+
+---
+
+## Example Run
+
+**Spec inputs (abbreviated):**
+- AC-1: Toggle visible at all viewport widths with label text
+- AC-3: localStorage persistence notification
+- AC-4: Correct rendering at 768px breakpoint (label may truncate)
+
+**Author artifact produced:**
+
+```
+author/
+  microcopy/
+    dark-mode-toggle.md           <- all toggle states and labels
+    dark-mode-notifications.md    <- preference saved/restored messages
+  i18n/
+    dark-mode.keys.json           <- key definitions, en-US + es-ES values
+  seed/
+    dark-mode-fixtures.json       <- test data values
+  glossary/
+    dark-mode-terms.md            <- dark mode, light mode, system preference
+  coverage/
+    dark-mode-matrix.md           <- screen-to-key-to-locale mapping
+```
+
+**Key content decisions (documented in artifact):**
+- Toggle label: "Dark mode" (not "Dark theme" or "Night mode") per glossary
+- es-ES toggle label "Modo oscuro" is same character count — no layout flag needed
+- Notification on preference save: "Preference saved" (transient toast, 3s)
+
+---
+
+## Common Mistakes
+
+| Mistake | Impact | Prevention |
+|---------|--------|------------|
+| Using placeholder text (lorem ipsum, TBD) | Placeholders leak to production; design is sized for wrong content | Every text field must have production-ready copy |
+| Missing locale entries for some keys | Shipped feature shows raw keys in some locales | Content coverage matrix must show 100% for all required locales |
+| Authoring content not in the spec | Scope creep into design and execution | Author only what the acceptance criteria require |
+| Ignoring layout impact of long translations | Designer creates frames that break with production text | Flag translations >15% longer than primary locale |
+| Inconsistent terminology across screens | Users see "dark mode" on one screen and "night theme" on another | Glossary is a required output; all copy must use glossary terms |
+
+---
+
+## Related
+
+- [Overview — All Workflows](README.md)
+- [Previous: spec-challenge](spec-challenge.md)
+- [Next: design](design.md)
+- [Architecture (author phase)](../../../concepts/architecture.md)
+- [Roles and Workflows](../../../concepts/roles-and-workflows.md)