Lab: The spec

Deliverable: SPEC.md, in the repo (the repo: your project folder, as git tracks it), one page, good enough that a stranger (or a strange AI) could build v1 from it without asking you anything important. Create the file in VS Code: File → New File, name it SPEC.md — a plain text file whose **bold** and # marks render as formatting.

1. 1Declare your variant (or keep the default) in two sentences: who it's for, what the loop is. Run the honesty check: is your loop actually Replyable's shape (inbox → detail → assisted response)? If it's drifted into a different app, either re-skin back or consciously accept you're off the course rails (allowed, but you're on your own for the deltas).
2. 2Draft the four sections with the assistant — give it the lesson's structure and your variant, let it draft, then edit hard: every sentence you can't defend gets rewritten or cut. The data model especially: rename the columns for your domain (a host's variant might rename subject → property), but keep the two-table shape and the fixed status list (new / replied / done).
3. 3Wireframe the three screens — paper, or boxes in any tool, ten minutes total. Then run the trace check both directions (screen elements ↔ columns). Fix the mismatches now; they're spec bugs, and spec bugs compound at 10× when they reach code.
4. 4Run all three adversarial passes and incorporate: expect 3-5 real catches (the empty-inbox state and the reopen-a-Done-message question catch nearly everyone). Note in the spec which edge cases v1 deliberately ignores — a documented punt beats a surprise.
5. 5Commit it: git add SPEC.md && git commit -m "spec v1". From here on, the spec travels with the code, and every assistant conversation that builds a feature starts by pasting the relevant spec section — context is the difference between an assistant that builds your app and one that builds an app.