XonkelX · XonkelX · Aug 4, 2026 · Jul 26, 2026 · Jul 27, 2026 · Jul 27, 2026
diff --git a/README.md b/README.md
diff --git a/docs/architecture/adr-002-supabase-realtime.md b/docs/architecture/adr-002-supabase-realtime.md
@@ -1,6 +1,6 @@
 # ADR 002: Supabase PostgreSQL and Realtime
 
-**Status:** implemented locally; remote Free validation recorded in the pull request and final Story 2 report
+**Status:** accepted and implemented in Story 2; production validated in Story 3
 
 ## Context and requirements
 
@@ -36,6 +36,6 @@ Every successful mutation increments `queues.revision` exactly once. Entry rows
 
 ## Free-plan constraints and risks
 
-As verified on 2026-07-17, [Supabase Free pricing](https://supabase.com/pricing) lists two active projects, 500 MB database size, 5 GB egress, and pausing after roughly one week of low activity. [Realtime pricing](https://supabase.com/docs/guides/realtime/pricing) and [limits](https://supabase.com/docs/guides/realtime/limits) remain quota-bound. No keep-alive, paid add-on, trial, or public deployment is part of Story 2.
+As verified on 2026-07-17, [Supabase Free pricing](https://supabase.com/pricing) listed two active projects, 500 MB database size, 5 GB egress, and pausing after roughly one week of low activity. [Realtime pricing](https://supabase.com/docs/guides/realtime/pricing) and [limits](https://supabase.com/docs/guides/realtime/limits) remain quota-bound and should be rechecked before operational use. No keep-alive, paid add-on, or trial is part of the project; Story 3 subsequently validated the public deployment on the existing Free project.
 
 Remaining hardening includes CAPTCHA or stronger anonymous abuse protection, cleanup of abandoned anonymous identities, capability rotation/recovery, more durable distributed attempt throttling, operational monitoring, data retention policy, and reassessment of Broadcast at scale. The current throttle is five failed attempts per user/queue/15-minute window with a 15-minute block; it is deliberately modest, not commercial brute-force protection.
diff --git a/docs/architecture/realtime-evaluation.md b/docs/architecture/realtime-evaluation.md
@@ -1,6 +1,6 @@
 # Real-time architecture evaluation
 
-**Decision status:** proposed for Story 2
+**Decision status:** accepted and implemented in Story 2; production validated in Story 3
 
 **Last verified against official documentation:** 2026-07-17
 
@@ -33,7 +33,7 @@ Spike **Supabase Postgres + Realtime** behind `QueueRealtimeAdapter` in Story 2.
 5. Track a monotonic queue revision or `updated_at` plus stable event ordering so stale updates are discarded.
 6. Exercise concurrent `call next`, network interruption, background-tab reconnect, free-project wake behavior, and quota exhaustion before any deployment decision.
 
-Supabase is not installed and the adapter is not implemented in Story 1. This document is a recommendation, not a claim of production synchronization.
+At the Story 1 decision point, Supabase was not installed and the adapter was not implemented. Story 2 subsequently implemented this recommendation, and Story 3 validated it in production. The comparison remains as the decision record rather than current implementation guidance.
 
 ## Cost controls
 
@@ -47,7 +47,7 @@ Supabase is not installed and the adapter is not implemented in Story 1. This do
 ## Rejected assumptions and unresolved risks
 
 - Free tiers and beta capabilities change; the figures above are dated evidence, not a permanent guarantee.
-- Supabase hosted Free projects may have wake/suspension behavior that harms an always-ready service counter. Current behavior must be measured in the Story 2 spike.
+- Supabase hosted Free projects may have wake/suspension behavior that harms an always-ready service counter. Story 3 observed and documented the expected inactive-project pause and restore behavior.
 - Anonymous Version 1 staff control needs a safe capability model. With no authentication, a high-entropy staff capability or another narrow authorization scheme must prevent public clients from issuing staff commands without collecting personal data.
 - Postgres-change delivery is not itself a durable client event log. Reconnect must always resync a snapshot, and commands need idempotency keys.
 - The 200-connection free quota is sufficient for a portfolio demonstration and very small deployments, not broad production scale.

diff --git a/docs/assets/screenshots/customer-status.png b/docs/assets/screenshots/customer-status.png
diff --git a/docs/assets/screenshots/dark-theme.png b/docs/assets/screenshots/dark-theme.png
diff --git a/docs/assets/screenshots/landing-page.png b/docs/assets/screenshots/landing-page.png
diff --git a/docs/assets/screenshots/mobile-view.png b/docs/assets/screenshots/mobile-view.png
diff --git a/docs/assets/screenshots/public-display.png b/docs/assets/screenshots/public-display.png
diff --git a/docs/assets/screenshots/queue-creation.png b/docs/assets/screenshots/queue-creation.png
diff --git a/docs/assets/screenshots/staff-board.png b/docs/assets/screenshots/staff-board.png
diff --git a/docs/assets/video/next-v1-demo.mp4 b/docs/assets/video/next-v1-demo.mp4
diff --git a/docs/design/story-4/01-home.png b/docs/design/story-4/01-home.png
diff --git a/docs/design/story-4/02-demo-create.png b/docs/design/story-4/02-demo-create.png
diff --git a/docs/design/story-4/03-customer-join.png b/docs/design/story-4/03-customer-join.png
diff --git a/docs/design/story-4/04-customer-status.png b/docs/design/story-4/04-customer-status.png
diff --git a/docs/design/story-4/05-staff-board.png b/docs/design/story-4/05-staff-board.png
diff --git a/docs/design/story-4/06-public-display.png b/docs/design/story-4/06-public-display.png
diff --git a/docs/design/story-4/07-about.png b/docs/design/story-4/07-about.png
diff --git a/docs/design/story-4/README.md b/docs/design/story-4/README.md
@@ -0,0 +1,24 @@
+# Story 4 visual direction
+
+These seven boards document the approved ticket-led direction for the v1.0
+portfolio presentation. They are design references rather than screenshots of
+the running application.
+
+The system follows the selected red-ticket reference: condensed black display
+type, warm paper surfaces, cobalt information bands, visible rules, generous
+queue numerals, functional iconography, and dense but legible operational
+layouts. The same language is applied across marketing and product surfaces.
+
+| Board                    | View                                     |
+| ------------------------ | ---------------------------------------- |
+| `01-home.png`            | Landing page and product positioning     |
+| `02-demo-create.png`     | Demo and queue creation                  |
+| `03-customer-join.png`   | Customer check-in before joining         |
+| `04-customer-status.png` | Customer ticket after joining            |
+| `05-staff-board.png`     | Staff operations and waiting list        |
+| `06-public-display.png`  | Distance-readable public display         |
+| `07-about.png`           | Project principles and portfolio context |
+
+Production captures live under `docs/assets/screenshots/`; the silent walkthrough
+lives under `docs/assets/video/`. Keeping references and captures separate makes
+the design intent reviewable without presenting concept art as shipped UI.
diff --git a/docs/product/scope.md b/docs/product/scope.md
@@ -33,4 +33,4 @@ Permanent email/password or social accounts, organizations, teams, billing, subs
 
 Version 1 is done when all three surfaces are polished and understandable, domain invariants hold under concurrent commands, connected screens synchronize and recover, accessibility and narrow responsive QA pass, free-tier operation is verified without payment information, CI is green, production security is reviewed, and documentation does not overstate capabilities.
 
-Story 1 satisfies the visual and domain foundation. Story 2 implements persistent PostgreSQL state, anonymous identity, transactional commands, database authorization, filtered Realtime invalidation, revisioned snapshots, reconnect convergence, and local multi-client validation. Public application deployment and production operations remain explicitly out of scope.
+Story 1 established the visual and domain foundation. Story 2 implemented persistent PostgreSQL state, anonymous identity, transactional commands, database authorization, filtered Realtime invalidation, revisioned snapshots, reconnect convergence, and multi-client validation. Story 3 completed the reviewed production deployment and remote acceptance testing. Story 4 prepares the finished system for its public v1.0 portfolio release without expanding product scope.
diff --git a/docs/releases/v1.0.0.md b/docs/releases/v1.0.0.md
@@ -0,0 +1,56 @@
+# v1.0.0 — Next Real-Time Queue System
+
+Next v1.0.0 is the first portfolio release of a production-deployed, persistent queue for small service teams. Customers, staff, and a public display stay synchronized through transactional PostgreSQL commands, filtered Supabase Realtime invalidation, and authoritative revisioned snapshots.
+
+## Highlights
+
+- Anonymous queue creation and customer check-in without permanent accounts or contact details
+- Queue-scoped one-time staff capability with database-enforced membership
+- Customer number, position, and turn status
+- Staff call, complete, skip, pause, reopen, and close workflows
+- Distance-readable public display with queue numbers only
+- Responsive light/dark UI, reduced motion, keyboard support, and accessible live status
+- Reconnect recovery and multi-client convergence without healthy-state polling
+
+## Reliability and security
+
+- All writes use explicit security-definer RPCs; browser roles have no direct table mutation grants.
+- RLS covers all eight application tables, and only `queues` and display-safe `queue_entries` are published to Realtime.
+- Row locks, state constraints, and a partial unique index preserve the one-serving invariant under concurrent commands.
+- Request UUID receipts make retries idempotent and reject mismatched reuse.
+- Staff codes are hashed, returned once, and excluded from URLs, logs, events, seeds, bundles, and retained release media.
+- Optional customer names are separated from public queue state and visible only to the owner or authorized staff.
+
+## Validation
+
+- 34 Vitest unit/component checks, including 9 focused Realtime tests
+- 62 pgTAP database checks
+- 11 Supabase integration checks
+- 15 Playwright application checks
+- 9 read-only production smoke checks
+- 131 passing automated checks in total without double-counting the focused Realtime subset
+- Formatting, lint, typecheck, production build, database reset/lint/type generation, and dependency audit pass
+- Production responsive, keyboard, focus, zoom, reduced-motion, dark-theme, privacy, reconnect, concurrency, and multi-client QA pass
+
+## Deployment
+
+- Production: https://next-queue-omega.vercel.app
+- Vercel Hobby with Node.js 22.x
+- One Supabase Free project in `us-east-1`
+- No paid service, trial, custom domain, analytics, storage add-on, or payment method
+
+## Known limitations
+
+- Free-tier projects have finite capacity and Supabase may pause after inactivity.
+- Anonymous identities cannot be recovered after browser data is cleared.
+- A lost one-time staff code cannot be recovered without an authorized session.
+- Enterprise abuse protection, monitoring, backup/recovery guarantees, automated retention, and a commercial SLA are outside v1.0.
+
+## Release checklist
+
+- [x] Story 3 production deployment merged and green
+- [x] Recruiter-facing documentation and release media prepared
+- [x] Synthetic release-capture data removed from application tables and Auth
+- [ ] Story 4 pull request reviewed and merged
+- [ ] Tag `v1.0.0` created from the final `main` commit
+- [ ] GitHub release published with these notes and the demo video attached
diff --git a/docs/security/authorization.md b/docs/security/authorization.md
@@ -26,4 +26,4 @@ Every exposed function revokes public/`anon` execution and grants only `authenti
 
 ## Known limitations
 
-Anonymous identity cannot be recovered after site-data clearing or transferred automatically to another device. Automatic cleanup of abandoned anonymous Supabase users is not built in. Capability rotation/recovery, stronger abuse prevention, operational alerting, formal retention/deletion policy, penetration testing, and a production SLA are outside Story 2. This project claims no security certification.
+Anonymous identity cannot be recovered after site-data clearing or transferred automatically to another device. Automatic cleanup of abandoned anonymous Supabase users is not built in. Capability rotation/recovery, stronger abuse prevention, operational alerting, formal retention/deletion policy, penetration testing, and a production SLA are outside v1.0. This project claims no security certification.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -33,4 +33,4 @@ Permanent email/password or social accounts, organizations, teams, billing, subs

		Version 1 is done when all three surfaces are polished and understandable, domain invariants hold under concurrent commands, connected screens synchronize and recover, accessibility and narrow responsive QA pass, free-tier operation is verified without payment information, CI is green, production security is reviewed, and documentation does not overstate capabilities.

		Story 1 satisfies the visual and domain foundation. Story 2 implements persistent PostgreSQL state, anonymous identity, transactional commands, database authorization, filtered Realtime invalidation, revisioned snapshots, reconnect convergence, and local multi-client validation. Public application deployment and production operations remain explicitly out of scope.
		Story 1 established the visual and domain foundation. Story 2 implemented persistent PostgreSQL state, anonymous identity, transactional commands, database authorization, filtered Realtime invalidation, revisioned snapshots, reconnect convergence, and multi-client validation. Story 3 completed the reviewed production deployment and remote acceptance testing. Story 4 prepares the finished system for its public v1.0 portfolio release without expanding product scope.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -26,4 +26,4 @@ Every exposed function revokes public/`anon` execution and grants only `authenti

		## Known limitations

		Anonymous identity cannot be recovered after site-data clearing or transferred automatically to another device. Automatic cleanup of abandoned anonymous Supabase users is not built in. Capability rotation/recovery, stronger abuse prevention, operational alerting, formal retention/deletion policy, penetration testing, and a production SLA are outside Story 2. This project claims no security certification.
		Anonymous identity cannot be recovered after site-data clearing or transferred automatically to another device. Automatic cleanup of abandoned anonymous Supabase users is not built in. Capability rotation/recovery, stronger abuse prevention, operational alerting, formal retention/deletion policy, penetration testing, and a production SLA are outside v1.0. This project claims no security certification.