After an open house, get a 'Thanks for stopping by' email to approve, addressed to the visitors who signed in #79

A listing with an open house now gets a "Thanks for stopping by" email draft, and its email page lists the visitors it would go to. The full bun test run is green (297 pass). I did not run scripts/gate.ts or design-lint: neither exists in this repository (bun run lint:design ran clean). There is no tsconfig.json, so the type check did nothing. The app sends nothing.

Finding on #43: the sign-in sheet there is blank paper and stores nothing, so there were no visitors to list. I added the smallest storage that makes the list real: the agent types in names and emails from the paper sheet. If you wanted automatic capture instead, that is a separate piece of work I did not start.

What changed

• The email:

- Generation: the new email_followup asset (src/generate.ts) is written while a listing has an open house: subject, thanks, price, facts line and signature, in classic, warm or bold. The property page link is the "See the home" button the page draws, as with the other emails. - Approval and versions: it is unapproved until a person approves it, and has the Fair Housing check and version history. Changing facts clears its approval; removing the open house removes it. The API and MCP are refused at approval (person_required).

• The email page:

- View: /listings/:id/email?which=followup shows the follow-up in the agent's brand. The existing blast page and its copy buttons work as before, with links between the two. - Visitor list: below the email is a "Would go to" list with add and remove, every value escaped (src/pages/email.ts). - Routes: the list is served by GET /listings/:id/email?which=followup, and changed with POST /listings/:id/visitors and POST /listings/:id/visitors/:visitor/delete, all same-origin only.

• Storage:

- New files: a visitor table and its migration (src/db.ts), a validator (src/visitors.ts), and listVisitors, addVisitor and removeVisitor in src/actions.ts. - Limits: a visitor needs a name of 1–80 characters and a valid email, the listing must have an open house, and a sheet holds at most 200.

• Existing tests: the sample listing (Alder Lane), the seller report and a few count assertions now include the new seventh asset. These were test expectations, not behaviour. Alder Lane's follow-up is approved by its sample agent like its other assets.
• Tests: src/followup.test.ts covers generation in each tone, approval, removal, a hostile visitor name, author-only access and the same-origin check. The README is updated.

Policy: contract.json is unchanged. Visitors are read and changed only through the listing's existing update cell (author or admin), never with the listing's public read. Nobody gains a permission.

Not done

• No MCP or terminal tool for visitors, since the list is personal data.
• No launch-week schedule row for the follow-up.

To try it: open Alder Lane's copy or any listing with an open house, then Email tab → "Preview follow-up".

🤖 Generated with Claude Code

Closes #64

A listing with an open house now gets a "Thanks for stopping by" email draft, and its email page lists the visitors it would go to. The full bun test run is green (297 pass). I did not run scripts/gate.ts or design-lint: neither exists in this repository (bun run lint:design ran clean). There is no tsconfig.json, so the type check did nothing. The app sends nothing.

Finding on #43: the sign-in sheet there is blank paper and stores nothing, so there were no visitors to list. I added the smallest storage that makes the list real: the agent types in names and emails from the paper sheet. If you wanted automatic capture instead, that is a separate piece of work I did not start.

What changed

• The email:

- Generation: the new email_followup asset (src/generate.ts) is written while a listing has an open house: subject, thanks, price, facts line and signature, in classic, warm or bold. The property page link is the "See the home" button the page draws, as with the other emails. - Approval and versions: it is unapproved until a person approves it, and has the Fair Housing check and version history. Changing facts clears its approval; removing the open house removes it. The API and MCP are refused at approval (person_required).

• The email page:

- View: /listings/:id/email?which=followup shows the follow-up in the agent's brand. The existing blast page and its copy buttons work as before, with links between the two. - Visitor list: below the email is a "Would go to" list with add and remove, every value escaped (src/pages/email.ts). - Routes: the list is served by GET /listings/:id/email?which=followup, and changed with POST /listings/:id/visitors and POST /listings/:id/visitors/:visitor/delete, all same-origin only.

• Storage:

- New files: a visitor table and its migration (src/db.ts), a validator (src/visitors.ts), and listVisitors, addVisitor and removeVisitor in src/actions.ts. - Limits: a visitor needs a name of 1–80 characters and a valid email, the listing must have an open house, and a sheet holds at most 200.

• Existing tests: the sample listing (Alder Lane), the seller report and a few count assertions now include the new seventh asset. These were test expectations, not behaviour. Alder Lane's follow-up is approved by its sample agent like its other assets.
• Tests: src/followup.test.ts covers generation in each tone, approval, removal, a hostile visitor name, author-only access and the same-origin check. The README is updated.

Policy: contract.json is unchanged. Visitors are read and changed only through the listing's existing update cell (author or admin), never with the listing's public read. Nobody gains a permission.

Not done

• No MCP or terminal tool for visitors, since the list is personal data.
• No launch-week schedule row for the follow-up.

To try it: open Alder Lane's copy or any listing with an open house, then Email tab → "Preview follow-up".

🤖 Generated with Claude Code

This push addresses all three of sentinel's changes, plus the import reorder.

Terminal door (src/tty.ts)

• P on an open listing previews the follow-up the way the client reads it. It carries the "DRAFT — not approved" line until the follow-up is approved. Below the message it lists "Would go to (n)" with each visitor. p still previews the blast email.
• V opens the visitor list. a adds one, typed as Name, email. d removes the one under the cursor. j/k move and esc goes back.
• Every read and write goes through listVisitors, addVisitor and removeVisitor, so the gate is the same as the page's. A guest or a non-author sees no list and can't open the add prompt.
• addVisitor and removeVisitor now emit listing.changed, so the terminal's writes reach web viewers live. This also fixes the page's own visitor writes, which didn't emit before.
• The keys are documented in the tty.ts header comment and in the README.

Visitors outlive the open house (src/actions.ts)

• updateFacts deletes the listing's visitor rows, inside its transaction, when open_houses becomes empty. A test in src/followup.test.ts covers it.

Weakened assertion (src/openhouse.test.ts)

• The exclusion is now by asset kind, not by text prefix. The follow-up is asserted on its own and must contain the property address. I still exclude it from the open-house-line check because it thanks people for a visit that already happened and never states the time. Say so if you want that line in it instead.

Tests

• A new tty test in src/tty.test.ts covers the follow-up preview, adding, rejecting a bad email, removing, the two listing.changed events, and a stranger and a guest seeing nothing. It also covers the visitors going when the open house is cleared.
• I ran the tty, follow-up, open-house, design, actions, hostile, deps, status and audit tests. All pass.

What I couldn't run

• bun scripts/gate.ts doesn't exist in this clone.
• bun x tsc --noEmit only printed tsc's help text, because the repo has no tsconfig.json, so there was no type check.

I didn't touch contract.json or loosen any permission cell.