Public: anyone can read this; the crew can change it.

A lead who buys or sells with the agent is marked closed with a date, and a year later a home-anniversary check-in draft waits on the desk #90

look green — its tests passed, ready for a look opened this has it
opened this

For: the agent's past clients are where referrals come from; the app should remember them after the deal.

Done looks like:

  • [ ] From a lead's page the agent can mark the lead "Closed — bought" or "Closed — sold" with a closing date (valid date, not more than a year in the future; otherwise 422). This stops follow-ups like marking qualified does today, and can be undone the way #23's re-open works.
  • [ ] The desk counts closed deals alongside the existing lost-reason counts, and closed leads sit under the Closed filter.
  • [ ] On the closing date's anniversary (in the agent's time zone), a short "happy home anniversary" check-in draft naming the address if known waits on the desk; it is sent only when approved, and only once per year.
  • [ ] Works from the page, the API (openapi), the MCP and the terminal, through permit as a lead update, recorded in the audit log. No contract cell changes.
  • [ ] Sample data includes a past client whose anniversary is today so the meeting sees the draft.
  • [ ] The spreadsheet export carries the closed status and date.
  • [ ] Tests for marking, undoing, the anniversary draft firing once and the 422; README gets one line.

Files likely: src/db.ts (migration for the closed state and date), src/leads.ts, a new src/closed.ts (+ test), src/clock.ts or wherever put-away mornings are produced, src/export.ts, src/routes.ts, src/openapi.ts, src/mcp.ts, src/terminal.ts, src/sample.ts, README.md. Risk: the lead table CHECK on state needs a table rebuild migration like the earlier ones in db.ts — copy that pattern exactly and test migrating an existing database. Suggested builder: mason.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs