Suite 666 documentation

Suite 666 is a first-person office simulation in which the place is not a backdrop. The suite is the central character hidden in the title: it holds the team's pressure, habits, absences, arguments, rituals, and work. The office's windows make the outside world equally present through weather, traffic, time, and events that continue without waiting for the player.

This documentation describes the implemented seven-day living-office release and records the historical and technical evidence behind the reconstruction. It is an implementation contract: generated prose and images may propose bounded material, but the browser remains authoritative over state, time, geometry, knowledge boundaries, safety, and what becomes visible in the world.

Fictional simulation

Every simulated person, relationship, product, campaign, artwork, and event is fictional. Names establish characters inside this work; generated output must not be presented as biography or historical testimony. Historical sources document the physical office and 1993 context only.

Product thesis

Three character layers drive the simulation:

1. Suite 666 is the main character. Its light, noise, clutter, maintenance, thresholds, and accumulated events express the state of the whole game.
2. The outside world is a second environmental character. Time, traffic, weather, deliveries, news, and the building impose pressure and opportunity.
3. The people alter and interpret those environments. They have bounded knowledge, private intent, schedules, and relationships, but they never own authoritative game state.

Read the world-character model Read the vertical-slice contract

Living-office release

The current release provides:

• a finite campaign from Day 1 at 9:00 AM through Day 7, with one authoritative browser clock, focus acceleration, sleep, tasks, deadlines, and a weekly playable build;
• Jesse Rourke as the embodied player founder, five scheduled autonomous founders, and fictional Donna Jackson as an optional office-manager hire who never participates in the team's tabletop campaign;
• semantic rooms, activity anchors, portals, capacity reservations, structural door actions, bounded locomotion, room-purpose placards, and physical collision for living-stage people and props;
• browser-owned relationships, commitments, memories, artifacts, inventory, weather, exterior events, D&D sessions, daily music genomes, and Curator plans;
• proximity conversations that can propose bounded records and work changes, with deterministic local dialogue as the default;
• a silent Curator that requests at most one bounded daily plan and falls back locally without blocking campaign advancement beyond its deadline;
• append-only local event persistence, replay, snapshots, corruption handling, compaction, and an explicit memory-only fallback;
• optional direct-browser DeepSeek BYOK for text and MiniMax image-01 for one fixed-prompt, memory-only Donna portrait;
• strict request/response validation, revision checks, cancellation, visible errors, and no execution of generated code or scene instructions.

Authority path

player, runtime rule, or validated proposal
                    |
                    v
finite event -> pure reducer -> invariant check -> expected-head append
                    |
                    v
       authoritative projection -> world, HUD, audio, and persistence

Provider requests receive filtered projections. Provider output is parsed and validated twice where private browser context is needed, then translated into browser-owned events. The model never receives a write handle to simulation state, the DOM, navigation, or storage.

Runtime boundaries

Route	Purpose
/	Interactive first-person simulation and reconstruction
/docs/	This MkDocs site
/graph/	Isolated asset-provenance graph
/tour	Intentionally absent

The applications are assembled into one immutable Nginx image. Documentation is prebuilt; no Python process or application backend runs in production.

Status language

Pages distinguish implemented behavior from a target contract. Current architecture pages describe the released runtime unless a section explicitly says otherwise. Dated project records preserve earlier decisions as historical context; they are not the current runtime interface.