2.3 KiB
2.3 KiB
Codex Agent Guide — CoopGameChooser
This repo is a tiny, purpose-built web app for a closed Discord group to:
- submit game suggestions blindly
- reveal all suggestions with authors
- vote 0–10 blindly
- reveal totals sorted by score
Tech constraints:
- .NET 10
- ASP.NET Core Minimal API
- Static HTML/CSS/JS (no Razor Pages, no Blazor, no HTMX)
- SQLite via EF Core
- Cookie-based anonymous identity (no accounts)
- Single active “session” (one room) unless extended later
- Runs on IIS (Windows Server)
This file tells Codex how to work in this repo. Also see the other related files: API.md, IIS.md, SPEC.md
Operating Principles
Non-negotiables
- Server-side enforcement of phase rules (clients must not be trusted).
- Blindness:
- Suggest phase: player can only read/write their own suggestions.
- Vote phase: player can only read/write their own votes.
- Results phase: only aggregated totals are shown.
- Minimal moving parts: prefer
Program.cs+ a few small files over frameworks.
“Ridiculously fast” bias
- Prefer “ship a working MVP” over architecture purity.
- Avoid introducing new dependencies unless they remove complexity.
Repo Layout Target
Program.cs— Minimal API endpoints, middleware, cookie identity, admin endpointsData/— EF Core DbContext and migrations (optional for MVP)Domain/— Plain models: Player, Suggestion, Vote, AppState, Phase enumwwwroot/index.html— app shell; loads phase-specific viewsapp.js— API client + render functions + pollingstyles.css— minimal styling
Do not introduce MVC controllers, Razor Pages, Blazor, or SPA frameworks.
Implementation Checklist (Codex should follow this order)
- App boots and serves static files
- Cookie-based anonymous identity
- Phase gating (server-side)
- Suggest phase (blind input)
- Reveal phase (read-only)
- Vote phase (blind scoring)
- Results phase (aggregated leaderboard)
- Admin controls (phase switch, reset)
Security Notes
- Cookie must be HttpOnly and SameSite=Strict
- Use HTTPS in production
- No client-side trust for blindness
Codex Working Style
- Implement API first, UI second
- Keep changes small and testable
- Prefer clarity over abstraction
- After every iteration, do a git commit with a brief summary of the changes as a commit message.