## Product requirements

**AH-PRD-001 · Implemented baseline · September 9, 2026**

After Hours makes persistent agent behavior inspectable through a public arcade. A visitor should be able to see what an agent is doing, ask about it, and examine the engineering underneath. The underlying problem is coordinating model decisions, a changing environment, durable state and human messages when each operates at a different speed.

This is a retrospective specification of an independent project. It records the current product contract; it does not imply an earlier product committee, customer contract or formal design approval.

### Users and the useful outcome

A visitor wants a working game and a natural conversation. An engineering reader wants to follow a decision from requirement to implementation to evidence. An operator needs to distinguish a healthy website from a working agent, stop control safely, and recover without discarding progress.

The product succeeds when the interaction is understandable and the system's behavior is explainable. Time spent on the page, contact conversions, game completion rate and response latency have not been measured as product outcomes.

### Scope and acceptance criteria

| ID | Requirement | Acceptance criterion | Evidence / status |
| --- | --- | --- | --- |
| R1 | Show real emulation | Cabinet and focused view consume actual PNG frames associated with a resident/game; saved and provisional frames remain distinguishable. | Streaming tests and public WebSocket checks passed. |
| R2 | Preserve useful state | Restart restores the last committed screen; switching away and back restores the resident's own game checkpoint. | Recovery tests and all-15 catalog integration passed. |
| R3 | Keep control attributable | An old lease, wrong resident credential or public request cannot issue a valid game action. | Authority, epoch and exclusion tests passed. |
| R4 | Make chat delivery inspectable | A retry with the same request ID does not create a second request; only explicit reply/dismiss resolves its pending status. | Inbox tests; real visitor request received an answer. |
| R5 | Offer a universal environment | Each of three residents can choose any of fifteen installed titles when available; conflicting cabinet acquisition is rejected. | Catalog and resident tests; live switches to uCity and Flooder observed. |
| R6 | Operate independently of a visitor or laptop | VM services own the CLI workers and game cores; closing the page does not own their lifecycle. | VM sessions resumed and made actions with Mac launch agents disabled. |
| R7 | Support accessible exploration | Keyboard and touch move the visitor; all cabinet details are reachable through standard buttons; reduced motion retains a usable game view. | Desktop dialogs, Escape and 390px mobile checks passed. Full assistive-technology audit remains open. |
| R8 | Bound autonomous work | Resident and manager launch allowances survive restarts; exhaustion prevents more launches until capacity returns or an authorized reset occurs. | Manager budget tests and actual exhausted-ledger incident. |

### Constraints that shape the design

The project shares a VM with other applications. Public access uses existing HTTPS and a fixed edge route. Three active emulator cores cover the fifteen-game catalog; spectators do not create their own inference sessions. Model actions are based on screenshots and manuals, without game-memory reads. Only homebrew titles with reviewed license evidence are admitted, with pinned ROM hashes and attribution.

The selected runtime is GPT-5.6 Sol with low reasoning. Provider latency and quotas remain external dependencies. The work allowance limits scheduled turns, not dollars. A resident can be paused even while the website is healthy.

### Deliberate boundaries

Visitors can explore, watch and talk; they do not acquire emulator control credentials. Walking coordinates are local browser presentation, while agent destinations and cabinet occupancy come from the server. Fifteen games currently use one emulator family, PyBoy for Game Boy/Game Boy Color. Shared visitor presence, verified achievements, general game-playing competence, an uptime SLA and commercial production adoption are outside this baseline.

### Next measurements

Measure admission-to-reply latency with unanswered requests kept in the denominator; provider errors and budget pauses by reason; action timing alongside emulated time; stream age under slow clients; and save/restore behavior after injected failure. Define thresholds from a representative baseline before publishing service-level objectives or performance claims.