See the launch week on one page: which approved post and email goes out on which day, and add it to your calendar #69

Each listing now has a launch-week page at GET /listings/:id/schedule and a calendar file at GET /listings/:id/schedule.ics. The full bun test suite passes (246 tests). I could not run bun scripts/design-lint.ts, scripts/gate.ts or scripts/fast.ts because they don't exist in this clone. bun x tsc --noEmit only printed tsc's help text because the repo has no tsconfig, so nothing was type-checked.

• Plan: src/schedule.ts builds the day-by-day rows from the listing's status, open houses and assets. It is pure and writes nothing.

- Launch day: MLS description, the three social posts and the email blast. - Coming soon: the teaser post and email, listed before the launch-day rows. - Other statuses: the status post and email. - Price drop: the price improvement post and email. - Open houses: a reminder post the day before and the open house itself, with its times.

• Rows: each row names the asset, links to it on the listing page, and says "Approved by … on …" or "Draft — not approved yet, so it does not go out". The page also says nothing is sent from here.
• Calendar file: /listings/:id/schedule.ics is hand-built text/calendar with CRLF lines, escaped text and lines folded at 75 bytes. It has one event per row, and a draft's title starts with "DRAFT:".

- Dates: open houses are floating local times and every other event lasts all day. Nothing is converted between time zones. - Escaping: a test with a hostile address containing ;, ,, \ and a newline shows it can't add an event.

• Reachability: the listing page has a "Launch week" button, and the schedule page has an "Add to calendar" link. Both pages print cleanly via the existing print styles. The README has a new step 14 describing it.
• Other changes: a few CSS classes in static/app.css, documented in docs/design/areas/schedule.md. The OpenAPI file is regenerated.
• Tests: src/schedule.test.ts covers the 412 Alder Lane rows, draft versus approved, the coming-soon teaser order, open-house reminders, the .ics shape and escaping, and 404s. I also added the schedule page to the a11y and hostile-input page lists.
• Permissions: reads go through getListing, so permit decides as it does for the report, and I changed no contract.json cell.

The listing has no stored launch date, so "launch day" is the date the listing was created. A coming-soon listing's teaser and its launch-day rows therefore share that same day.

The reminder post uses the Short post asset, and the open house row links to the Flyer copy.

I left out a separate go-live date field, the sign-in sheet as a schedule row, and any sending.

To try it, open a listing and press Launch week, then Add to calendar.

🤖 Generated with Claude Code

Closes #63

Each listing now has a launch-week page at GET /listings/:id/schedule and a calendar file at GET /listings/:id/schedule.ics. The full bun test suite passes (246 tests). I could not run bun scripts/design-lint.ts, scripts/gate.ts or scripts/fast.ts because they don't exist in this clone. bun x tsc --noEmit only printed tsc's help text because the repo has no tsconfig, so nothing was type-checked.

• Plan: src/schedule.ts builds the day-by-day rows from the listing's status, open houses and assets. It is pure and writes nothing.

- Launch day: MLS description, the three social posts and the email blast. - Coming soon: the teaser post and email, listed before the launch-day rows. - Other statuses: the status post and email. - Price drop: the price improvement post and email. - Open houses: a reminder post the day before and the open house itself, with its times.

• Rows: each row names the asset, links to it on the listing page, and says "Approved by … on …" or "Draft — not approved yet, so it does not go out". The page also says nothing is sent from here.
• Calendar file: /listings/:id/schedule.ics is hand-built text/calendar with CRLF lines, escaped text and lines folded at 75 bytes. It has one event per row, and a draft's title starts with "DRAFT:".

- Dates: open houses are floating local times and every other event lasts all day. Nothing is converted between time zones. - Escaping: a test with a hostile address containing ;, ,, \ and a newline shows it can't add an event.

• Reachability: the listing page has a "Launch week" button, and the schedule page has an "Add to calendar" link. Both pages print cleanly via the existing print styles. The README has a new step 14 describing it.
• Other changes: a few CSS classes in static/app.css, documented in docs/design/areas/schedule.md. The OpenAPI file is regenerated.
• Tests: src/schedule.test.ts covers the 412 Alder Lane rows, draft versus approved, the coming-soon teaser order, open-house reminders, the .ics shape and escaping, and 404s. I also added the schedule page to the a11y and hostile-input page lists.
• Permissions: reads go through getListing, so permit decides as it does for the report, and I changed no contract.json cell.

The listing has no stored launch date, so "launch day" is the date the listing was created. A coming-soon listing's teaser and its launch-day rows therefore share that same day.

The reminder post uses the Short post asset, and the open house row links to the Flyer copy.

I left out a separate go-live date field, the sign-in sheet as a schedule row, and any sending.

To try it, open a listing and press Launch week, then Add to calendar.

🤖 Generated with Claude Code

All five review points are addressed and pushed to the same branch. The full bun test suite passes (251 tests).

1. Terminal: w on an open listing shows the launch week as text.

- Each row reads all day · What · Asset · Approved by … on … (an open house shows its start–end times instead of "all day"), or "Draft — not approved yet, so it does not go out". Esc goes back, and the help line names w. - It is gated like the R seller report: it appears only once the listing has been read. - New tests in src/tty.test.ts cover a draft, an approved asset, and the help line.

1. Tests:

- I removed the stray /schedule-not-here call. - A new test snapshots the listing, asset, audit and event tables, reads /schedule and /schedule.ics, and asserts nothing changed. It also still checks the 404s. - Another test approves the MLS description on a test-made listing through the page. That row then shows "Approved by pat", the other rows stay Draft, and the .ics marks exactly those as DRAFT:.

1. Contract and speed: src/contract.test.ts doesn't list per-route rows for the report, the kit or any other listing page, so I added nothing there. src/speed.test.ts now includes /listings/1/schedule and /listings/1/schedule.ics, and both pass under the 50 ms bar.
2. README: I added the paragraph on the launch week to the agent section, in the same place as the launch kit, and step 14 now mentions w in the terminal.
3. Checks:

- Design lint: bun scripts/lint-design.ts is clean. The script is named lint-design.ts, not design-lint.ts as the instructions had it. - Not run: there is no scripts/gate.ts or scripts/fast.ts in this clone. bun x tsc --noEmit only prints tsc's help text because the repo has no tsconfig, so nothing was type-checked. - OpenAPI: I regenerated contract/openapi.json.

No contract.json cell changed.

🤖 Generated with Claude Code

I merged main into the branch and pushed; the full bun test suite passes (260 tests) and bun scripts/lint-design.ts is clean.

• src/hostile.test.ts: both sides edited the same list of pages. I kept main's /listings/:id/card and my /listings/:id/schedule.
• static/app.css: both sides added a block at the end of the file. I kept both, and put back the closing braces of my @media print block, which the conflict had split. One stylesheet test failed on those braces until I did.
• contract/openapi.json: I regenerated it after the merge.

🤖 Generated with Claude Code