Open house visitors say whether they already work with an agent, and the agent sees it on the visitor list and the CSV #142

Open house visitors can now say whether they work with an agent. The agent sees the answer on the visitor list and in the CSV. The tests I ran pass: tablet, followup, db, sample, walkthrough, tty and photo-alt. I did not run the full suite; the forge runs it on push. bun x tsc --noEmit only printed tsc's help text in this sandbox, so I have no type-check result. scripts/gate.ts and scripts/fast.ts don't exist in this repo, and I ran scripts/lint-design.ts (the repo's name for the design lint), which printed nothing.

What changed

• Tablet page: /listings/:id/open-house asks "Are you working with an agent? (optional)" with Yes / No radios. The server accepts yes, no or nothing. Any other value is refused with a 422 and "Working with an agent is Yes or No."
• Visitor list: the follow-up page's list shows "Has an agent" or "No agent" next to each visitor. It shows nothing for a visitor with no answer.
• CSV: visitors.csv has a new last column, "Working with an agent", reading Yes, No or blank. I appended it at the end so the existing columns keep their positions. The existing CSV tests had to change to expect the new header and column.
• Migration: a new final migration, ALTER TABLE visitor ADD COLUMN with_agent TEXT CHECK (with_agent IN ('yes','no')). The table is not rebuilt, and old visitors keep a NULL value that reads as blank. Re-running it is safe, because migrate skips the step when the column already exists.
• Sample listing: the sample listing 412 Alder Lane gets three visitors, one each with answers No, Yes and blank. They are planted once, including on databases where the sample already exists.
• Thank-you screen: unchanged, and a test checks that it still shows no earlier visitor.
• Styling: two small CSS rules for the radios, noted in docs/design/areas/open-house.md.

Tests

• A tablet test covers the field on the form, yes, no and blank answers, a refused bad value, the list, the CSV and the thank-you screen. It fails without the field on the form, the list or the CSV.
• A db test checks an old visitor survives the migration as NULL and that the column rejects other values.
• A sample test checks both answers are present.

Not done

• The terminal tool and the staff "add visitor" form on the follow-up page don't ask the question, so their visitors stay blank.
• contract.json is untouched, so no permission cell is loosened.

Closes #138

Open house visitors can now say whether they work with an agent. The agent sees the answer on the visitor list and in the CSV. The tests I ran pass: tablet, followup, db, sample, walkthrough, tty and photo-alt. I did not run the full suite; the forge runs it on push. bun x tsc --noEmit only printed tsc's help text in this sandbox, so I have no type-check result. scripts/gate.ts and scripts/fast.ts don't exist in this repo, and I ran scripts/lint-design.ts (the repo's name for the design lint), which printed nothing.

What changed

• Tablet page: /listings/:id/open-house asks "Are you working with an agent? (optional)" with Yes / No radios. The server accepts yes, no or nothing. Any other value is refused with a 422 and "Working with an agent is Yes or No."
• Visitor list: the follow-up page's list shows "Has an agent" or "No agent" next to each visitor. It shows nothing for a visitor with no answer.
• CSV: visitors.csv has a new last column, "Working with an agent", reading Yes, No or blank. I appended it at the end so the existing columns keep their positions. The existing CSV tests had to change to expect the new header and column.
• Migration: a new final migration, ALTER TABLE visitor ADD COLUMN with_agent TEXT CHECK (with_agent IN ('yes','no')). The table is not rebuilt, and old visitors keep a NULL value that reads as blank. Re-running it is safe, because migrate skips the step when the column already exists.
• Sample listing: the sample listing 412 Alder Lane gets three visitors, one each with answers No, Yes and blank. They are planted once, including on databases where the sample already exists.
• Thank-you screen: unchanged, and a test checks that it still shows no earlier visitor.
• Styling: two small CSS rules for the radios, noted in docs/design/areas/open-house.md.

Tests

• A tablet test covers the field on the form, yes, no and blank answers, a refused bad value, the list, the CSV and the thank-you screen. It fails without the field on the form, the list or the CSV.
• A db test checks an old visitor survives the migration as NULL and that the column rejects other values.
• A sample test checks both answers are present.

Not done

• The terminal tool and the staff "add visitor" form on the follow-up page don't ask the question, so their visitors stay blank.
• contract.json is untouched, so no permission cell is loosened.

The preview failure was my own new tablet test. I've fixed it and pushed 412aac3. I can't be sure that was the only failure, because the deploy log you sent showed a failing /week timing test instead.

The failing test posted five visitors as the same user pat that the rest of src/tablet.test.ts uses. That user hit the per-user rate limit and got a 429 where the test expected a 303. I moved the test to its own user, ava. No application code changed.

The full bun test passes locally: 474 pass, 0 fail. Before the fix it had exactly one failure here, my tablet test, and that matches the single failure in the deploy's final summary. The /week timing failure didn't reproduce:

• Isolated: src/speed.test.ts passes three times out of three, and /week takes about 12 ms per request.
• In the full suite: it passes in the same full run that once failed.
• Cause: /week doesn't read visitors, and my change adds only three rows to one sample listing. I take that failure to be CI load pushing it over the 50 ms p95 limit. I did not loosen the test.

If the forge's run still fails on /week, I'll look at that next.

Visitors at an open house now say whether they already work with an agent. The tablet asks, the answer shows on the visitor list, and it goes into the CSV. Anything other than a valid answer is refused.

The deploy failed on "the screen answers fast". That test launched its listing as the shared test agent tablet-pat. By then the other tablet tests had used up that agent's per-user rate limit, so the launch failed and the test failed with it. The fix gives the speed test its own agent, tablet-fay, and moves the other tablet tests from pat to tablet-pat. It is a test-only change and no app code changed.

src/tablet.test.ts passes locally: 7 tests, 0 failures. I did not run the full suite here, since the forge runs it on the push. bun x tsc --noEmit printed tsc's help text instead of type-checking, so the type check did not run. The changed file is a test.

I chose not to loosen any contract.json cell.

To try it, open /listings/<id>/open-house as the listing's agent and submit a visitor with an answer to "Are you working with an agent?". The visitor list and /listings/<id>/visitors.csv then show it.