grace-plan

Run the GRACE architectural planning phase.

## Prerequisites
- `docs/requirements.xml` must exist and have at least one UseCase
- `docs/technology.xml` must exist with stack decisions
- `docs/verification-plan.xml` should exist as the shared verification artifact template
- If requirements or technology are missing, tell the user to run `$grace-init` first
- If the verification plan template is missing, recreate it before finalizing the planning artifacts

## Architectural Principles

When designing the architecture, apply these principles:

### Contract-First Design
Every module gets a MODULE_CONTRACT before any code is written:
- PURPOSE: one sentence, what it does
- SCOPE: what operations are included
- DEPENDS: list of module dependencies
- LINKS: knowledge graph node references

### Module Taxonomy
Classify each module as one of:
- **ENTRY_POINT** — where execution begins (CLI, HTTP handler, event listener)
- **CORE_LOGIC** — business rules and domain logic
- **DATA_LAYER** — persistence, queries, caching
- **UI_COMPONENT** — user interface elements
- **UTILITY** — shared helpers, configuration, logging
- **INTEGRATION** — external service adapters

### Semantic Anchoring
Favor semantically rich module, function, flow, and block names.

- prefer names that carry domain meaning over abstract IDs or arbitrary placeholders
- make PURPOSE and SCOPE fields concrete enough that a worker can infer intent without guessing
- when a rule is subtle, include one or two compact examples in notes or verification scenarios instead of relying on a vague prose rule

### Reliability-First Stack Selection
Use `docs/technology.xml` to define an approved implementation stack for agents.

- name the preferred runtime libraries, test tools, logging stack, and framework surfaces explicitly
- note discouraged or non-default libraries when they would weaken autonomous reliability
- plan around tools and abstractions that the team is actually willing to verify and maintain

### Knowledge Graph Design
Structure `docs/knowledge-graph.xml` for maximum navigability:
- Each module gets a unique ID tag: `M-xxx NAME="..." TYPE="..."`
- Functions annotated as `fn-name`, types as `type-Name`
- CrossLinks connect dependent modules bidirectionally
- Annotations describe only the module's public interface
- Do not push private helpers or implementation-only types into shared XML artifacts

### Verification-Aware Planning
Planning is incomplete if modules cannot be verified.

For every significant module, define during planning:
- a `verification-ref` like `V-M-xxx`
- likely source and test file targets
- critical scenarios that must be checked
- the log or trace anchors needed to debug failures later
- which checks stay module-local versus wave-level or phase-level

## Process

### Phase 1: Analyze Requirements
Read `docs/requirements.xml`. For each UseCase, identify:
- What modules/components are needed
- What data flows between them
- What external services or APIs are involved

### Phase 2: Design Module Architecture
Propose a module breakdown. For each module, define:
- Purpose (one sentence)
- Type: ENTRY_POINT / CORE_LOGIC / DATA_LAYER / UI_COMPONENT / UTILITY / INTEGRATION
- Dependencies on other modules
- Key public interfaces (what the module exposes to other modules or callers)
- Tentative source path, test path, and `verification-ref`
- Semantic anchors the worker should reuse: module naming, function naming, and critical block names

Present this to the user as a structured list and **wait for approval** before proceeding.

### Phase 3: Design Verification Surfaces
Before finalizing the plan, derive the first verification draft:
- map critical UseCases to `DF-xxx` data flows
- assign `V-M-xxx` verification entries for important modules
- list the most important success and failure scenarios
- identify required log markers or trace evidence for critical branches
- note module-local checks plus any wave-level or phase-level follow-up
- define stop conditions or replan triggers for the highest-risk modules so execution can halt cleanly instead of drifting

Present this verification draft to the user as part of the same approval checkpoint. If the verification story is weak, revise the architecture before proceeding.

### Phase 4: Mental Walkthroughs
Run "mental tests" for 2-3 key user scenarios step by step:
- Which modules are involved?
- What data flows through them?
- Where could it break?
- Which logs or trace markers would prove the path was correct?
- Are there circular dependencies?

Present the walkthrough to the user. If issues are found — revise the architecture.

### Phase 5: Generate Artifacts
After user approval:

1. Update `docs/development-plan.xml` with the full module breakdown, public module contracts, target paths, observability notes, data flows, and implementation order. Use unique ID-based tags: `M-xxx` for modules, `Phase-N` for phases, `DF-xxx` for flows, `step-N` for steps, and `V-M-xxx` references for verification.
2. Update `docs/verification-plan.xml` with global verification policy, critical flows, module verification stubs, autonomy-gate evidence, and phase gates.
3. Update `docs/knowledge-graph.xml` with all modules (as `M-xxx` tags), their public-interface annotations (as `fn-name`, `type-Name`, etc.), `verification-ref` links, and CrossLinks between them.
4. Ensure `docs/technology.xml` explicitly names the preferred stack and observability surfaces the worker should stay inside.
5. Print: "Architecture approved. Run `$grace-verification` to deepen tests and trace expectations, `grace lint --profile autonomous` to check execution readiness, `$grace-execute` for sequential execution, or `$grace-multiagent-execute` for parallel-safe waves."

## Important
- Do NOT generate any code during this phase
- This phase produces ONLY planning documents and verification artifacts
- Every architectural decision must be explicitly approved by the user

## Output Format
Always produce:
1. Mod