5ff1d54efa
The map, handoff, plan and Session Zero doc now name plan step 16, the play agent, as the playtest gate. L2-L4, D1-D3 and the L1 follow-ups are recorded as deferred by ruling, not dropped. A source check corrected the map. Inference routes per lane by model name to the SDK sidecar or CodexConnector, and no local transport exists. The sidecar is a private msgpack pipe behind InferencePort, not the CultNet connector API the map claimed every backend shares. The handoff's session_zero.begin item is retired: the name is refused, and only tests reference it. One evidence record covers the pivot. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
120 lines
6 KiB
Markdown
120 lines
6 KiB
Markdown
# Ghostlight Dungeon Session Zero
|
||
|
||
Status: adopted direction, 2026-09-15. Not implemented. Its role as the
|
||
playtest gate is superseded (operator, 2026-09-22) by the play agent,
|
||
`ghostlight-play-agent.md` (plan step 16). D1–D3 and the library passes
|
||
L2–L4 they consume are deferred by ruling, not dropped. Plan step 15 in
|
||
`notes/ghostlight-implementation-plan.md` carries the deferred pass order.
|
||
|
||
## Ownership
|
||
|
||
Session Zero is Ghostlight Dungeon's concept and Dungeon's authority. Dungeon
|
||
is a consumer of the Ghostlight library. Session Zero consumes library
|
||
capabilities through their generic surfaces and adds nothing Dungeon-shaped
|
||
to the library: no Vault registry, player, slider, starting location, or
|
||
Session Zero phase exists in the library vocabulary.
|
||
|
||
The library capabilities it needs are specified, consumer-neutral, in
|
||
`ghostlight-world-ontology.md` under "Elaboration lenses and detail rules
|
||
(target)": the stock lens set and weights, detail rules, per-world evidence
|
||
binding, and elaborator sessions in Draft. Other consumers use the same
|
||
capabilities with their own policy; Delvehold, for one, starts from a
|
||
`Uniform` detail rule.
|
||
|
||
The world kernel lives in the `ghostlight` library crate
|
||
(`crates/ghostlight/`); `ghostlight-dungeon` consumes it across a public
|
||
boundary and cannot reach its internals.
|
||
|
||
## Objective
|
||
|
||
A player chooses a Vault, says what kind of experience they want, and gets a
|
||
world seeded from that Vault. The world is dense where they stand and sketched
|
||
where they don't, and it grows detail ahead of them as they travel. The flavor
|
||
of the world comes from how often each of the eight stock lenses works on it.
|
||
|
||
## The flow
|
||
|
||
1. **Choose a Vault.** The player picks from Vaults the Dungeon operator has
|
||
admitted. A Dungeon Vault entry names its root and the scope a player may
|
||
read, for example Kalsa's `Public`. The payload carries a Vault id, never a
|
||
path. Dungeon binds the chosen Vault as the world's evidence source.
|
||
2. **Describe the experience.** The player writes what they want. A model
|
||
reads that description and proposes weights for the eight stock lenses. The
|
||
proposal fills the sliders; the player adjusts them. Dungeon submits only
|
||
the numbers and the description, which becomes the world brief.
|
||
3. **Create.** Dungeon creates a library world with title, brief, the stock
|
||
lens set and weights, and Dungeon's detail rule with no anchor yet. No
|
||
player subject is declared yet, so every place sits at the rule's floor.
|
||
4. **Sketch.** Dungeon's seed session authors a coarse world from the Vault:
|
||
regions, routes with travel costs, institutions, populations.
|
||
5. **Choose a start.** The player picks a sketch place. Dungeon submits one
|
||
owner patch declaring the player's human-controlled subject there, and pins
|
||
that subject as the first anchor of its detail rule.
|
||
6. **Elaborate.** The library's elaborator sessions run, pulled toward the
|
||
anchors by distance.
|
||
7. **Activate** when the player chooses. Dungeon never makes activation wait
|
||
on a count.
|
||
8. **Play.** As the player travels, the library's derived demand follows the
|
||
anchor and detail follows the player.
|
||
|
||
## Dungeon policy
|
||
|
||
- **Lenses:** the library's stock set of eight, weighted by the player's
|
||
sliders. The owner may change weights in Draft and Active; later sessions use
|
||
the new weights.
|
||
- **Detail rule:** `ByDistance`, anchored on important subjects, the player
|
||
first. Recommended levels: within 60 minutes, persons, institutions, and
|
||
populations; within 1 day, institutions and populations; beyond, institutions
|
||
only; lookahead 120 minutes. Tuned on the road. Which other subjects Dungeon
|
||
pins, and when, is Dungeon policy not yet decided.
|
||
- **Travel:** Dungeon's seed authors a travel affordance for persons, and the
|
||
Eve surface projects one control per affordance a player's subject holds.
|
||
|
||
## Authority map (Dungeon)
|
||
|
||
- **Owner:** Dungeon's runtime owns Session Zero's flow, the Vault registry,
|
||
the weight proposal, the player principal, anchor pinning, and the Eve
|
||
surface. Every world change it makes is an ordinary library command.
|
||
- **Inputs:** the authenticated player, the admitted Vault list, the player's
|
||
description and slider values, the chosen start place.
|
||
- **Outputs:** library world creation, seed and owner patches, rule and
|
||
weight changes, activation, and Eve projections.
|
||
- **Derived state:** the slider proposal, the Session Zero step a player is on
|
||
(derived from the library snapshot's phase, rule anchors, and structure), and
|
||
every projection.
|
||
- **Forbidden writers:** Dungeon writing world state other than through
|
||
library commands; the proposal model submitting weights without the
|
||
player's command; a Vault path in any payload; any Dungeon identifier,
|
||
schema, or policy entering the library vocabulary.
|
||
|
||
## Cut line (Dungeon)
|
||
|
||
- `GHOSTLIGHT_SEED_VAULT_ROOT` as the only Vault: Dungeon's Vault registry
|
||
replaces it.
|
||
- The `world.create` payload fields for jurisdiction roots and permille, when
|
||
the library's detail rule replaces them.
|
||
- The genesis human subject: Dungeon declares its player at the chosen start.
|
||
|
||
## Verification (Dungeon)
|
||
|
||
1. A player-chosen Vault id resolves only to an admitted Vault and scope; an
|
||
unknown id or a path is refused before anything is spent.
|
||
2. The slider proposal changes nothing until the player submits weights.
|
||
3. The start choice declares exactly one player subject, at a sketch place,
|
||
once, in Draft, and pins it as the rule's first anchor.
|
||
4. Activation succeeds with nonzero deficits.
|
||
5. Road: a seeded world on the SDK route shows persons near the start,
|
||
institutions far from it, and new persons at a place after the player's
|
||
subject travels toward it.
|
||
|
||
## Pass order
|
||
|
||
Library passes L0 through L4 are in plan step 15; L0 is the kernel
|
||
extraction. Dungeon passes follow them:
|
||
|
||
1. Vault registry, world creation with Vault id, brief, lens weights, and
|
||
detail rule.
|
||
2. The Session Zero Eve surface: Vault choice, description, slider proposal,
|
||
sliders, sketch, start choice, activation.
|
||
3. Travel affordance and per-affordance player controls. This pass closes the
|
||
playtest gate.
|