Add initial README and architecture decision records for venue-driven simulation game

- Introduced README.md outlining game concept, mechanics, and planned venues.
- Added ADRs for venue-driven architecture, de-escalation-first model, explicit access verification, local single-player focus, event-based incident recording, and choice of Godot 4 with GDScript.

docs/adr/0001-venue-driven-simulation-architecture.md

@@ -0,0 +1,34 @@
+# ADR-0001: Venue-driven simulation architecture
+
+- **Status:** Accepted
+- **Date:** TBD
+
+## Context
+
+The game is planned to include multiple venues with different access rules, equipment, crowd patterns, NPC mixes, and scenario events. The Hollywood Boulevard building, The Joke Shop comedy club, and the late-night TV studio share core interaction and escalation mechanics but differ in their policies and content.
+
+Hard-coding each venue into the simulation would make new scenarios expensive to create and would encourage inconsistent behavior between venues.
+
+## Decision
+
+Use a shared simulation core with venue-driven configuration and content. A `VenueScenario` supplies locations, access policies, equipment, NPC pools, dialogue, schedules, event pools, and escalation constraints. Shared systems handle movement, interactions, access verification, incidents, reputation, crowds, and shift review.
+
+## Consequences
+
+### Positive
+
+- New venues can reuse tested systems.
+- Venue rules remain visible and easier to review.
+- Scenarios can be tested independently of rendering.
+- Different venues can share NPC types while changing their context.
+
+### Negative
+
+- The data model must be designed carefully.
+- Some venue-specific behavior may need extension hooks.
+- Content authoring tools or validation will become important as the number of venues grows.
+
+## Alternatives considered
+
+- **One custom implementation per venue:** Rejected because it duplicates logic and increases maintenance cost.
+- **One universal ruleset:** Rejected because ID checks, wristbands, wand screening, and studio credentials have materially different behavior.

docs/adr/0002-de-escalation-first-escalation-model.md

@@ -0,0 +1,43 @@
+# ADR-0002: De-escalation-first escalation model
+
+- **Status:** Accepted
+- **Date:** TBD
+
+## Context
+
+The game involves security work, access denial, rare violent threats, and an emergency responder with greater authority. A design focused on attacking NPCs would undermine the intended workplace-simulation experience and make ordinary public behavior indistinguishable from danger.
+
+The plan explicitly calls for observation, gestures, dialogue, formal warnings, positioning, assistance, and emergency response in increasing levels.
+
+## Decision
+
+Represent escalation as explicit levels from 0 through 5:
+
+0. Observation
+1. Simple deterrence and polite direction
+2. Formal warning
+3. Blocking and physical positioning
+4. Radio for security assistance
+5. Emergency response
+
+The player is rewarded for selecting the lowest effective level. Emergency assistance is reserved for immediate threats and is evaluated after the incident. Physical force is not a default interaction.
+
+## Consequences
+
+### Positive
+
+- Reinforces judgment and communication as the main skills.
+- Makes simple actions, including raising a hand, mechanically meaningful.
+- Gives the player clear feedback about proportionality.
+- Keeps emergency response rare and consequential.
+
+### Negative
+
+- NPC reactions and threat assessment require more nuanced modeling.
+- Players may need clear feedback to understand why an escalation was or was not justified.
+- Designing fair edge cases will require playtesting.
+
+## Alternatives considered
+
+- **Combat-first design:** Rejected because it conflicts with the game’s core premise.
+- **Binary allow/deny interaction:** Rejected because it removes the interesting judgment between harmless behavior, refusal, and immediate danger.

docs/adr/0003-explicit-access-verification-system.md

@@ -0,0 +1,44 @@
+# ADR-0003: Explicit access-verification system
+
+- **Status:** Accepted
+- **Date:** TBD
+
+## Context
+
+Authorized people may need to enter the building, while unauthorized people may look similar or behave confidently. The plan requires the guard to recognize a person or inspect a wristband. Other venues add IDs, tickets, credentials, guest lists, and handheld wand screening.
+
+If access is decided only by NPC type or scripted identity, the player does not perform meaningful security work.
+
+## Decision
+
+Make access verification a dedicated system. It evaluates one or more access artifacts and venue policy, including:
+
+- Personal recognition
+- Wristband color, pattern, date, or event marking
+- Government-issued ID and age requirement
+- Ticket, reservation, or guest-list status
+- Staff, performer, or production credential
+- Prohibited-item and wand-screening results
+
+The player must inspect or select the relevant evidence. Valid, expired, counterfeit, mismatched, missing, and ambiguous artifacts are distinct outcomes. The system records both the evidence and the player’s decision for shift review.
+
+## Consequences
+
+### Positive
+
+- Makes admission decisions an active gameplay mechanic.
+- Supports all planned venues without changing the core interaction model.
+- Creates fair reasons for both admission and refusal.
+- Enables feedback when the player denies an authorized person or admits an unauthorized one.
+
+### Negative
+
+- The UI must present enough information without becoming tedious.
+- Content creators need tools for generating believable artifact variations.
+- False positives and ambiguous cases require careful balancing.
+
+## Alternatives considered
+
+- **Automatic recognition only:** Rejected because it removes verification gameplay.
+- **Appearance-based access:** Rejected because it is unreliable and conflicts with the intended design.
+- **One universal credential:** Rejected because venues have different admission policies.

docs/adr/0004-local-single-player-first.md

@@ -0,0 +1,32 @@
+# ADR-0004: Local single-player first
+
+- **Status:** Accepted
+- **Date:** TBD
+
+## Context
+
+The project is at the planning stage and no engine, backend, or multiplayer requirement has been established. The core experience is a single guard making decisions during a short shift. Early development needs fast iteration on rules, NPC behavior, UI, and scenario content.
+
+## Decision
+
+Build the first playable version as a local single-player game. Keep simulation, presentation, content, and shift results in one client process. Do not require an online service or multiplayer layer for the initial prototype.
+
+## Consequences
+
+### Positive
+
+- Reduces infrastructure and deployment complexity.
+- Makes deterministic scenario testing easier.
+- Allows the team to validate the core game loop before committing to networking.
+- Keeps the first vertical slice small.
+
+### Negative
+
+- Multiplayer and online analytics are deferred.
+- Some future features may require refactoring if they depend on network authority.
+- Local persistence and platform support still need to be designed later.
+
+## Alternatives considered
+
+- **Multiplayer-first:** Rejected because it adds complexity before the single-player loop is proven.
+- **Backend-first simulation:** Rejected because the planned game does not currently require a service or shared world.

docs/adr/0005-event-based-incident-recording.md

@@ -0,0 +1,37 @@
+# ADR-0005: Event-based incident recording
+
+- **Status:** Accepted
+- **Date:** TBD
+
+## Context
+
+The game needs body-camera evidence, radio reports, crowd reactions, reputation scoring, and a shift review. These systems all need to understand what happened during an interaction, including the NPC’s behavior, the player’s response, access evidence, escalation level, and final outcome.
+
+If each system observes gameplay independently, scoring can become inconsistent and replaying or reviewing an incident becomes difficult.
+
+## Decision
+
+Record important gameplay actions as structured incident events. Events should include an incident identifier, timestamp or simulation step, actor, observed behavior, player action, evidence, escalation level, response, and outcome where applicable.
+
+The incident recorder is the source for body-camera review, reputation evaluation, crowd consequences, radio accountability, and shift summaries. Presentation may display events, but it does not own the authoritative incident history.
+
+## Consequences
+
+### Positive
+
+- Creates consistent scoring and review across venues.
+- Makes debugging and automated tests easier.
+- Supports future replay, analytics, or accessibility features.
+- Keeps UI concerns separate from game rules.
+
+### Negative
+
+- Requires a stable event schema.
+- Event volume must be managed during busy crowd scenes.
+- Historical data may need migration when the schema changes.
+
+## Alternatives considered
+
+- **Each subsystem tracks its own state:** Rejected because it risks contradictory outcomes.
+- **Only store final shift scores:** Rejected because it cannot explain or review individual decisions.
+- **Record raw input only:** Rejected because raw input does not capture the interpreted situation or policy outcome.

docs/adr/0006-godot-4-gdscript.md

@@ -0,0 +1,34 @@
+# ADR-0006: Godot 4 with GDScript
+
+- **Status:** Accepted
+- **Date:** TBD
+
+## Context
+
+The project needs a game engine and programming language before implementation can begin. The game is a local single-player workplace simulation with navigation, crowds, NPC behavior, UI for access checks and dialogue, audio, and shift-scoring systems. The project benefits from fast iteration, low cost, and the ability to run rules and scenario tests headlessly.
+
+## Decision
+
+Use the Godot Engine 4.x with GDScript for gameplay logic. Model the venue-driven architecture as nodes, scenes, and custom `Resource` types. Use Godot's navigation, UI, audio, and headless mode. Test with the GUT framework.
+
+## Consequences
+
+### Positive
+
+- Free and open-source license with no per-seat or royalty cost.
+- Built-in 3D rendering, navigation, animation, UI, and audio reduce external dependencies.
+- GDScript is tightly integrated and fast to iterate on.
+- Headless mode supports deterministic, GUI-free automated tests.
+- Custom resources make scenario data editable and data-driven.
+
+### Negative
+
+- GDScript is less suited to very large, performance-critical systems than some alternatives.
+- The team commits to Godot's editor workflow and version cadence.
+- C# remains an option only if future needs justify adding a toolchain.
+
+## Alternatives considered
+
+- **Unity with C#:** Rejected due to licensing uncertainty and a heavier editor/workflow.
+- **Bevy with Rust:** Rejected because Rust adds friction and iteration time for a prototype team.
+- **Web-based TypeScript (Three.js/Babylon.js):** Rejected because Godot provides more out-of-the-box game systems and simpler desktop export.