## Return brief

The whole project is one file: `PROJECT.md` (9 lines). There is no code, no git history, no notes, no tests, no config — so most of what a "return brief" would normally reconstruct isn't recoverable from disk.

**What we're trying to achieve** (stated in `PROJECT.md:1-6`)
A small signup page for a neighborhood volunteer event — fictional demo. A visitor sees the date, location, and available roles, and submits an RSVP. The coordinator needs a readable list of the RSVPs.

**What's established**
- RSVP fields in the draft are `name`, `email`, `role` (`PROJECT.md:7`).
- No backend exists yet — that's a deliberate current-state note, not necessarily a permanent constraint.
- Nothing has been implemented or tested (`PROJECT.md:8`).
- Choosing the next increment is explicitly left open to whoever picks this up.

**Where we stopped**
At the very beginning. The file reads as a project brief written before any work started, not as a checkpoint mid-build. There is no evidence of a prior working session — no scaffolding, no abandoned drafts, no dependency manifest.

**What I cannot recover**
- Any prior conversation, decisions made verbally, or rejected approaches.
- Tech stack and framework: unchosen or at least unrecorded.
- The concrete event details (actual date, location, the list of roles) — the brief says these should be *displayed*, but never says what they are.
- How RSVPs should persist without a backend (in-memory? localStorage? a JSON file?) and whether the coordinator's list is the same page, a separate view, or an export.
- Whether "readable list" implies any filtering/sorting/grouping by role.
- Who the audience is for this demo and what "done" looks like.

**Next useful step**
Stand up a single static HTML page with the RSVP form (`name`, `email`, `role`) plus a rendered list of submitted RSVPs held in browser state. That is the smallest thing that makes both halves of the brief visible at once, needs no stack decision you'd regret, and turns the open questions above into concrete ones you can answer by looking at it.

Before I'd build it, two things genuinely change the shape of the work, so worth a word from you: (1) the real event details and role list, or confirmation that placeholders are fine; (2) whether RSVPs need to survive a page refresh. Everything else I'd decide as I go.
