@maka/maka-cli 5.64.0 → 5.65.0

package/bundle/typescript/src/commands/game/sideQuest/factories/scene-chunks.d.ts

@@ -32,7 +32,15 @@ export interface ISkeletonExit {
     direction: string;
     targetRoom: string;
     keyRequired?: string;
-    puzzle?: string;
+    /** A devices[].name that holds this door shut. That device lives in
+     *  THIS room -- the one you must stand in to reach it. */
+    device?: string;
+    /** An npcs[].name who STANDS in this doorway and will not move.
+     *  Mutually exclusive with `device`: an exit is gated by a person or
+     *  by a mechanism, never both. The guard's position is DERIVED from
+     *  the exit they hold (see assembleScene), so the two cannot disagree
+     *  about where they are standing. */
+    guard?: string;
 }
 export interface ISkeletonRoom {
     name: string;
@@ -53,14 +61,21 @@ export interface ISkeletonNpc {
     plane?: 'meat' | 'matrix' | 'astral';
     startLocation: string;
 }
-export interface ISkeletonPuzzle {
+export interface ISkeletonDevice {
     name: string;
-    /** Room-anchored placement; omit for a door puzzle (referenced from exits[].puzzle). */
-    room?: string;
+    /** REQUIRED. A device is always room-owned -- a keypad beside a grate
+     *  physically stands in one room, the one you must be in to reach it.
+     *  An exit it holds is declared FROM that same room. */
+    room: string;
     concept: string;
-    bypassType?: 'lockpick' | 'hack' | 'spell' | 'con';
-    requiresPuzzle?: string;
-    rewardItem?: string;
+    /** lock (a mechanism -- picked, breached, or opened by its key),
+     *  panel (an interface -- a code, or hacked), ward (a working -- cast
+     *  at or dispelled). Anything unrecognised CLAMPS to 'panel' rather
+     *  than throwing: a device whose kind we cannot read is still a
+     *  device, and rejecting a whole draft over one word is a worse
+     *  outcome than a keypad where the model meant something else. */
+    kind?: 'lock' | 'panel' | 'ward';
+    grantsItem?: string;
 }
 export type SkeletonItemRole = 'winCondition' | 'reward' | 'key' | 'clue' | 'loot' | 'starting';
 export interface ISkeletonItem {
@@ -70,8 +85,8 @@ export interface ISkeletonItem {
     room?: string;
     heldBy?: string;
     plane?: 'meat' | 'matrix';
-    /** clue items only: which puzzle's requiredPhrase this clue reveals. */
-    forPuzzle?: string;
+    /** clue items only: which device's code this clue reveals. */
+    forDevice?: string;
 }
 export interface ISceneSkeleton {
     name: string;
@@ -79,7 +94,7 @@ export interface ISceneSkeleton {
     completionMessage: string;
     rooms: ISkeletonRoom[];
     npcs: ISkeletonNpc[];
-    puzzles: ISkeletonPuzzle[];
+    devices: ISkeletonDevice[];
     items: ISkeletonItem[];
     winCondition: {
         item: string;
@@ -123,13 +138,15 @@ export interface INpcDetail {
     dialogue: string[];
     combat?: Record<string, unknown>;
 }
-export interface IPuzzleDetail {
+export interface IDeviceDetail {
     name: string;
-    riddle: string;
-    requiredPhrase: string;
-    successMessage: string;
-    failureMessage: string;
-    lockedMessage?: string;
+    description: string;
+    /** ONLY meaningful on a 'panel'. You cannot talk at a mechanical
+     *  lock, and a ward answers to the Art -- neither has anything to
+     *  hear a phrase with. */
+    code?: string;
+    openMessage: string;
+    refuseMessage: string;
     guardsExit?: string;
     footprint?: 'small' | 'medium' | 'large';
 }
@@ -150,7 +167,7 @@ export interface IItemDetail {
 export interface ISceneDetails {
     rooms: IRoomDetail[];
     npcs: INpcDetail[];
-    puzzles: IPuzzleDetail[];
+    devices: IDeviceDetail[];
     items: IItemDetail[];
 }
 /**
@@ -159,20 +176,21 @@ export interface ISceneDetails {
  * Returns '' when no player is available.
  */
 /**
- * SPELL OUT THE CLUE RULE, IN THIS RUNNER'S TERMS. The dossier already
- * hints at it in prose ("con"-bypass barriers for a talker), and the
- * model still missed it: the single most common generation failure on
- * record is a barrier this runner can't open with no clue written for
- * it. It's character-dependent, which is what made it look like random
- * flakiness -- a Face satisfies exactly ONE of the four bypass types, so
- * three quarters of the barriers the model naturally reaches for demand
- * a clue item, and it keeps forgetting.
+ * THE ONE BARRIER RULE THAT STILL DEPENDS ON WHO IS PLAYING.
+ *
+ * This used to name all three barrier types the runner could and could
+ * not force, and demand a clue for each one they could not -- the
+ * single most common generation failure on record, and one that looked
+ * like random flakiness precisely because it varied with the character.
  *
- * So state it mechanically instead of hinting: name the types they can
- * and can't do, and name the consequence. normalizeSkeleton repairs this
- * anyway -- this is the half that stops the fault being authored at all.
+ * It shrank to this because the clue/key rule became UNCONDITIONAL for
+ * panels and locks (see partyCanDispel): a code is findable and a key
+ * is placeable, so both are openable by ANY runner and there is nothing
+ * character-dependent left to state. A ward is the exception that
+ * cannot be written away -- no clue rescues it for a mundane team -- so
+ * it is the only thing this still says.
  */
-export declare function bypassBrief(player: Player): string;
+export declare function wardBrief(player: Player): string;
 export declare function buildPlayerDossier(player?: Player): string;
 /** The crew summary generation scales opposition against (Phase A of
  *  the party system): name, archetype, and the statline headline. */
@@ -196,20 +214,34 @@ export declare function partyHeadcount(crew?: ICrewDossierEntry[]): number;
 export declare function buildSkeletonPrompt(tier: number, player?: Player, previousError?: string, rumor?: string, crew?: ICrewDossierEntry[], canonBlock?: string): string;
 export declare function buildRoomsPrompt(skeleton: ISceneSkeleton, previousError?: string): string;
 export declare function buildNpcsPrompt(skeleton: ISceneSkeleton, previousError?: string): string;
-export declare function buildPuzzlesPrompt(skeleton: ISceneSkeleton, previousError?: string): string;
-export declare function buildItemsPrompt(skeleton: ISceneSkeleton, puzzles: IPuzzleDetail[], previousError?: string): string;
+export declare function buildDevicesPrompt(skeleton: ISceneSkeleton, previousError?: string): string;
+export declare function buildItemsPrompt(skeleton: ISceneSkeleton, devices: IDeviceDetail[], previousError?: string): string;
 /**
- * Whether THIS runner can reliably work a barrier of the given bypassType
- * with their own hands -- no written-down credential required. This is
- * what loosens the "every puzzle needs a discoverable clue" rule when the
- * scene is generated against a dossier: a lockpick maglock in a scene
- * built for a master locksmith doesn't need its code lying in a book --
- * the pick IS their route. Deliberately conservative: EXPLICIT skill
- * ratings only (the combatSkill fallback would let any bruiser "qualify"
- * as a hacker), threshold 3 (trained professional), and with no dossier
- * at all the strict clue rule stays.
+ * Can anyone at this table unweave a WARD?
+ *
+ * The last surviving branch of what used to be canBypassUnaided, which
+ * asked the same question of all three barrier kinds. The other two are
+ * gone because their answers stopped mattering (ruling 2026-08-27):
+ *
+ *   A PANEL takes a code, and a code is FINDABLE. Write it down and any
+ *   runner can type it; a decker who did not need it loses nothing.
+ *   A LOCK takes a key, and a key is FINDABLE. Place it and any runner
+ *   can carry it to the door; picking becomes the SHORTCUT for someone
+ *   with locksmith, not the requirement.
+ *
+ * So for those two the clue/key rule is UNCONDITIONAL now, and the
+ * character-dependent waiver is gone with the condition it rested on.
+ *
+ * A WARD is irreducible. There is no findable answer to a ward; it takes
+ * Magic. A mundane team cannot dispel one however much is written down,
+ * so a ward generated for a party with nobody awakened is an unopenable
+ * barrier no clue can rescue. That is where the character dependence is
+ * REAL rather than incidental, and it is the only place this survives.
+ *
+ * Named for what it now is: a one-case function still called
+ * canBypassUnaided would attract the other two cases back.
  */
-export declare function canBypassUnaided(player: Player | undefined, bypassType?: string): boolean;
+export declare function partyCanDispel(player: Player | undefined): boolean;
 /** Strips accidental markdown fences and parses; throws with a useful message. */
 export declare function parseJsonReply<T>(reply: string): T;
 /**
@@ -218,7 +250,14 @@ export declare function parseJsonReply<T>(reply: string): T;
  * matrix defense...) are still enforced by the assembled-scene validators.
  */
 export declare function validateSkeleton(skeleton: ISceneSkeleton, player?: Player, crew?: ICrewDossierEntry[]): void;
-export declare function normalizeSkeleton(skeleton: ISceneSkeleton, player?: Player): string[];
+/**
+ * `player` is GONE from this signature, not underscored. Its only
+ * consumer was the character-dependent clue waiver, and with the
+ * clue/key rule unconditional there is nothing here that varies with
+ * who is playing. A parameter kept "just in case" is an invitation to
+ * make normalization character-dependent again.
+ */
+export declare function normalizeSkeleton(skeleton: ISceneSkeleton): string[];
 /**
  * THE ANSWER HAS TO BE WRITTEN DOWN. The other half of the clue problem,
  * and the more expensive half.
@@ -290,7 +329,7 @@ export declare function resolveSpotName(declared: string, spotNames: string[]):
  */
 export declare function ensureCredentialKindAgrees(details: ISceneDetails): string[];
 export declare function assembleScene(skeleton: ISceneSkeleton, details: ISceneDetails, playerName: string): ISceneSeedJson;
-export type RepairTarget = 'rooms' | 'npcs' | 'puzzles' | 'items' | 'skeleton';
+export type RepairTarget = 'rooms' | 'npcs' | 'devices' | 'items' | 'skeleton';
 /**
  * Maps a validation failure to the chunk that owns the broken content, so
  * a repair regenerates ONE pass instead of the whole scene. Anything