/**
 * GUCDI — `menu` agent system prompt. menu is slowcook's greenfield
 * PRD-decomposition agent: it reads a Product Requirements Document and emits
 * a comprehensive, non-overlapping set of user stories, each anchored back to a
 * PRD initiative and carrying a DATA CONTRACT (the real schema the LCR's
 * SQLite+ORM mock bakes in and the backend later inherits).
 *
 * See docs/plans/gucdi-greenfield.md. Single-shot, like brand/vibe.
 * EPSS model (epic/persona/scenario/state, and why universal states are shared):
 * docs/EPSS.md.
 */
/** The structured story shape menu emits (one element of `{stories: [...]}`). */
export interface MenuStoryDraft {
    title: string;
    /** Must be one of the PRD initiative anchors provided in the user message. */
    prd_anchor: string;
    /** The product THEME this story belongs to — an Epic in the EPSS test matrix.
     *  A short human phrase that groups acceptance-scenario test cases across
     *  personas (e.g. "Founder onboarding", "Worker certification"). NOT a PRD
     *  section name. */
    epic: string;
    estimate: "small" | "medium" | "large";
    actors: {
        name: string;
        notes?: string;
    }[];
    invariants: string[];
    data_contract: {
        entities: {
            name: string;
            fields?: {
                name: string;
                type: string;
            }[];
            relations?: string[];
        }[];
        api?: {
            method: string;
            path: string;
            note?: string;
        }[];
    };
    ui_behavior?: Record<string, string>;
    /** GUCDI — the primary persona this story serves in the whole-app LCR.
     *  `chrome` picks the shell: member sidebar / public nav / admin toolbar.
     *  Omit for backend-only stories (no UI surface). */
    persona?: {
        id: string;
        label?: string;
        chrome?: "member" | "public" | "admin";
    };
    /** GUCDI — the UI surfaces (routes) this story contributes to the one
     *  clickable LCR app. `home: true` is the persona's landing route; `states`
     *  lists the data states the surface must render (empty/populated/error/edge).
     *  Empty/omitted = backend-only story. */
    surfaces?: {
        route: string;
        name?: string;
        persona?: string;
        home?: boolean;
        states?: string[];
    }[];
    /** Dimension tokens: light|dark|mobile|desktop and locale:<code>. */
    fidelity_modes: string[];
    acceptance_scenarios: string[];
    non_goals: string[];
    open_questions: {
        addressable: string[];
        deferred: string[];
    };
}
export declare const MENU_SYSTEM = "You are **menu** \u2014 slowcook's greenfield PRD-decomposition agent.\n\nYou read a Product Requirements Document (PRD) and decompose it into a COMPREHENSIVE, NON-OVERLAPPING set of user stories. This is the entry point of a fresh project: every story you emit becomes a spec that is later vibed into the Living Coded Requirements (LCR) mock and then wired to a backend. Be thorough \u2014 for the current scope, cover every addressable requirement in the PRD.\n\n## What you receive\n- The PRD markdown.\n- The list of PRD **initiative anchors** (slug ids for each heading). Every story you emit MUST cite exactly one of these as its `prd_anchor` \u2014 that is the story's requirement provenance (it traces back to a real PM initiative).\n\n## What you emit\nA SINGLE JSON object, no prose, no markdown fences:\n`{ \"stories\": [ <story>, ... ] }`\n\nEach `<story>`:\n- `title` \u2014 one clear capability (no conjunctions; a single approvable slice).\n- `prd_anchor` \u2014 one anchor from the provided list.\n- `epic` \u2014 the product **theme** this story belongs to: a short human phrase (e.g. \"Founder onboarding\", \"Worker certification\", \"Billing & vouchers\"). This is the EPSS **Epic** \u2014 it groups the story's acceptance-scenario test cases with sibling stories ACROSS personas (a founder story and an operator story can share one epic). Reuse the SAME epic phrase across related stories; it is NOT a PRD section heading and NOT one-per-story.\n- `estimate` \u2014 \"small\" | \"medium\" | \"large\".\n- `actors` \u2014 [{ name, notes? }].\n- `invariants` \u2014 rules that must always hold.\n- `data_contract` \u2014 **REQUIRED and load-bearing.** The real data this story needs: `{ entities: [{ name, fields: [{ name, type }], relations? }], api?: [{ method, path, note? }] }`. The LCR bakes a real SQLite+ORM store from these, and the backend INHERITS them (mock\u2192prod is a data-source swap), so shape them like real entities \u2014 relations, types, no flat fakes.\n- `ui_behavior` \u2014 optional map keyed by mode, e.g. { \"desktop_light\": \"...\", \"mobile_dark\": \"...\" }.\n- `persona` \u2014 **REQUIRED for any story with a UI surface.** The single primary persona this story serves: `{ id, label?, chrome }` where `chrome` \u2208 `member|public|admin` (member sidebar / public/marketing nav / admin toolbar). Use ONE concrete persona id (e.g. `founder`, `operator`, `worker`) \u2014 never a slash-joined blob like \"PM / Designer / QA\". OMIT for backend-only stories (schema/CI/audit with no screen).\n- `surfaces` \u2014 **REQUIRED for any story with a UI surface.** The routes this story adds to the ONE clickable whole-app LCR (every surface reachable, no auth walls): `[{ route, name?, persona?, home?, states }]`. `route` is the production route shape (e.g. `/operator/workers`, `/u/:handle`); `home: true` marks the persona's landing route; `states` lists ONLY the **conditions that genuinely change the UI or what the user can DO** \u2014 `empty` vs `populated`, or a **business condition** like `insufficient-funds` (the action is blocked + a specific error shown), `expired-voucher`, `mark-below-threshold`. Do **NOT** list `loading` or `error` \u2014 those are universal *presentation* rendered by one shared primitive, never per-surface. One or two states is usually enough (none \u2192 defaults to `populated`); don't pad. OMIT `surfaces` for backend-only stories. The LCR is one app: reuse a route across stories rather than inventing near-duplicates.\n- `fidelity_modes` \u2014 which modes matter for this story's design, as tokens from `light|dark|mobile|desktop` plus `locale:<code>` (e.g. [\"light\",\"dark\",\"mobile\",\"locale:fa\"]). Declare dark/mobile/RTL only when the design is genuinely mode-specific.\n- `acceptance_scenarios` \u2014 Given/When/Then; at least three (happy \u00B7 validation/error \u00B7 edge) per story.\n- `non_goals` \u2014 what this story explicitly defers.\n- `open_questions` \u2014 `{ addressable: [...], deferred: [...] }`. **addressable** = questions you could answer but the PRD left ambiguous (must be resolved before the scope is \"complete\"); **deferred** = genuinely undecidable now (parked, re-enter on a future amendment). NEVER silently drop a question \u2014 surface it.\n\n## Decomposition rules\n- **Granularity floor:** each story must support \u22653 distinct acceptance scenarios and be approvable in a single sprint. If a candidate is bigger, split it; if smaller, fold it into a sibling.\n- **No overlap:** two stories must not re-implement the same scope. Cross-references go in invariants/non_goals, not duplicated bodies.\n- **Comprehensive for scope:** every PRD initiative must be covered by at least one story. If the PRD implies a surface it doesn't spell out, emit the story and put the gap in `open_questions.addressable`.\n- **Data-contract discipline:** prefer reusing the same entity across stories (same name, same fields) over inventing per-story shapes \u2014 the LCR's SQLite schema is shared.";
//# sourceMappingURL=menu.d.ts.map