Each person can have a preferred way to be reached, and the drafts and People page show it #294

A party can now have a preferred way to be reached (text, email or phone call, default none), and People and the review page show it. I ran the full test suite (bun test) and bun scripts/lint-design.ts; both pass. One run had a timing test (speed.test.ts) over its 50 ms budget under load; it passes when run alone.

I could not run bun x tsc --noEmit: the repository has no tsconfig.json. There is also no scripts/gate.ts or scripts/fast.ts here.

What changed

• Storage and rules: a new migration adds party.reach (blank, text, email or call, enforced by a CHECK), and the pin file now has its hash. In src/deals.ts, partyText, addParty and editParty take reach and refuse any other value with 422. On an edit, leaving it out keeps the current value and sending it blank clears it. The permit and same-origin paths are the existing party ones.
• Where it can be set: the add-party and edit forms on the deal page have a "Reaches best by" select. POST /deals/:id/parties, PATCH /api/deals/:id/parties/:party and the MCP add_party and edit_party tools accept it, and contract/openapi.json is regenerated.
• Where it shows: People shows "Reaches best by text" under the name. The review page adds the same phrase to each draft's "To …" line. The drafted subject and body are unchanged, and a test checks that.
• Export and import: parties carry reach in the export. An older file without it imports with none, and an unknown value is rejected.
• Sample deals: the sample parties carry text, email, phone call and no preference.
• Docs: README.md has a short "How people like to be reached" section, and docs/TECHNICAL.md has the technical details.
• Tests: new tests are in src/reach.test.ts. I also updated the field list in src/export.test.ts, and src/migrations.test.ts needed its old-database filter extended to cover the new migration.

What I chose not to do

• No contract.json cell changes.
• I did not add the preference to the README's People tour step, because a test requires that step to match src/tour.ts. It has its own README section instead.
• I did not touch the clock or the People nudge line, to stay clear of #233 and #234.
• I did not show the preference on the deal page's party list or its per-date drafts, or prefill it from the "use" link for people known from other deals. The issue only asked for People and the review page.

To try it: on a deal page, add or edit a party and choose how they like to be reached. Then open People and /reminders/today to see the line. In the sample data, Priya Nair shows "email" and Maya & Tom Okafor show "text".

🤖 Generated with Claude Code

Closes #287

A party can now have a preferred way to be reached (text, email or phone call, default none), and People and the review page show it. I ran the full test suite (bun test) and bun scripts/lint-design.ts; both pass. One run had a timing test (speed.test.ts) over its 50 ms budget under load; it passes when run alone.

I could not run bun x tsc --noEmit: the repository has no tsconfig.json. There is also no scripts/gate.ts or scripts/fast.ts here.

What changed

• Storage and rules: a new migration adds party.reach (blank, text, email or call, enforced by a CHECK), and the pin file now has its hash. In src/deals.ts, partyText, addParty and editParty take reach and refuse any other value with 422. On an edit, leaving it out keeps the current value and sending it blank clears it. The permit and same-origin paths are the existing party ones.
• Where it can be set: the add-party and edit forms on the deal page have a "Reaches best by" select. POST /deals/:id/parties, PATCH /api/deals/:id/parties/:party and the MCP add_party and edit_party tools accept it, and contract/openapi.json is regenerated.
• Where it shows: People shows "Reaches best by text" under the name. The review page adds the same phrase to each draft's "To …" line. The drafted subject and body are unchanged, and a test checks that.
• Export and import: parties carry reach in the export. An older file without it imports with none, and an unknown value is rejected.
• Sample deals: the sample parties carry text, email, phone call and no preference.
• Docs: README.md has a short "How people like to be reached" section, and docs/TECHNICAL.md has the technical details.
• Tests: new tests are in src/reach.test.ts. I also updated the field list in src/export.test.ts, and src/migrations.test.ts needed its old-database filter extended to cover the new migration.

What I chose not to do

• No contract.json cell changes.
• I did not add the preference to the README's People tour step, because a test requires that step to match src/tour.ts. It has its own README section instead.
• I did not touch the clock or the People nudge line, to stay clear of #233 and #234.
• I did not show the preference on the deal page's party list or its per-date drafts, or prefill it from the "use" link for people known from other deals. The issue only asked for People and the review page.

To try it: on a deal page, add or edit a party and choose how they like to be reached. Then open People and /reminders/today to see the line. In the sample data, Priya Nair shows "email" and Maya & Tom Okafor show "text".

🤖 Generated with Claude Code

I've addressed all three review points and pushed to the same branch. The full bun test passes (763 tests) and bun scripts/lint-design.ts exits 0 at the new head. tsc still can't run here because the repository has no tsconfig.json.

What changed since the first push

• Terminal door (point 1):

- p (add a party) and e (edit one) now ask "Reaches best by (text, email, call…)" and pass reach to addParty and editParty. - On an edit the prompt shows the current value, and a blank answer clears it. This matches the page's "No preference" option. - An unknown value is refused by the action, and the message appears on screen. - The preference shows beside the name on the P People view and on the deal view's party list. - It also shows on each row of the reminders list, next to the party name. That is where the terminal shows the draft; the "To" line there holds no contact details. - The file's header comment, the README and docs/TECHNICAL.md are updated. - Two existing terminal tests needed one extra Enter for the new step.

• Route and tool tests (point 2): the new src/reach.routes.test.ts runs against a real server. It covers:

- Setting it through the add-party form (POST /deals/:id/parties), and the deal page then showing the select pre-selected. - A 422 for an unknown value, with the typed name kept and nothing written. - A cross-origin post getting 403 and a signed-out post being turned away (303, 401 or 403); both write nothing. - The edit form (POST /parties/:id/edit) changing, clearing and refusing the value, and opening with the current choice selected. - PATCH /api/deals/:id/parties/:party setting it, keeping it when left out, clearing it when blank, and answering 422 for an unknown value. - The MCP add_party and edit_party tools taking it and refusing unknown values.

• Terminal tests: src/terminal.test.ts has a new test for set, reject-unknown, clear-on-blank and display on both the People view and the party list.
• Merged people (point 3): src/people.ts now keeps the newest non-blank preference when parties merge into one person, so a blank on a newer deal no longer wipes it. A test in src/people.test.ts covers this in both orders.

Where I differ from the review: the terminal shows the preference on the reminders list row, not on a "To" line, because that view has no such line.