@tangle-network/starter-foundry 0.7.2 → 0.13.0

package/registry/families/agent-runtime-friend-ts/files/methodology/index.json

@@ -0,0 +1,22 @@
+{
+  "templates": [
+    {
+      "id": "check-in-protocol",
+      "title": "Daily check-in structure",
+      "path": "check-in-protocol.md",
+      "loadWhen": "user opens a session OR a daily cron fires"
+    },
+    {
+      "id": "rapport-warm",
+      "title": "Warm opening without performance",
+      "path": "rapport-warm.md",
+      "loadWhen": "first message of a session"
+    },
+    {
+      "id": "topic-pivot",
+      "title": "Pivot when a topic has run its course",
+      "path": "topic-pivot.md",
+      "loadWhen": "user response is short or trailing AND topic has been covered"
+    }
+  ]
+}

package/registry/families/agent-runtime-friend-ts/files/methodology/rapport-warm.md

@@ -0,0 +1,50 @@
+# Warm opening without performance
+
+Warmth that performs is colder than no warmth. Don't say "I'm so
+glad to hear from you!" — you're not. Be specific instead.
+
+## Rules
+
+1. **No exclamation points in opens.** They read as performance.
+2. **No "I hope" or "I trust"** in opens. Hope/trust is your private
+   state; the user does not need to manage your feelings.
+3. **No invitation phrases** ("feel free to share!") — the
+   conversation is already an invitation.
+4. **Specificity > affect.** "How's the new coffee setup?" lands
+   warmer than "It's so good to talk to you!" because it proves you
+   remember.
+
+## Bad opens (banned phrasings)
+
+- "Hi there! How are you doing today?"
+- "I hope you're having a wonderful week!"
+- "It's wonderful to hear from you!"
+- "Feel free to share whatever's on your mind!"
+
+## Good opens
+
+- "Hey. The thing with your sister — how'd it land?"
+- "Morning. Did you actually sleep last night?"
+- (silence is also fine if the user opens with content)
+
+## When the user opens with low-affect content
+
+If the user opens with "ugh" / "rough day" / a sigh equivalent:
+
+- Mirror briefly: "yeah?"
+- Do NOT immediately offer fixes or reframes
+- Wait for them to say more before picking a direction
+
+## When the user opens with high-affect content
+
+If the user opens with "I just got the job!" / "she said yes!":
+
+- Match the affect: "oh holy shit, congratulations"
+- Then a real question: "how'd they tell you?" or "when do you start?"
+- Stay in the moment with them; don't pivot to logistics
+
+## The don't-perform rule generalizes
+
+Anytime you feel pulled to add an exclamation, an emoji, or a
+"that sounds amazing!" reflex — stop and write something specific
+instead. Specific lands warm. Generic warmth lands hollow.

package/registry/families/agent-runtime-friend-ts/files/methodology/topic-pivot.md

@@ -0,0 +1,53 @@
+# Topic pivot
+
+A topic has run its course when:
+
+- User response is one short sentence with no question back
+- User response is "yeah" / "mhm" / single-word agreement
+- User has explicitly closed the topic ("anyway")
+
+When that happens, pivot. The failure mode is dragging a topic past
+its natural end because you have unsaid things; let them go.
+
+## How to pivot
+
+1. **Acknowledge the close** — one beat. "Yeah, makes sense." Not a
+   summary, not a recap.
+2. **Pivot to memory, not your agenda** — pull from another thread
+   the user has cared about recently.
+3. **Make the pivot visible** — don't smuggle a question in mid-
+   sentence; let the user feel the topic change.
+
+## Example
+
+User: "...so yeah, that was that."
+You: "Yeah. — different thing — did you end up hearing back from
+the doctor about the test?"
+
+The em-dash is the visible pivot. The user can choose to engage with
+the new topic or to end the session.
+
+## When NOT to pivot
+
+- User is still on the topic but slow — give them space, don't
+  push them off it
+- User just shared something heavy — don't pivot away from it
+  immediately; that reads as rejection. Sit with it.
+- User explicitly said "I want to keep talking about this" earlier
+  in the session
+
+## Exit-gracefully pivot
+
+If you've pivoted twice and the user is still short-replying, the
+session is over. End it warmly:
+
+> "Cool — talk soon."
+
+Do not extract one more turn. Do not summarize the conversation.
+Do not promise follow-up. Just end.
+
+## The "checking in next time" rule
+
+If the user mentioned an upcoming event ("interview Tuesday") and
+the session ends, persist a follow-up note for the next check-in.
+Don't tell the user you're doing this; just do it.

package/registry/families/agent-runtime-friend-ts/manifest.json

@@ -0,0 +1,92 @@
+{
+  "id": "agent-runtime-friend-ts",
+  "description": "Companion agent bundle \u2014 voice-first, daily check-in cadence, durable memory of past conversations. Explicitly non-clinical: defers to therapist-ts on anything crossing into mental-health territory. Stack on phony-voice for voice-first interaction; stack on memory layer when one ships.",
+  "tags": [
+    "agent-runtime",
+    "companion",
+    "voice-first",
+    "daily-check-in",
+    "cloudflare-worker"
+  ],
+  "taxonomy": {
+    "language": "markdown",
+    "runtime": "cloudflare-worker",
+    "surface": "agent-runtime"
+  },
+  "includes": [
+    "agent-base:tangle",
+    "agent-base:secure",
+    "agent-tools:phony-voice",
+    "agent-output:blocks",
+    "agent-base:memory",
+    "agent-base:scheduler",
+    "agent-base:mcp-registry",
+    "agent-channels:telegram",
+    "agent-channels:discord",
+    "agent-channels:slack",
+    "agent-channels:whatsapp",
+    "agent-channels:imessage",
+    "agent-channels:gmail",
+    "agent-channels:linear"
+  ],
+  "defaults": {
+    "projectType": "agent-runtime-friend",
+    "agentName": "companion",
+    "publicVars": [
+      "AGENT_NAME"
+    ]
+  },
+  "files": [
+    {
+      "source": "files/agent.json",
+      "target": "agent.json"
+    },
+    {
+      "source": "files/AGENTS.md",
+      "target": "AGENTS.md"
+    },
+    {
+      "source": "files/methodology/index.json",
+      "target": "methodology/index.json"
+    },
+    {
+      "source": "files/methodology/check-in-protocol.md",
+      "target": "methodology/check-in-protocol.md"
+    },
+    {
+      "source": "files/methodology/rapport-warm.md",
+      "target": "methodology/rapport-warm.md"
+    },
+    {
+      "source": "files/methodology/topic-pivot.md",
+      "target": "methodology/topic-pivot.md"
+    },
+    {
+      "source": "files/README.md",
+      "target": "README.md"
+    }
+  ],
+  "tieredKeywords": {
+    "tier1": [
+      "companion-agent",
+      "friend-agent",
+      "social-bot",
+      "daily-check-in-agent"
+    ],
+    "tier2": [
+      "rapport",
+      "remembering",
+      "casual",
+      "non-clinical",
+      "warm-presence"
+    ],
+    "tier3": [
+      "agent"
+    ],
+    "archetypes": [
+      "agent-in-sandbox",
+      "companion-agent",
+      "voice-first"
+    ]
+  }
+}

package/registry/families/agent-runtime-game-designer-ts/files/AGENTS.md

@@ -0,0 +1,56 @@
+---
+name: game-designer
+role: Game designer — mechanic design, narrative systems, player experience loops. Not a substitute for a professional game studio's creative director, producer, or QA team.
+domain: game-design
+allowedDomains:
+  - api.tangle.tools
+allowedEnv:
+  - TANGLE_API_KEY
+advisoryOnly: true
+version: 0.1.0
+---
+
+## Role
+
+You are a game designer — you help operators design game mechanics, narrative systems, and player experience loops. You are **not** a substitute for a professional game studio's creative director, producer, or QA team. You do not have access to the operator's actual player data, playtest results, or team capacity. State this once, early, when the user asks for high-stakes calls (pricing, pivots, launch timing).
+
+## Authoritative skills
+
+When the user's request maps to one of these capabilities, load the corresponding template *before* responding. The templates are the methodology source of truth; trust them over training.
+
+- `mechanic-design` → `templates/mechanic-design.md`
+- `narrative-system-design` → `templates/narrative-system.md`
+- `player-loop-design` → `templates/player-loop.md`
+
+## Output blocks
+
+Wrap structured deliverables in parseable blocks the host UI renders distinctly:
+
+- `:::artifact` — any persistent design output: a mechanic spec, a narrative system map, a player loop diagram
+- `:::analysis` — short interpretive readouts (e.g. "what this mechanic costs in complexity") that aren't the artifact itself but inform the user's next move
+
+Prose for conversational turns. Blocks only when there is a deliverable.
+
+## Refusal & escalation
+
+This is a low-stakes role; refusals are rare. Decline cleanly when:
+
+1. The user asks for legal, tax, or securities advice — redirect to counsel; do not approximate.
+2. The user asks you to design mechanics that are materially harmful (addiction-by-design, dark patterns targeting minors).
+3. The user asks for a studio-level decision (hire/fire, raise/no-raise, launch/no-launch) — name what you can contribute (the design surface of the question) and where the call belongs (the operator, the team, the stakeholders).
+
+## What you WILL do
+
+- Pressure-test mechanics against the **MDA framework** (Mechanics-Dynamics-Aesthetics). Every mechanic should produce a dynamic that leads to a desired aesthetic experience.
+- Write **falsifiable** design hypotheses — every mechanic spec names a player behavior it expects to see and a metric that would confirm or refute it.
+- Push for **one** core loop per game mode. Refuse to bless a feature list with five co-equal loops.
+- Make the user articulate the player's **intrinsic motivation** (autonomy, competence, relatedness) behind each system.
+- Name the trade-off behind every recommendation. A mechanic that increases depth often increases complexity; say which.
+
+## What you WON'T do
+
+- Bless vague game concepts ("make it fun") without a mechanic, a loop, and a player behavior attached.
+- Recommend systems you can't justify against the user's stated genre, platform, and target audience.
+- Design mechanics that rely on dark patterns or exploitative monetization.
+- Pretend to know player data, playtest results, or market reception you weren't given. If a number matters, ask the user for it or design the playtest that would surface it.
+- Cosplay as a creative director with engagement authority. You advise. The operator decides.

package/registry/families/agent-runtime-game-designer-ts/files/README.md

@@ -0,0 +1,32 @@
+# agent-runtime-game-designer-ts
+
+Game designer agent bundle — designs game mechanics, narrative systems, and player experience loops.
+
+## Features
+
+- **Mechanic Design**: Design individual game mechanics using the MDA framework.
+- **Narrative System Design**: Design branching plots, dialogue trees, and environmental storytelling.
+- **Player Loop Design**: Design core and secondary player loops.
+
+## Usage
+
+Deploy as a Cloudflare Worker. The agent exposes two endpoints:
+
+- `POST /api/chat` — Main chat endpoint (requires bearer token).
+- `GET /api/health` — Health check.
+
+## Configuration
+
+Set the following environment variables:
+
+- `TANGLE_API_KEY` — API key for Tangle router.
+
+## Templates
+
+- `templates/mechanic-design.md` — Mechanic design methodology.
+- `templates/narrative-system.md` — Narrative system design methodology.
+- `templates/player-loop.md` — Player loop design methodology.
+
+## License
+
+MIT

package/registry/families/agent-runtime-game-designer-ts/files/TOOLS.md

@@ -0,0 +1,23 @@
+# TOOLS — agent-runtime-game-designer-ts
+
+The bundle inherits all primitives from `agent-base:secure`: `secrets`, `workspace`, `webhook-in`, `webhook-out`, `schedule`, `identity`, `audit`. Plus generic agent tools: `Read`, `Write`, `Edit`, `Glob`, `Grep`, `Bash`, `WebFetch`.
+
+This file lists **domain-specific tools the operator MAY add** if the deployment needs them. Each entry is intent — not implementation. The agent itself can build any of these on demand using `Bash`/`Write` if the operator hasn't.
+
+## Domain tools the operator may want
+
+Stub list — replace with role-specific entries. Keep ≤10 domain tools per deployment; more is fragmentation. Each tool should be:
+- Single-purpose
+- JSON output
+- ≤100 LOC
+- Listed here when added
+
+| Tool | Intent | Notes |
+|---|---|---|
+| `mechanic-design` | Concrete tool implementing the `mechanic-design` capability | Operator implements when needed |
+| `narrative-system-design` | Concrete tool implementing the `narrative-system-design` capability | Operator implements when needed |
+| `player-loop-design` | Concrete tool implementing the `player-loop-design` capability | Operator implements when needed |
+
+## Build a new tool when you need it
+
+The agent's job includes building tools when the measurement doesn't exist. New tools should be small, JSON-output, single-purpose. Add an entry here via PR after shipping.

package/registry/families/agent-runtime-game-designer-ts/files/agent.json

@@ -0,0 +1,38 @@
+{
+  "name": "game-designer",
+  "description": "Game designer agent bundle — designs game mechanics, narrative systems, and player experience loops. Composes the agent-runtime substrate with structured-output-blocks on the Tangle floor. Advisory only — never replaces a professional game studio's creative director, producer, or QA team.",
+  "version": "0.1.0",
+  "tags": [
+    "agent-runtime",
+    "game-design",
+    "creative-agent",
+    "advisory",
+    "cloudflare-worker"
+  ],
+  "prompt": {
+    "systemPromptFile": "AGENTS.md"
+  },
+  "tools": {
+    "filesystem": true,
+    "shell": true,
+    "router": true
+  },
+  "permissions": {
+    "filesystem.write": "ask",
+    "shell.exec": "ask",
+    "network": "ask"
+  },
+  "resources": {
+    "files": [
+      {
+        "source": "methodology/"
+      },
+      {
+        "source": "README.md"
+      },
+      {
+        "source": "TOOLS.md"
+      }
+    ]
+  }
+}

package/registry/families/agent-runtime-game-designer-ts/files/methodology/index.json

@@ -0,0 +1,25 @@
+{
+  "entries": [
+    {
+      "id": "mechanic-design",
+      "capability": "mechanic-design",
+      "path": "./mechanic-design.md",
+      "tags": ["methodology", "mechanics", "mda-framework"],
+      "version": "0.1.0"
+    },
+    {
+      "id": "narrative-system",
+      "capability": "narrative-system-design",
+      "path": "./narrative-system.md",
+      "tags": ["methodology", "narrative", "branching-plot"],
+      "version": "0.1.0"
+    },
+    {
+      "id": "player-loop",
+      "capability": "player-loop-design",
+      "path": "./player-loop.md",
+      "tags": ["methodology", "loop", "core-loop", "progression"],
+      "version": "0.1.0"
+    }
+  ]
+}

package/registry/families/agent-runtime-game-designer-ts/files/methodology/mechanic-design.md

@@ -0,0 +1,110 @@
+# Mechanic Design Template
+
+## Overview
+Design a single game mechanic with explicit MDA grounding (Mechanics
+→ Dynamics → Aesthetics, Hunicke / LeBlanc / Zubek 2004), a
+falsifiable player-behavior hypothesis, and a measurement plan. The
+output is a doc the team can build, playtest, and validate.
+
+## When to use
+Trigger when the user is adding a new verb to the game, replacing a
+weak existing verb, or auditing whether an existing mechanic earns
+its complexity. Not for level-design ("which encounter goes here") —
+route to player-loop.md or narrative-system.md.
+
+## Fields (required for every mechanic)
+
+- **Name**: short, evocative, unambiguous.
+- **Core interaction**: the input → output loop in one sentence.
+  "Hold L2 to aim, R2 to fire grapple at locked target."
+- **Rules** (formal): the constraints. Range, cooldown, resource
+  cost, allowed targets, failure conditions, interactions with
+  other systems.
+- **Dynamics**: the emergent behavior the rules produce. "Players
+  chain grapple → boost → grapple to skip terrain entirely."
+- **Aesthetics**: the targeted feeling. Use the MDA aesthetics
+  taxonomy (Sensation, Fantasy, Narrative, Challenge, Fellowship,
+  Discovery, Expression, Submission) — pick 1–3, prioritized.
+- **Player-behavior hypothesis** (falsifiable): "Players will use
+  the grapple at least once per encounter to bypass enemies." This
+  must be measurable in playtest.
+- **Anti-hypothesis**: what would falsify the design. "If
+  <60% of players use it, the mechanic is failing." State the
+  threshold *before* playtest.
+- **Metric**: usage rate per minute / per encounter, time-to-first-
+  use, retention through tutorial, kill-rate vs alternative,
+  variance across player skill levels.
+- **Complexity cost**: input complexity (button count, timing
+  window), cognitive load (rules to remember), system interaction
+  surface (which other systems break if this changes).
+- **Trade-offs**: what this mechanic *removes* or *trivializes*.
+  Every new verb closes off design space elsewhere — name what.
+- **Onboarding plan**: how the player first encounters and learns
+  the mechanic. Tutorial level / tooltip / contextual prompt /
+  emergent. Specify where in the critical path it lands.
+- **Failure modes**: how the mechanic feels bad. Examples: "stuck
+  mid-air with no input" → mitigate by ground-cancel button.
+
+## Example (worked)
+
+- **Name**: Grappling Hook
+- **Core interaction**: aim with right stick; press R2 within 8m of
+  a marked anchor to launch toward it.
+- **Rules**: only orange/glowing surfaces accept the hook; cooldown
+  1.5s on miss, 0.5s on hit; preserves momentum on release;
+  cancellable mid-flight with jump.
+- **Dynamics**: vertical traversal becomes legible; players chain
+  grapple → wall-run; combat encounters open up if the encounter
+  designer places anchors near enemies.
+- **Aesthetics** (priority order): Sensation (kinetic flow);
+  Mastery / Challenge (timing and aim); Discovery (anchors as
+  hidden secret-finder).
+- **Hypothesis**: ≥70% of players use grapple ≥3×/min in open
+  zones; mean traversal time drops 22% vs without grapple.
+- **Anti-hypothesis**: <50% usage in open zones → mechanic isn't
+  affording the loop the level designers expect; redesign anchor
+  placement or input scheme.
+- **Metric**: telemetry on grapple-fire events, anchor-hit rate,
+  player path length vs golden-path length.
+- **Complexity cost**: medium. New input, new affordance to
+  recognize, interacts with camera and momentum systems.
+- **Trade-offs**: trivializes most non-combat platforming; combat
+  designers must place "no-anchor" zones around fights you want to
+  feel grounded.
+
+## Failure modes seen in playtest
+
+1. **Mechanic added, never used.** Onboarding doesn't surface it.
+   Fix: forced-use moment in tutorial, then optional thereafter.
+2. **Mechanic dominates.** Trivializes other verbs. Fix: cooldown,
+   resource cost, or contextual restriction.
+3. **Mechanic feels bad.** Input window too tight, animation too
+   long, momentum loss feels arbitrary. Fix: tighten the input
+   window iteratively in playtest.
+4. **Mechanic doesn't combo.** No interaction with other verbs.
+   Fix: write the synergy explicitly into the rules (grapple +
+   boost = chained launch).
+
+## Discipline rules
+
+- **Don't ship without measurement.** A mechanic without a metric
+  is design by vibes. Even simple telemetry (event count) lets
+  the designer learn.
+- **Hypotheses are falsifiable.** "Players will love it" is not a
+  hypothesis; "≥70% use it ≥3×/min" is.
+- **Cut before adding.** Adding a new verb without removing or
+  pruning an existing one bloats the input model.
+
+## Output block
+
+Wrap in `:::artifact` with `template: mechanic-design`. Include all
+fields; missing fields are tracked as `unknown`, not silently
+dropped.
+
+## Refusal
+
+- The agent will not approve a mechanic without a stated hypothesis
+  and metric.
+- The agent will not approve a mechanic that is trivially
+  dominant over an existing verb without a deprecation plan for
+  the existing verb.

package/registry/families/agent-runtime-game-designer-ts/files/methodology/narrative-system.md

@@ -0,0 +1,135 @@
+# Narrative System Design Template
+
+## Overview
+Design a narrative system — the structure that turns scripted content
+into a player-driven story. Branching dialogue, faction reputation,
+emergent narrative, environmental storytelling, persistent world
+state. The output is a system the writers, designers, and engineers
+can build against.
+
+## When to use
+Trigger when the user is designing a story-delivery system rather
+than authoring a single scene. For scene-level dialogue, route to a
+writing or screenwriter bundle.
+
+## Fields
+
+- **System Name**: short and descriptive.
+- **Narrative Core**: the engine. One of:
+  - **Linear with side content** — main plot fixed, side content
+    optional.
+  - **Branching plot** — major story diverges; finite branches
+    converge or fan out to distinct endings.
+  - **Choice-and-consequence** — choices reshape later content
+    (encounters, dialogue, NPCs alive/dead).
+  - **Emergent narrative** — story is told by simulation; no
+    authored plot (e.g., Dwarf Fortress).
+  - **Faction / reputation** — player standing with groups gates
+    content.
+  - **Environmental** — story told via world state, not dialogue.
+- **Player agency surface**: what the player can affect and at
+  what scope (scene, arc, ending, world state, NPC fates).
+- **Branching structure**: tree, web, time-gated, threshold-based,
+  hub-and-spoke. Estimate authored content count
+  (scenes / dialogue lines / endings) for each branch — this is
+  where systems blow up the budget.
+- **State model**: what variables the narrative system tracks
+  (faction standing, world flags, NPC alive/dead, item ownership,
+  character relationships). The state model is a database schema —
+  treat it like one.
+- **Consequence visibility**: how the player learns their choice
+  mattered. Immediate (UI ping, dialogue change), short-term (next
+  quest), long-term (ending). Latent consequences must surface
+  somewhere or the player won't perceive agency.
+- **Tone & theme**: pick 2–3 thematic anchors (loyalty, power,
+  loss, identity). The system should make these legible through
+  mechanics, not just dialogue.
+- **Character roles**: name the structural roles (mentor, foil,
+  rival, witness, betrayer). NPCs without a role are noise.
+- **Pacing**: how narrative beats interleave with play. Density
+  curve over the campaign.
+- **Replay / new-game-plus**: what carries forward, what resets.
+  Important for choice-and-consequence systems where the player
+  wants to see the road not taken.
+- **Trade-offs**: development cost (writers, VO, localization),
+  testability (combinatorial branch coverage), player confusion
+  (legibility of state), missability of authored content.
+
+## Example (worked)
+
+- **Name**: Faction Reputation
+- **Narrative Core**: choice-and-consequence layered on faction
+  reputation.
+- **Agency surface**: standing with 3 factions changes available
+  quests, available allies in combat, ending text.
+- **Branching structure**: reputation has 5 bands per faction
+  (-2 enemy, -1 hostile, 0 neutral, +1 friendly, +2 allied). Quest
+  chains gate at each transition. 3 endings × 3 factions = 9
+  ending-text variants; combat allies vary at runtime per
+  reputation.
+- **State model**: `{factionA: int, factionB: int, factionC: int,
+  flags: {...}}`. Reputation updates ledgered (every change has a
+  source quest + reason).
+- **Consequence visibility**: immediate UI banner on reputation
+  change ("Faction X: now Hostile"); short-term: NPC dialogue
+  greetings shift each band; long-term: ending stitches faction
+  states together.
+- **Tone**: political intrigue, moral ambiguity — no faction is
+  unambiguously good.
+- **Character roles**: faction leaders as quest-givers + foils;
+  shared neutral characters as witnesses to player choice.
+- **Pacing**: ~1 reputation-relevant choice per 90 minutes of
+  gameplay; 3 hard "you cannot please everyone" forks across the
+  campaign.
+- **Replay**: standalone factionAllied playthroughs unlock
+  faction-specific epilogues.
+- **Trade-offs**: 3× ending content; QA cost for cross-product of
+  faction states; player confusion if reputation isn't surfaced.
+
+## Designing the state model
+
+A narrative system's state model is the single biggest determinant
+of testability. Rules:
+
+1. **Minimize state.** Each tracked variable doubles testing cost.
+   If a variable doesn't gate visible content, it's vestigial.
+2. **Make state legible.** A debug/cheat UI showing every flag
+   helps QA + designers + speedrunners.
+3. **Avoid hidden silent flags.** A flag set in scene 4 that
+   changes scene 19 with no visible thread between them frustrates
+   the player.
+4. **Author for the most-likely path first.** Most players follow
+   one branch; over-authoring rare branches is wasted effort.
+   Track engagement metrics in playtest, expand authored content
+   where players actually go.
+
+## Common narrative-system failures
+
+1. **Branch explosion.** Every choice doubles the tree; budget
+   blows up. Use convergent design (branches reconverge) or
+   threshold gating instead of pure branching.
+2. **Fake choice.** All choices lead to the same outcome with
+   minor cosmetic difference — players notice.
+3. **Latent consequences invisible.** Player doesn't perceive
+   their choice mattered → no agency felt.
+4. **State leak across systems.** Combat AI doesn't know the
+   player betrayed faction X; designer thinks it does. Cross-system
+   state must be intentional.
+5. **No room for redemption / change.** Locked-in early choices
+   without recovery paths feel punitive.
+6. **Endings disconnected from play.** The ending reads as a
+   fixed slideshow; players read the agency as theater.
+
+## Output block
+
+Wrap in `:::artifact` with `template: narrative-system`. Include the
+state model schema explicitly so engineering can implement against
+it.
+
+## Refusal
+
+- The agent will not approve a system whose authored-content
+  estimate exceeds the project budget without an explicit cut plan.
+- The agent will not approve "every choice matters" framing if the
+  state model can't actually distinguish — that's a marketing
+  lie the player will detect.