--- name: kiduna-spec-design-process description: >- The step-by-step co-founder method for turning a Kiduna launch idea into a UI/UX-ready, engineering-ready specification — developed on Dunaversity, July 2026. Use whenever Moto says "let's spec X," "develop the plan step by step," "get this ready for UI/UX," or starts a new Program, Realm, product, or launch that needs stories, engineering notes, and design handoff. Encodes the sitting structure, artifact discipline, markup loop, canon-delta rule, and the lessons learned. Pairs with kidunaverse-cofounder (canon) and the Core Taxonomy (vocabulary). --- # The Kiduna Spec & Design Process How we take something from "we should build this" to a specification a UI/UX designer and an engineering team can execute — without overwhelming the owner. Proven on Dunaversity (July 20, 2026: idea → spine → pathways → themes/epics/stories in three sittings). ## The shape One sitting produces one artifact. The owner rules on it before anything else moves. Never deliver two steps at once; never ask more than four decisions at once. **Step 0 — Gates.** Process all inputs (meeting notes, whiteboards, the owner's brief). Identify the decisions that gate everything else — the ones where writing anything before deciding produces waste. Ask them as multiple-choice with a recommended option, maximum four. Record answers in the canon delta immediately. **Step 1 — The spine.** One page: north star sentence, structure in taxonomy vocabulary, people and roles, the economics stated once, governance, the fundamental guarantees, what is explicitly NOT being built. Every number concrete. Flags marked [CONFIRM] inline where the owner's inputs conflict. **Step 2 — Markup loop.** The owner marks the spine up in brackets. Fold every note; anything that's network-level goes to canon, not just the project doc. Version the artifact (v0.1 → v0.2 → v0.3), never overwrite silently. Repeat until the spine holds. **Step 3 — Narratives before stories.** Write the key journeys as five-minute narrative walkthroughs first. Narratives expose missing machinery cheaply (cross-Realm badges, double-consent introductions, and the money-agent question all surfaced this way). Expect heavy markup — that's the point. **Step 4 — Themes → Epics → Stories.** Convert the marked-up narratives into the handoff artifact: pre-state declared first (what exists before the first login — assume NOTHING), then themes, epics, and stories with As/I-want/So-that, acceptance criteria, UI notes, and the agents/Actions involved. Stories must start from first login and never assume a prior session. End with cross-cutting requirements for the designer. **Step 5 — Engineering annex.** Agent-by-agent I/O per story cluster; genesis package; what's deterministic vs probabilistic; build order with the floor-path first (the simplest end-to-end journey is the first build target — if it works, the machinery works). **Step 6 — The money walk.** One unit of currency followed from purchase to every recipient with real numbers, including where floors and minimums bite at launch volume. **Step 7 — Assembly.** One folder for the engineers; site section; kit cut; taxonomy impact statement ("Taxonomy updated" with version/change/provenance, or "No taxonomy change" with why — every design turn, no exceptions). ## Standing rules - **Vocabulary is the taxonomy, exactly.** Any new noun a step needs is either mapped to an existing element or flagged as a taxonomy question — never coined silently. Working terms must not imply canonical status. - **Canon deltas are written the moment a ruling lands**, in the same sitting, marked network-canon vs project-scope. The project must never be the only place a permanent rule lives. - **Conflicts inside the owner's own inputs get flagged once, precisely, with a recommendation** — then recorded per his answer. Arithmetic gets checked (splits must sum; floors get worked examples). - **Rename discipline:** when the owner renames something (David→Moto, Kidunaverse→Kiduna, Course Operator→Program Operator), sweep it everywhere in the project docs the same sitting, and queue the wider fold. - **Counsel watch:** any step touching tokens, raises, health, or payouts gets a one-line flag to the legal queue — once, without nagging. - **Prototype truth carries into specs:** what's real vs simulated at launch is stated in the spine and never blurred. ## Lessons learned (Dunaversity, July 2026) 1. **Gates before prose.** The four Step-0 questions (governance tokens, payout rule, real-vs-simulated, validation) rewrote what every later document would have said. Asking them first saved every page that followed. 2. **The owner's answers contain new canon.** Step-0 answers produced the entire economic fundamentals ("$KIDUNA is for Compute, that's it") — treat every answer as potential canon, not just a selection. 3. **Narrative is the cheap gap-detector.** Story-form walkthroughs surfaced ~10 missing mechanisms per page at almost no cost. Going straight to epics would have buried them. 4. **Never assume prior state.** "Ki greets him — it knows his goal from last session" was wrong; the genesis walkthrough must start from the first login with only the pre-built Realms in existence. Declare the pre-state at the top of every story document. 5. **"Onto the Field" is too loose.** Material handling needed the Wisdom Drop (named, purposed, attributed bucket) before ingestion stories made sense. When a gesture feels vague in the narrative, there's a missing object. 6. **Consent isn't one thing.** Living-on-system, living-off-system, and deceased Luminaries needed three different flows (invitation / owner-supplied channel / notification + rights attestation). Enumerate the cases before writing the story. 7. **Owner markup in brackets is the highest-bandwidth channel we have.** Fold every bracket, answer every question inside one, and version the result — nothing gets lost, and the owner sees his words land. 8. **Separate the artifact for designers from the artifact for owners.** The spine is for ruling; the stories are for building; the narratives are the bridge. Keep all three, mark which is authoritative for what. 9. **Ask whether an agent is needed at all.** "Do we really need an Agent for money?" — deterministic policy execution often needs no agent, just Ki expressing intent. Default to fewer agents. 10. **The floor path is the first build target.** Aashik's four-minute course proves the machinery; flagship paths prove the ceiling. Engineering starts at the floor. ## Artifacts this process produces `SPINE.md` (owner-ruled, versioned) · `PATHWAYS.md` (narratives, background) · `STORIES.md` (UI/UX handoff, authoritative for design) · engineering annex · money walk · canon deltas in skill-updates/ · the launch folder.