# Dunaversity — Themes, Epics, and Stories (v0.1 · 2026-07-20 · Step 3, UI/UX handoff edition)

**Scope:** Moto as Catalyst of the Genesis Program (Mastering Agency), every step from first login — then Matt, Aashik, and Paul as learners on Live, each walked to the moment they become a Catalyst and move to Studio. Written for a UI/UX designer: each story has acceptance criteria, UI notes, and the agents/Actions involved. Vocabulary is taxonomy v1.3.4 exactly (Six Elements; Source replaces Presence; Scenes without Portals; the person-vouched invite).

**Pre-state (nothing else exists):** Kinship Duna — the Genesis Organization — and Dunaversity, the second duna, are pre-built. Ki exists with its genesis Stance and genesis Wisdom namespace. The treasury rules are configured (lineage 30/18, 3% Kiduna Club, 20%/$50K admin minimum). Moto has an account: member of Kinship Duna, **Wizard of Dunaversity**. No Programs exist. Mastering Agency is the **Genesis Program** — it will be used to let the others build theirs.

**Story format:** As / I want / So that · **AC** acceptance criteria · **UI** design notes · **⚙** agents & Actions.

---

## THEME A — First entry (Moto, Studio)

### Epic A1 · First login and orientation

**S-A1.1 · Launch and authenticate.** As Moto, I want to open Studio and sign in, so that I am present in the Field as myself.
**AC:** Studio launches to authentication; on success my Source is established; my Roles load (member of Kinship Duna; Wizard of Dunaversity); session identity is fixed (no in-Field account switching).
**UI:** minimal entry — mark, name, sign-in; no dashboard.
**⚙** Action: `enter_field`.

**S-A1.2 · Ki greets first, from zero.** As Moto, I want Ki to greet me before I speak — with no assumed prior session — so the conversation, not a menu, is the front door.
**AC:** Ki's first message names what exists and nothing more: "Two Realms are here: Kinship Duna and Dunaversity. You are Dunaversity's Wizard. What would you like to do?"; voice and chat both available; the Field behind shows exactly two Realm Elements.
**UI:** the HUD carries Ki's greeting over a quiet Field; two Realm Elements visible, nothing else; no empty-state clutter.
**⚙** Ki; graph read (my Roles, visible Realms).

**S-A1.3 · Look before building.** As Moto, I want to enter Dunaversity and see its (empty) state, so I understand where the Program will live.
**AC:** entering Dunaversity is an explicit Action; inside: no Programs yet, the Organization's Stance and treasury rules inspectable; route back to the Field is always present.
**UI:** entering a Realm is a place transition, not a page load; an "about this Realm" Panel (translucent) shows Stance/rules on request.
**⚙** Action: `enter_realm`.

### Epic A2 · Declaring intent

**S-A2.1 · Ki doesn't guess — I declare.** As Moto, I want to tell Ki "I want to create a course about mastering agency," so that intent comes from me and Ki assembles the path.
**AC:** Ki restates what it heard as a plan ("a Program Realm inside Dunaversity — a course"); Ki lists what forming it will involve (identity → structure → material → people → badges → publish); nothing is created yet.
**UI:** the plan renders as a checklist Element pinned to the workspace — it will track progress across sessions.
**⚙** Ki; Program Operator (not yet invoked).

**S-A2.2 · Confirm formation.** As Moto, I want to confirm creation of the Program Realm, so a draft Realm exists with me as Catalyst.
**AC:** confirmation is a Confirmed-level Action; on confirm: Program Realm exists in **draft** inside Dunaversity, invisible to discovery; I hold Catalyst; a Record is written.
**UI:** a single clear confirm — one tap, consequence stated ("creates a draft Realm only you can see").
**⚙** Program Operator; Action: `create_realm` (type: Program).

---

## THEME B — Program identity (name · handle · description · Stance)

### Epic B1 · Naming through conversation

**S-B1.1 · Name and handle.** As Moto, I want Ki to propose names from our conversation and check handle availability live, so identity emerges from dialogue, not a form.
**AC:** Ki proposes 3+ name candidates with rationale; I can type my own ("Mastering Agency: How to free yourself from time, space, and the death-grip of global civilization"); handle auto-derived (`mastering-agency`), uniqueness-checked across the ecosystem, editable; title + handle saved to the draft Realm.
**UI:** proposals as selectable Elements in a Panel; live availability check on the handle; the long title displays with a designed short-form.
**⚙** Ki; Action: `update_realm_identity`.

**S-B1.2 · Description drafted from interview.** As Moto, I want Ki to interview me briefly (who is this for, what changes for them, what it is not) and draft the description, so the public face is written from my answers.
**AC:** 3–5 interview turns; a draft description appears as an editable Artifact; my edits are the authoritative version; versions retained.
**UI:** split attention — conversation on one side, the living draft beside it; edits inline.
**⚙** Ki (drafting); Artifact: generated, Moto's provenance.

### Epic B2 · The Stance

**S-B2.1 · Stance interview.** As Moto, I want Ki to elicit the course's Stance — what it believes, how it treats people, what it never does — so the Program has instructions, not vibes.
**AC:** structured elicitation (mission, values, boundaries, prohibited behavior — e.g., "never lectures; disagreement is material"); output is a versioned Stance Artifact attached to the Realm; every Program agent inherits it; editable any time by Catalyst only.
**UI:** the Stance is a first-class document Element on the Realm, marked with its version; a diff view on edit.
**⚙** Ki; Action: `update_stance` (Catalyst-only permission).

---

## THEME C — Wisdom Drops (the material)

*Rule: material is never dumped "onto the Field" loosely. Moto asks Ki to create a named **Wisdom Drop** — a permissioned bucket — for each body of material: per topic, per purpose, per Luminary. Every item carries attribution and add-time classification.*

### Epic C1 · Creating and managing Drops

**S-C1.1 · Create a named Drop.** As Moto, I want to say "create a Wisdom Drop for Howard's synthesis work," so each body of material has its own bucket, purpose, and attribution before anything is added.
**AC:** Drop created with: name, purpose statement, default classification (e.g., private-to-this-Program), default attribution (e.g., Howard); Drops are Elements of the Realm; listable, renamable, re-classifiable by Catalyst.
**UI:** Drops render as labeled containers within the Program workspace; creating one is one sentence to Ki or one button.
**⚙** Ki; Action: `create_wisdom_drop`.

**S-C1.2 · Drop inventory.** As Moto, I want to see all Drops with counts, classifications, and attribution at a glance, so I always know what the course is made of and who it credits.
**AC:** inventory view: name · items · classification · attribution · last change; opening a Drop lists items with per-item overrides.
**UI:** a Panel (translucent) over the Realm; never a file manager aesthetic — these are credited bodies of Wisdom.

### Epic C2 · Ingest — three sources

**S-C2.1 · From my desktop.** As Moto, I want to drag files from my computer into a *specific Drop*, so nothing lands unclassified or uncredited.
**AC:** drag targets are Drops (or Ki asks "which Drop?" if dropped loose); each file becomes an **imported** Artifact with source metadata; per-item classification editable at drop time; bulk classification per batch.
**UI:** drag-over highlights Drops; a brief add-time card per batch: Drop · classification · attribution — confirm once.
**⚙** Actions: `add_wisdom` (imported); vector ingestion into the Drop's namespace.

**S-C2.2 · From Google Docs/Drive.** As Moto, I want to paste a link to a doc or a folder, so external material joins a Drop without moving house.
**AC:** link resolves via a Connection (Google); I choose snapshot (imported copy) or reference (**external** Artifact, re-fetched under its own permissions); folder links enumerate contents for selection; provenance recorded either way.
**UI:** paste-link into the Drop; a clear toggle: "copy now" vs "keep linked"; external items visibly marked.
**⚙** Connection: Google; Actions: `add_wisdom` (imported | external).

**S-C2.3 · From research runs.** As Moto, I want to prompt the Researcher ("build me a briefing on the history of enclosure — cite everything") and have results land in a Drop I designate, so the course can be *built*, not just assembled.
**AC:** Researcher runs multi-model with provenance kept; output is **generated** Artifacts (markdown) with source lists; lands in the designated Drop in a review state; Compute consumed is metered to the Program's development record.
**UI:** a run card: prompt · status · Compute used · results; results open side-by-side with sources.
**⚙** Researcher; QA/QC (auto-pass follows); Action: `run_research`.

**S-C2.4 · Author directly.** As Moto, I want to create Artifacts myself — drafting with Ki from imported material and prompts — so generated and imported work interleave.
**AC:** an editor over any Drop item(s) producing a new generated Artifact citing its inputs; both origins coexist in one Drop.
**UI:** "make something from these" — select items, state intent, edit the draft.

### Epic C3 · Review, QA, classification

**S-C3.1 · QA/QC pass.** As Moto, I want QA/QC to check accuracy and provenance on course material and queue what it can't verify, so I decide with the flag in front of me.
**AC:** flags queue with reason ("quote unverifiable — no source found"); my options: cut · keep-with-caveat · send back to Researcher; every disposition recorded.
**UI:** a review queue Panel; one item at a time; the flagged passage highlighted in context.
**⚙** QA/QC; Actions: `resolve_qa_flag`.

**S-C3.2 · Classification is always visible, always mine.** As Moto, I want every item's classification (private-to-Program · public · personal · secret) visible where the item is, and changeable by its owner, so the privacy story is never ambiguous.
**AC:** classification chips on every item; changing one is a recorded Action by the item's owner; personal items are visibly distinct and Ki confirms their rule aloud ("yours alone — I can draw on it to help you teach, never expose it").
**UI:** four classifications, four unmistakable treatments; no burying in settings.
**⚙** Action: `set_classification` (owner-only).

**S-C3.3 · Vector and graph stay in agreement (engineering story).** As the orchestration layer, I need the graph to hold every Drop, item, classification, attribution, and acceptance state as nodes/edges, while vectors live in per-Drop namespaces — so **permission is answered by the graph before content is fetched from vectors, every time**.
**AC:** no vector query without a graph permission pass; Drop namespace = retrieval scope; acceptance state changes graph edges (not vector contents); deleting/reclassifying updates both stores atomically.
**⚙** Graph Command Service; this is the §5 discoverability substrate too.

### Epic C4 · Structure emerges (the movements)

**S-C4.1 · Structure is discovered, not assumed.** As Moto, I want Ki and the Curator to interview me about the arc and propose 2–3 structures *from the material we now have*, so "four movements" is an outcome of work, not a template.
**AC:** structure proposals reference actual Drops/items; I pick, merge, or dictate; the chosen structure becomes the course skeleton (movement Elements); restructuring later is safe (items re-map, nothing is lost).
**UI:** proposals as arrangeable structures; drag items between movements; the skeleton is the course's home view from here on.
**⚙** Curator; Action: `set_program_structure`.

**S-C4.2 · Curate into movements.** As Moto, I want the Curator to place accepted material into movements with rationale, and me to approve or move it, so curation is assisted but authored.
**AC:** every placement carries "why here"; unplaced material sits visibly in its Drops; my moves are final.
**⚙** Curator.

---

## THEME D — Luminaries, Creators, and the Wizard

### Epic D1 · Naming Luminaries

**S-D1.1 · Name a living Luminary who is on-system.** As Moto, I want to name Howard a Luminary, so his work is credited and he shares in the split.
**AC:** naming creates: attribution on his Drop(s), a pending **invitation** to him (his Ki delivers it), a proposed split entry; his acceptance recorded; his material usable meanwhile with attribution.
**⚙** Profiler (locates his Source); Actions: `name_luminary`, `send_invitation`.

**S-D1.2 · Name a living Luminary who is NOT on-system.** As Moto, I want Ki to ask me how to reach a Luminary (email? no channel?), so recognition doesn't depend on membership.
**AC:** Ki asks for a channel; if provided, a notification/invitation goes out-of-band (Kinship Code attached — zero-spam rule: I send it, or Ki sends on my explicit instruction to a channel I supplied); if no channel, standing is recorded as "named, unreached" and revisitable.
**UI:** a short "how do we reach them?" card; status chips: invited · joined · unreached.

**S-D1.3 · Name a deceased Luminary.** As Moto, I want to credit a deceased Luminary (consent isn't required — recognition and rights are), so their body of work is honored correctly.
**AC:** no consent flow; attribution + recognition recorded; Ki asks two questions instead: "notify anyone (estate, family)?" and "do you have rights to use this material?" — my answer recorded on the Drop (rights responsibility is mine); their share, if any, routes per my split instruction (e.g., to an estate or a fund).
**UI:** the same naming card with the consent section replaced by notification + rights attestation.

**S-D1.4 · Splits.** As Moto, I want each Luminary's share in the Program's split rule set where I name them, so credit and compensation are one gesture.
**AC:** split entries visible on the Program's money view; sum-checks; editable by Catalyst until locked into the Squad wallet rules.

### Epic D2 · Appointing a Creator (Renee Smith)

**S-D2.1 · Appoint at Program scope.** As Moto, I want to appoint Renee Smith Creator for this Program, so she can contribute publicly-scoped material to it.
**AC:** appointment is a recorded Role grant (Program scope); she's notified; her Role chip shows in the Program.
**⚙** Action: `assign_role` (Creator, scope: Program).

**S-D2.2 · What Creator actually changes (the precise rule).** As Renee, I can always publish my own Wisdom **public** (my right as its owner — any Realm can then carry it). As a Program-scope Creator, my *private-to-this-Program* submissions land in the course's contribution queue with Creator standing. **Nothing becomes course-official without acceptance, and accepted material still passes through the Curator for integration into a movement.**
**AC:** two visibly distinct paths for her material: "published publicly by Renee" vs "accepted into Mastering Agency, integrated into Movement III"; the graph records acceptance state and placement separately from the raw vector content.
**UI:** contribution queue shows submitter, standing (Creator/member), classification, and target; accept → an integration step, not a done state.
**⚙** Actions: `submit_contribution`, `accept_into_record`, `integrate_item`; Curator.

### Epic D3 · The Program Wizard

**S-D3.1 · Elevate a Wizard with an explicit operations scope.** As Moto, I want to elevate a trusted member (launch: Jeya) to Program Wizard with a checked list of operations, so administration is delegated without becoming ownership.
**AC:** scope picker at grant time — enrollment operations · contribution-queue triage (recommend, not accept) · badge issuance mechanics · schedule/notifications · Scene housekeeping; **excluded and not offerable: Stance changes, treasury/splits, acceptance-into-record, Luminary naming**; grant is time-bound and revocable; all Wizard acts are Records visible to me.
**UI:** a delegation card with the scope checklist and the exclusions stated in plain sight.
**⚙** Action: `assign_role` (Wizard, scope: Program, operations list).

---

## THEME E — The Scene (built plainly)

### Epic E1 · From art to place

**S-E1.1 · Import the art.** As Moto, I want to import the completed Mastering Agency art into the Program's Scene workspace, so the visual world starts from what exists.
**AC:** art assets ingest as Artifacts in a Scene workspace attached to the Program; originals untouched; inventory view.

**S-E1.2 · Define what's missing.** As Moto, I want to define characters, objects, and interactions with generation help (from art + course Stance), so the Scene becomes playable, not just visible.
**AC:** character/object definitions are Artifacts (name, look from art refs, role in the course, behavior notes); generation assists, I approve each; everything versioned.
**UI:** a simple roster: art on one side, defined entities on the other; "define from this art" as the primary gesture.
**⚙** Researcher/generation actors under the Program Stance; Compute metered to development.

**S-E1.3 · Attach the Scene.** As Moto, I want the Scene attached to the Program Realm as its Media system, so it presents within the Surface under the Realm's identity, permissions, and Records — no separate entry machinery.
**AC:** the Scene is Realm Media operated by Actors; it loads in place within the Surface; Source, Role, and permissions are simply the Realm's; leaving the Scene view is ordinary navigation with state continuity.
**⚙** Action: `enter_scene` (a view change, not a boundary crossing).

**S-E1.4 · Test walk.** As Moto, I want to walk the Scene as a learner would before publish, so the optional path is sound.
**AC:** a preview-as-learner mode; nothing required for course completion lives only in the Scene.

---

## THEME F — Badges, Offering, Publish

**S-F1.1 · Define badges.** As Moto, I want to define the Program's badges — one per movement, one for the whole arc, one contribution badge — so completion and contribution are durable records.
**AC:** each badge: name, art, criteria (deterministic where possible: movement completion; Catalyst-triggered for contribution), issuing authority (Program), on-chain NFT on issuance; badge definitions are part of the publishable Program.
**UI:** badge cards with criteria in plain language.
**⚙** Action: `define_badge`.

**S-F1.2 · Set the Offering.** As Moto, I want enrollment terms set as an Offering — at launch, membership entitlement (included with Dunaversity membership) — so access is a stated term, not an assumption.
**AC:** Offering attached to the Program; terms displayed wherever the course is discoverable; changeable by Catalyst with notice.

**S-F1.3 · Pre-publish check.** As Moto, I want one screen that shows exactly what the world will see (public metadata: title, description, public essays, badges, Offering) plus Sentinel and QA status, so publishing is informed.
**AC:** "what's public" preview is byte-accurate to the genesis namespace entry; unresolved QA flags and Sentinel notes listed; classification summary (nothing private leaks into public metadata — machine-checked).
**UI:** a single pre-flight Panel.

**S-F1.4 · Publish.** As Moto, I want publishing to be a Deliberate action, so the moment the course becomes discoverable is unmistakably mine.
**AC:** press-and-hold; status draft → **published**; public metadata written to the genesis namespace; a Record with timestamp; unpublish/republish exists with the same weight.
**⚙** Action: `publish_realm` (Deliberate).

---

## THEME G — Money on the creation side

**S-G1.1 · Compute meter, always honest.** As Moto, I want to see Compute consumed as I build (Researcher runs, generation, Scene work) — as cost, not drama — so development spend is a fact I watch, not a surprise.
**AC:** per-run and cumulative development Compute on the Program's money view; USDC-denominated at launch.

**S-G1.2 · The development record.** As the system, every unit of development Compute is attributed to the Program, so the payback rule has an authoritative number.
**AC:** development-Compute ledger on the Program; inspectable by Catalyst; feeds the monthly distribution.

**S-G1.3 · Squad wallet and split rule.** As Moto, I want the Program's Squad wallet configured with my split (Moto X% · Howard · Four Arrows · Renee · contribution pool), so distribution is policy, not promises.
**AC:** split rule attached to the wallet; sum = 100%; changes are Deliberate actions with Records; Luminary shares route per D1 (incl. estate routing for the deceased).

**S-G1.4 · The monthly walk (worked example, launch numbers).** As Moto, I want to see one month worked: treasury remainder → Programs pro-rata by Compute consumed → Mastering Agency's share → payback of my development spend (e.g., 1,400 USDC) → the excess through the split.
**AC:** the money view can show this walk with real numbers each month; every hop is a Record.
**⚙** Deterministic distribution execution (whether any "agent" fronts this remains the open question — Ki expresses intent; execution is policy).

---

## THEME H — Matt: learner on Live → Catalyst threshold

### Epic H1 · Joining

**S-H1.1 · Invitation.** As Matt, I receive a one-time link and a Secret Code that Moto set, out-of-band (text), so joining starts with a person vouching, not a funnel.
**AC:** the link is single-use and dies once the Secret Code is redeemed; Moto privately declared who it's for, what it invites to, trust level, and relationship context (never shown to Matt; informs greeting and presentation); opening lands on kiduna.ai.
**S-H1.2 · Membership.** As Matt, I enter my Code Name (the one name field), enter the Secret Code, set my own password — no email, no mobile — then pay 100 USDC at kiduna.ai (card via onramp, or connect a wallet); my FROST wallet (three shares) is created, and I land in Live auto-enrolled in Kinship Duna and Dunaversity.
**AC:** payment → distribution executes per the unchangeable rules (lineage 30 → Moto's line · 3% Kiduna Club · admin minimum → treasury), every hop a Record; wallet creation invisible-but-inspectable; first-open of Live goes straight to Ki.

### Epic H2 · Learning on Live

**S-H2.1 · Ki-first arrival.** As Matt, Ki greets me by name, knows Moto invited me, and offers one clear thing: what's here (Mastering Agency).
**AC:** no feed, no grid; conversation with one discoverable course behind it.
**S-H2.2 · Enroll.** As Matt, I enroll with one confirmation (Offering: included with membership).
**AC:** enrollment recorded; the Program appears as *my* place in Live.
**S-H2.3 · Learn.** As Matt, I move through Movement I on the phone — reading, listening, asking Ki questions that draw on the course's Wisdom within its permissions.
**AC:** progress is mine to see (not ranked); movement completion issues the badge (on-chain, quietly).
**S-H2.4 · The Scene from the phone.** As Matt, I can open the Mastering Agency Scene from within the course on Live, or skip it and miss nothing required.

### Epic H3 · Contributing

**S-H3.1 · Voice contribution.** As Matt, moved by Movement II, I record my Gulf War story by voice on Live and submit it **private to the Program**.
**AC:** one gesture from within the course; classification stated before submit; my Service Alliance veteran badge (KYC'd NFT) rides as trust evidence.
**S-H3.2 · Acceptance touches me back.** As Matt, when Moto accepts my testimony into the course record and the Curator places it, I'm notified, the contribution badge is issued, and I can see exactly where my story lives.
**AC:** acceptance/placement/badge all Records; my reclassification rights remain mine (I can later consent to public).
**⚙** Sentinel (emotion watch active on heavy testimony; support path present, no scores).

### Epic H4 · The threshold

**S-H4.1 · "I could teach this."** As Matt, I tell Ki I want to build a military history course; Ki explains the Catalyst path and what changes (Studio, structure, drops, splits), and offers to carry my contributions over as seed material.
**AC:** the moment creates nothing yet; a plan checklist is prepared; Ki suggests continuing in Studio.
**S-H4.2 · Cross to Studio.** As Matt, I open Studio and find the plan and my seed material waiting — same Field, bigger bench.
**AC:** continuity absolute; from here his path is Themes A–G (the same epics, his content). **Stop.**

---

## THEME I — Aashik: learner → the fastest Catalyst

**S-I1.1 · Joins** (as H1, code from Moto or lineage under him).
**S-I1.2 · Learns enough.** As Aashik, I sample Mastering Agency on Live; what hooks me is the machine, not the topic.
**S-I1.3 · Declares from the couch.** As Aashik, I tell Ki — on Live — "I want to make a course: how to be a cricket fan," and the draft Program forms with defaults (standard Stance template, one "Fan" badge, open enrollment, no Luminaries, no Scene) in under five minutes.
**AC:** Live-side creation covers: intent → name/handle → default confirmation → draft Realm; everything else deferred; the four-minute path is real and measured.
**S-I1.4 · Enriches in Studio.** As Aashik, next morning in Studio, the Researcher scaffolds public-source material into a Drop; I record three voice segments; QA/QC flags tone, I keep it; I publish same-day.
**AC:** the floor path end-to-end ≤ one day; **this is Techneural's first build target.** **Stop at published.**

---

## THEME J — Paul: learner → the Catalyst with the biggest ask

**S-J1.1 · Joins** (as H1).
**S-J1.2 · Learns with a purpose.** As Paul, I take Mastering Agency's governance and finance movements on Live, asking Ki throughout how Realms, money, and privacy actually work — my questions are about what I'm going to build.
**S-J1.3 · The threshold conversation.** As Paul, I tell Ki what Supporting Research must do: connect researchers, donors, and patients (Muscular Dystrophy · IBC-IC · Colon Cancer · Child Neurology · Glioblastoma Foundation), run five disease Communities, distribute research, raise money, communicate.
**AC:** Ki maps each need to machinery (Communities, Institution KYB + sponsorship, external verified Artifacts, donation Offerings, double-consent introductions, private-metadata discovery) and — because this Program touches health — states the boundary plainly and routes the Program's Stance to review before it can open; the plan checklist is created for Studio.
**S-J1.4 · Cross to Studio with the plan.** As Paul, Studio opens on the prepared plan: five Communities scaffolded, the Institution flow queued, the Stance-review gate marked. **Stop.**

---

## Cross-cutting requirements the designer should hold

1. **Ki is the interface**; every screen is a rendering of a conversation that could have happened in words. Visual acts and spoken acts feed one system.
2. **The four classifications get four unmistakable visual treatments**, everywhere, on everything.
3. **Confirmation grammar** (Autonomous silent · Confirmed one-tap · Deliberate press-and-hold · Governed routed to a Forum) is consistent across all themes — the control is never the permission.
4. **Records are one gesture away** from anything consequential ("how did this happen" always answerable).
5. **Provenance and attribution are visible by default** — a course is visibly made of credited Wisdom, which is the anti-industrial guarantee rendered.
6. **Money renders as facts** (meters, ledgers, walks) — never gamified, never urgent.
7. Live and Studio are one Field: anything begun on one is waiting on the other.
8. **Inspect everywhere**: every rendered Element carries a clear inspect affordance, and "Inspect X" to Ki answers with true type, containment, permissions, provenance.

*Marked-up narratives remain in PATHWAYS.md as background. Step 4 (money walk + consumption polish) folds into these themes where noted. Next after your markup: the engineering annex — agent-by-agent I/O for each story cluster — and the design-lab handoff.*
