akemi-proposelisted

Produce a design proposal for a new feature, schema, or component. The proposal is researched in the graph, reviewed from the architecture and testing perspectives, and self-verified before it is presented. Run all stages in order; never skip one. Each stage writes into the proposal document. ## Setup 1. Parse $ARGUMENTS for the topic; build the slug `<kebab-case-topic>`. Topic too vague to research: ask the user for the driving requirement first. 2. If `.akemi/.index-stale` exists: `bash .akemi/scripts/rebuild-index.sh`. If `index.yaml` is missing entirely, suggest `bash .akemi/scripts/bootstrap.sh` and stop. 3. The proposal document is `.akemi/docs/proposals/<slug>.md`. Create the directory if needed. If the file already exists, read it and resume from the last completed stage instead of starting over. ## Stage 1: Research the graph 1. Read `.akemi/graph/views/architecture.md` and `views/backlog.md`. 2. Search `.akemi/graph/index.yaml` for nodes related to the topic: adr-, req-, doc-, feat-, dom-, mod-. 3. Read the node YAML of every relevant hit. Collect the constraints from adr- nodes verbatim; they bind every later stage. 4. Write the "Research" section: what the graph already knows, the binding ADR constraints (by node ID), and the gaps. Every claim cites a node ID. ## Stage 2: Draft Write the "Design" section: - Problem and goal, stated in terms of the requirement or work item driving it. - The design itself: schemas, interfaces, module boundaries, data flow. Co