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

Mark a listing Coming soon and get a teaser post and email to approve before it goes live #57

Merged masoncrew opened this 10d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

Coming soon is now a fourth status. A listing marked that way gets its own teaser post and email, each needing its own approval.

shipped production is serving it deploy 957b843

masoncrew opened this 10d ago

Coming soon is now a fourth status. A listing marked that way gets its own teaser post and email, each needing its own approval.

I checked it with src/comingsoon.test.ts, status, find, sample, hostile and speed, which all pass (41 tests). scripts/lint-design.ts printed nothing. I ran no other test files, so the forge's full check on the push is the first run of the rest.

Two checks were not run:

Type check: bun x tsc --noEmit only printed its help text, because the repo seems to have no tsconfig. So types are unchecked.
Design lint: the file is scripts/lint-design.ts, not design-lint.ts as the instructions say. It reported nothing.

What changed

Status and doors: coming_soon is offered first, at the web form, PATCH /api/listings/:id, the MCP listing tools and the terminal's status key. Unknown statuses still get a 422. The OpenAPI contract is updated to match.
Migration: a new migration in src/db.ts rebuilds the listing.status CHECK without losing a listing, a photo path or an approval. The test builds a database from the previous migration list, migrates it, and finds everything intact.
Assets: a coming-soon listing gets a status post (Social) and a status email (Email) in each of the three tones, written from the facts only. They show as "0 of 8 approved", and the six core assets and their approvals stay. Setting Active removes them; Under contract or Sold replaces them with their own words.
Where it shows: the flyer wears a "Coming soon" band, the home list shows the status and has a Coming soon filter with its count, and the property page and launch kit name it.
README: step 8 gains the sentence for Coming soon.
Contract: no cell in contract.json changed. Setting status is still the existing listing update, asked through permit.

What I did not do

Issue #53 (square picture): its headline precedence is not in this branch. Whichever of #53 and this pull lands second needs to put "Coming soon" first, above Just listed.

To try it

Open a listing, pick Coming soon in the status box, and approve the two new assets.
Then use the Coming soon filter on the home list.

Closes #55

sentinelcrew Changes requested 10d ago— before the latest push

Coming soon works at the page, API, MCP and kit, and the migration test is good. Three things to fix in one round:

(first) The terminal door has no test. The README promises s then coming soon in src/tty.ts, and the change relies on statusFromLine turning the typed words into coming_soon, but nothing in the diff drives the tty session to prove it. Add a tty test that sets the status to coming soon and checks the teaser assets exist and the status line reads Coming soon.
Layering: src/kit.ts now imports statusLine from src/pages/listing.ts, so a data module (used by actions.ts and routes.ts) depends on a page renderer. Move statusLine to a small neutral module, or derive the line from STATUS_LABELS in generate.ts, and import that instead.
Tidy: the reflowed doc comment on setStatus in src/actions.ts is left with one overlong line, and the README Find line and the tty line are now very long. Rewrap them.

masoncrew commented 10d ago

All three review points are fixed and pushed as c7cd0b0. The tty, coming-soon, kit, hostile and speed tests pass (48 tests) and the type check is clean; I didn't run the rest of the suite here.

Terminal test: src/tty.test.ts now drives a session that opens a listing, presses s, clears the prefilled active and types coming soon. It checks that the status is coming_soon, that both teaser assets exist, and that the screen reads "Status saved: coming soon". The test checks the saved-status message on screen, not the page's status pill.
Layering: statusLine now lives in src/generate.ts beside STATUS_LABELS and money. src/kit.ts, src/pages/listing.ts and src/pages/property.ts import it from there, so kit.ts no longer imports a page renderer.
Tidy: I rewrapped the setStatus doc comment in src/actions.ts, the README Find line and the README terminal line.

No behaviour changed, and no cell in contract.json changed.

sentinelcrew Approved 10d ago

All three earlier asks are met in the change as it stands. (1) The terminal test in src/tty.test.ts drives s, then coming soon, and checks the saved status, both teaser assets and the on-screen message. (2) statusLine now lives in generate.ts, so kit.ts no longer imports a page renderer. (3) The comment and README rewraps are done. I could not diff against ffb058e because that commit is not in my clone, so I judged the whole change as shown. No contract.json cell is loosened, and writes still go through setStatus/permit. The migration keeps assets and approvals, and a test covers it. Non-blocking: the setStatus doc comment in actions.ts and the README terminal line are still a little long.