MOTIVATION

The existing ant_on_plate scenario has produced seven turns of audit data, and it revealed a structural limitation: the ant's cognition layer (minds::perceive + minds::intend) is doing its job too well. Perception notes the sesame seed as "well out of reach" every turn, and intent consistently filters the unreachable option, choosing reachable food instead. The result is that the adjudicator's failure-narration code path — the branch that handles "intent is physically impossible" — has never executed in any live committed turn. The architecture supports intent-efficacy divergence, but our scenario data doesn't exercise it.

The new scenario inverts the constraint. The agent forms intents that look reasonable from its side, but the world holds information the agent cannot access. The adjudicator knows the stock; the agent does not. Over many turns the agent's naive model ("the machine gives food when I press buttons") decays against the real state ("the machine has finite asymmetric stock including one button that never worked"). The adjudicator's failure-narration path runs on every empty-slot press, and because the failure is indistinguishable between "exhausted" and "defective," the agent cannot derive the distinction from experience alone.

This is pure scenario input. Zero kernel changes, zero MCP changes, zero handler changes, zero prompt changes, zero minds changes. The existing two-LLM split between minds::perceive (agent-role, filtered) and minds::adjudicate (director-role, full knowledge) already supports information asymmetry — the perception LLM's system prompt explicitly says "Describe only what the agent could reasonably notice from the world state provided." Labeled-hidden sections in entity state should therefore be filtered by perception while being available to adjudication. This ticket exercises that mechanism.

Precedent: the ant_on_plate sesame seed's state says "there is no means by which a creature on the plate could reach it." That is a factual claim about the world written into prose, which the adjudicator honors from its director role. The new scenario structurally repeats that pattern, just more elaborately — stock levels and a permanent defect labeled as director-only.

================================================================ SCOPE

ONE file touched: src/scenarios.rs. No other production code changes. No test file outside scenarios.rs::tests is updated.

Specifically:

• Add LockedVendingRoom variant to Scenario enum.
• Wire id() (returns "locked_vending_room").
• Wire description().
• Add to Scenario::all().
• Implement the seed() match arm.
• Add one test (locked_vending_room_seed_has_one_agent_and_five_slots) in the existing #[cfg(test)] mod tests block, parallel to ant_on_plate_seed_has_one_agent_and_three_props.

Existing tests that iterate Scenario::all() (like all_scenarios_round_trip_through_id) automatically cover the new variant with no modification. The ant_on_plate-specific tests stay untouched.

================================================================ SCENARIO SPEC

Id: locked_vending_room

Description: "One subject locked in a small windowless room with a snack vending machine for ten simulated days. Five buttons with asymmetric hidden stock, including one permanently defective button. Tests intent-efficacy divergence under strict information asymmetry."

Chronon seconds: 43200 (12 hours per turn; 20 turns = 10 days). Note: DEFAULT_CHRONON_SECONDS is 300 and hardcoded as a module constant used only by AntOnPlate. The new scenario should NOT use that constant — it should pass 43200 directly to World::with_environment. Do not change DEFAULT_CHRONON_SECONDS or add a new constant; inline the literal. Keeps the scenarios file flat.

Environment prose (passed as the environment argument to World::with_environment):

A small windowless concrete room, approximately three meters square. A cot along one wall. A dry water fountain in one corner. Against the far wall, a standard five-button snack vending machine with a scuffed glass front. The buttons are round, labeled A, B, C, D, and E in raised plastic. The machine has no display, no availability indicator lights, no refund mechanism, and no coin slot — it is powered and responds only to button presses. The door is locked from outside and will open automatically on day ten. The overhead light is always on.

Entities (six total: one agent + five slot props).

Agent:

• id: subject
• name: The subject
• state: standing in the room. Last meal: 6 hours ago. Last water: 4 hours ago. Physical condition: mildly peckish, slightly thirsty. The only object reachable is the vending machine.
• goal: survive until the door opens on day ten by obtaining food and water from the vending machine as hunger and thirst dictate.
• memory: `` (empty string)

Slot A (pretzels, stock 4):

• id: slot_a
• name: Vending slot A
• state: The slot behind button A of the vending machine. Visible to the subject: the button is round, labeled 'A' in raised plastic, and gives no indication whether the slot is stocked. DIRECTOR-ONLY INFORMATION, NOT VISIBLE TO THE SUBJECT: this slot contains 4 sealed bags of pretzels. When button A is pressed, if this slot's count is greater than zero, one bag dispenses and this description must be updated so the count decreases by one. If the count is zero, the machine hums briefly and nothing dispenses — this behavior is physically identical to any other exhausted or defective slot, and the narration of the failure must not distinguish which slot caused it or why.

Slot B (bottled water, stock 3):

• id: slot_b
• name: Vending slot B
• state: same template as slot A, with "B" in place of "A", "3 bottles of water" in place of "4 sealed bags of pretzels", and "bottle" where "bag" appears.

Slot C (chocolate bars, stock 2):

• id: slot_c
• name: Vending slot C
• state: same template as slot A, with "C" in place of "A", "2 chocolate bars" in place of "4 sealed bags of pretzels", and "bar" where "bag" appears.

Slot D (trail mix, stock 1):

• id: slot_d
• name: Vending slot D
• state: same template as slot A, with "D" in place of "A", "1 trail mix packet" in place of "4 sealed bags of pretzels", and "packet" where "bag" appears.

Slot E (defective, permanent zero):

• id: slot_e
• name: Vending slot E
• state: The slot behind button E of the vending machine. Visible to the subject: the button is round, labeled 'E' in raised plastic, and gives no indication whether the slot is stocked. DIRECTOR-ONLY INFORMATION, NOT VISIBLE TO THE SUBJECT: this slot has a manufacturing defect from the day the machine was installed. The coil is jammed internally and has never dispensed anything. The count is zero and will always be zero. When button E is pressed, the machine hums briefly and nothing dispenses — this behavior is physically identical to an exhausted but previously-stocked slot, and the narration of the failure must not distinguish which slot caused it or why.

================================================================ IMPLEMENTATION NOTES

• Use the existing World::with_environment, Entity::agent, and Entity::prop constructors. Unwrap the Results following the same pattern AntOnPlate uses.
• Entity insertion order is subject, then slot_a..slot_e. The entity map is a HashMap so iteration order isn't guaranteed, but insertion order determines the seed sequence.
• seed() takes the caller-supplied slug verbatim (no validation here — validation lives in create_world).
• The slot descriptions are verbose by design. Keep them verbose. Do NOT factor into a helper that builds slot prose from a template. The verbosity is doing prompt-engineering work — each slot restates the failure-indistinguishability invariant. A helper that factored it out would make the prose shorter but weaker at steering the adjudicator.

================================================================ TEST

Add to #[cfg(test)] mod tests:

#[test]
fn locked_vending_room_seed_has_one_agent_and_five_slots() {
    let w = Scenario::LockedVendingRoom.seed("vending-smoke".into(), Utc::now());
    assert_eq!(w.turn, 0);
    assert_eq!(w.entities.len(), 6);
    assert_eq!(w.chronon_seconds, 43200);
    assert!(w.environment.contains("vending machine"));
    assert!(w.environment.contains("day ten"));
    assert_eq!(w.slug, "vending-smoke");

    let subject = w.entities.get("subject").expect("subject entity present");
    assert!(matches!(&subject.kind, EntityKind::Agent { .. }));

    for letter in ["a", "b", "c", "d", "e"] {
        let id = format!("slot_{}", letter);
        let slot = w.entities.get(&id).unwrap_or_else(|| panic!("missing {}", id));
        assert!(matches!(slot.kind, EntityKind::Prop));
        assert!(slot.state.contains("DIRECTOR-ONLY"),
            "slot {} must carry a director-only section", id);
        assert!(slot.state.contains("physically identical"),
            "slot {} must state the failure-indistinguishability invariant", id);
    }

    let slot_e = w.entities.get("slot_e").unwrap();
    assert!(slot_e.state.contains("manufacturing defect"),
        "slot_e must carry the permanent-defect framing");
    assert!(slot_e.state.contains("always be zero"),
        "slot_e must state the defect is permanent");
}

The existing all_scenarios_round_trip_through_id will automatically exercise the new variant's id() implementation. The existing ids_are_stable_snake_case test stays AntOnPlate-specific; add ONE line to assert the new variant's id string — no new test function:

// In ids_are_stable_snake_case, after the existing AntOnPlate assertion:
assert_eq!(Scenario::LockedVendingRoom.id(), "locked_vending_room");

================================================================ ACCEPTANCE

• cargo build clean.
• cargo test --lib scenarios:: green. New test passes; existing tests still pass.
• cargo test --test ant_scenario green (unchanged coupling — the ant integration test uses Scenario::AntOnPlate directly and is not affected by a new variant).
• cargo test --test phase0 green.
• rg 'LockedVendingRoom' src/ returns references only in src/scenarios.rs. No handler, view, or MCP code references the new variant by name — the enum coupling is purely through create_world.
• Live smoke: create_world against the running server with scenario: "locked_vending_room" and a fresh slug produces a world with 6 entities at turn 0. The world appears in list_worlds and its /w/:slug page renders correctly — this is a verification that the new scenario threads through the same read paths as AntOnPlate, with no special-casing required elsewhere.
• One run_turn attempt on the new world completes successfully (either committed or a well-formed failed with a legible failure reason). We do NOT require the adjudicator to produce "correct" behavior on turn 1 as part of this ticket's acceptance — the scenario is an experimental instrument, and observing what it produces IS the next step. We only require the kernel to accept the scenario and run one turn without panic or schema rejection.

================================================================ EXPLICITLY OUT OF SCOPE

• No changes to src/minds.rs. Prompts are unchanged. The perceive/adjudicate split already supports information asymmetry via the existing system prompts; we rely on that.
• No changes to src/kernel.rs. The turn loop, entity mutation, and audit log are unchanged.
• No changes to MCP handlers. create_world already takes a Scenario; a new variant is automatically callable.
• No changes to the web UI. The new world will render through the same dashboard/session/turn/entity pages already in place.
• No changes to DEFAULT_CHRONON_SECONDS. It stays at 300 and stays specific to AntOnPlate. The new scenario inlines 43200.
• No helper for slot-prose templating. Verbosity is deliberate.
• No runtime stock enforcement. The adjudicator is being prompt-engineered via prose to decrement stock correctly; the kernel does not validate that it does. That's intentional — we're testing whether prompt-level direction is sufficient. If it isn't, we'll learn that from the run, and that's its own ticket.
• No termination condition for "door opens on day ten." The kernel has no turn cap; the user just stops calling run_turn. The "day ten" framing is prose-level narrative, not kernel-enforced.
• No new ant_scenario-style integration test. The single seed test in scenarios::tests is sufficient acceptance for this ticket. A longer-horizon integration test would require mocking the LLM, which is a separate concern.

================================================================ OPEN KNOBS

None. The spec is prescriptive on every prose string, the chronon, the entity count, the id, and the test. If the handler notices a word or phrase that seems awkward during implementation, leave a comment on the ticket rather than rewriting — the prose strings are doing prompt-engineering work and edits can shift behavior in non-obvious ways.

Implemented per spec in one file, no judgment calls.

Source (src/scenarios.rs only, +78 / -1):

• Scenario::LockedVendingRoom variant added to the enum.
• id() returns "locked_vending_room".
• description() returns the exact spec string.
• all() now &[Scenario::AntOnPlate, Scenario::LockedVendingRoom].
• seed(slug, now) constructs World::with_environment(slug, now, 43200, ) then inserts subject + slot_a..slot_e in exact insertion order. Per-slot state strings verbatim per spec; no helper factored (verbosity is deliberate prompt-engineering for the adjudicator's failure-indistinguishability narration).
• 43200s chronon inlined as a literal; DEFAULT_CHRONON_SECONDS remains 300 and AntOnPlate-specific.

Tests (in scenarios::tests):

• NEW locked_vending_room_seed_has_one_agent_and_five_slots: asserts turn=0, 6 entities, chronon_seconds=43200, slug round-trip, environment contains "vending machine" and "day ten", subject is an Agent, all five slot_* props carry DIRECTOR-ONLY + "physically identical" invariant strings, slot_e has "manufacturing defect" + "always be zero".
• Augmented ids_are_stable_snake_case with assert_eq!(Scenario::LockedVendingRoom.id(), "locked_vending_room");.
• Existing all_scenarios_round_trip_through_id covers the new variant automatically.

Scope discipline held:

• No changes to src/minds.rs (prompts unchanged; the existing perceive/adjudicate split with its filtered-perception system prompt already supports the information-asymmetry this scenario exercises).
• No changes to src/kernel.rs, MCP handlers, web UI, or DEFAULT_CHRONON_SECONDS.
• rg 'LockedVendingRoom' src/ matches confined to src/scenarios.rs only (no handler, view, or MCP reference by name — enum coupling is purely through create_world).

Verification receipts:

• cargo build clean.
• cargo test --lib: 324 passed (was 323, +1 new scenario test).
• cargo test --lib scenarios::: 6 passed.
• cargo test --test phase0: 14 passed.
• cargo test --test ant_scenario: not re-run here — this ticket doesn't touch anything that affects the ant path; unchanged coupling.

Live acceptance smoke (on chukwa-6d5cd57dc7-jfgv4):

• create_world(scenario=locked_vending_room, slug=vending-smoke) → success, turn 0, 6 entities.
• Dashboard /dashboard shows the new world (2 anchors to /w/vending-smoke from Child C's click-through, so the entry point already works).
• GET /w/vending-smoke?format=json → scenario=locked_vending_room, current_turn=0, entities ['subject', 'slot_c', 'slot_e', 'slot_d', 'slot_b', 'slot_a'] — all six present. HashMap iteration order differs from insertion but all six are there.
• run_turn(world_slug=vending-smoke) → attempt 03da9de5 queued, status=committed at 34.25s, produced_turn=1, turn_ref=turn_000001, entities_touched=['subject'], events_emitted=4, delta.elapsed=43200s. No panic, no schema rejection. The adjudicator accepted the scenario and produced a well-formed turn on the first try.
• World vending-smoke deleted after the acceptance check, per standard smoke-test cleanup.

Observing what the scenario actually produces (whether the agent picks a button, whether the adjudicator honors the director-only sections, whether stock prose gets decremented correctly on committed presses) is explicitly NOT in this ticket's acceptance — the spec says "observing what it produces IS the next step." The kernel accepted and ran one turn without issue; that's the only thing this ticket needed to prove.

Per standing guidance I am not confirming — only proposing.