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/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.