Resuming the Frenday thread in /Users/james/3_nodejs/ai-new-business after a context compaction (2026-09-25, ~00:15 ICT). Read in this order before doing anything:

1. /Users/james/3_nodejs/ai-new-business/.tmp-frenday-builder-visual-handover.md  (primary; the Snapshot, "Builder, phase 1" and "Visual improvement" sections are enough to act)
2. /Users/james/3_nodejs/ai-new-business/apps/paiduay/docs/design/WYSIWYG-RESEARCH-2026-09-24.md  (the builder plan: recommended architecture and phase 1)
3. /Users/james/3_nodejs/ai-new-business/apps/paiduay/docs/design/CRITIC-AFTER-2026-09-24.md  (the NEXT ten visual/engineering items)
4. /Users/james/3_nodejs/ai-new-business/04_QUICK_STATUS_FOR_JAMES.md  (living status; keep it current and say so in chat; remind James of its §6)
5. SKIM ONLY (background, only if needed): apps/paiduay/docs/design/DESIGN-SYSTEM-2026-09-24.md; docs/foundation/02-kernel-spec.md §9.70 and §9.71; apps/paiduay/docs/EDITORIAL-RULES.md; apps/paiduay/components/card/templates.tsx and components/editor/look-ask.tsx (tonight's Pro layouts and picker, the builder's base).

After reading, James's order (2026-09-25 00:00, verbatim intent): implement the builder (phase 1 of the WYSIWYG research: a constrained Pro "Look" editor on top of the new card layouts) and improve the visual design, in parallel. He approved ALL the research doc's recommended defaults (tap + up/down reorder, curated palette, no custom fonts, free users may preview Pro looks, and the rest) and allows you to make low-risk decisions yourself without asking. His design feedback: he rejected mockups A and B ("neither"); both read as "amateur", about 30% of what he would consider deployable; that is his level of expectation, meant to raise the bar, not to discourage. So visual work must reach a professionally art-directed bar before he sees it: set a named reference bar, work on the live pages (not static mockups), run an adversarial critic against the bar, and iterate before presenting.

First decide whether you need to ask James anything. If yes, send ALL questions in ONE batch and wait. If not, proceed right away: dispatch Opus 5.5 sub-agents (model "opus"; the Fable weekly pool is nearly empty) with disjoint file ownership, at most 10 at once, integrate, typecheck, run the paiduay tests, commit, deploy with deploy/push-and-deploy.sh (NOTIFY=1), verify live, update spec §9, the tracker, 03_ENTRYPOINT.html and the status file, and ping James on Slack at milestones (webhook in memory). If the dev server is needed, restart it with the command in the bridge's STALE ON RESUME section first.

Guardrails: no fabricated content; Thai-first, English equal, never mixed on a line; singular they, Customer/Companion, hours 06:00 to midnight, American English, Kathy, hello@frenday.xyz, no "daytime", no em dashes in new copy (apps/paiduay/docs/EDITORIAL-RULES.md); never edit apps/paiduay/content/story.ts (James's words) and mark any new public wording as DRAFT for him; a booking is a request the Companion confirms; real photos only for real sellers, generated pictures only for the fictional demo people and labeled; never run the root pnpm test; no live Anthropic API tests beyond a few messages without agreeing the count with James (about $2.50 credit left); prod DB queries need set_config('app.tenant_id', ...) first; never touch the Luna/TuaTon compose projects; never commit .env, next-env.d.ts, page.html or z.txt; the git remote is vps only; all CLAUDE.md rules stand.
