B-Phase Handoff Notes (Fable 5 → Opus 4.8, 2026-07-07)

Written after B1 execution + the same-day spec updates from Russell's two documents. Read this alongside phase-a-review.md (still fully in force) before planning B2.

Where things stand

• B1 is executed and final-reviewed (verdict: ready for B2), awaiting Leo's gate. Full record in B1-order-math.md — decisions, final-review findings, and the B4-deferred items live there. SDD ledger: .superpowers/sdd/progress.md.
• A1–A5 all verified (Lisa signed off on the rate card 2026-07-07).
• The spec changed on 2026-07-07, after B1 closed. Re-read it before writing the B2 plan — don't rely on a cached mental model. The deltas:
  • §3 "Order modification after signing" — six binding B2–B5 requirements distilled from the legacy email archive (Legacy Email Findings in Obsidian): first-class un-finalize, amend-in-place with past-is-immutable, makegood→original-order links, retire-from-date-X, ad-copy referential integrity, advertiser≠payer.
  • §6 production auth rewritten from Cloudflare Access Briefing (Obsidian): verify-the-JWT cf_access backend (supersedes trust-the-header), two-gate model, rundown public-prefix rules that bind C3's design.
  • §8: B5 scope grew accordingly; B6 gained the one-page-PDF criterion.

Guidance for the B2 plan (write it just-in-time, per protocol)

1. Order schema carries makegood_for_order_id (nullable) from day one — spec §3 item 3; cheap in the B2 migration, painful later. A per-line reference can wait for B5 if preferred, but the order-level link lands in B2.
2. Don't hard-lock finalized orders against adding lines — round-3 Q5 (upsell mid-term) is still open with Lisa. Status/locking design must leave both answers (amend-same-order vs. new-order) implementable.
3. B3 note, worth stating in B2's data design already: order line dates reference episode identity, not bare civil dates (spec §3 item 2) — a moved episode must carry its sold dates with it.
4. B1's types are the contract — ordermath.Line/Discount/Totals (basis points, tagged-union discount). B2 stores facts; totals are computed via ordermath.Compute (computed-over-stored).
5. B4 owns input validation for the pure core (bp range, non-negative amounts) — recorded in B1's final review; don't let it slip.

B5 scope warning

B5 was already the highest-risk stage (transactional finalize, oversell impossibility). It now also owns un-finalize, amend-in-place, finalize confirmation, and the delete-guard family (A4's TODO(B5) sites + ad-copy rule). Recommend splitting when its plan is written (e.g. B5a finalize/oversell core, B5b amend/void/guards) — and per phase-a-review.md, Fable reviews the B5 design before implementation either way.

Open questions in flight

• Round-3 Q5 (upsell) and the Q6 three-firms confirm are with Lisa/Debi (Follow-up Questions). Fold answers into the B2/B5 plans when they land.
• The W1 golden inputs in B1 are constructed from the rate card, not verbatim Lisa examples — confirming against a real signed order remains open (flagged at the B1 gate).

Operational notes (not recorded elsewhere)

• Publishing needs no vault: CLOUDFLARE_API_TOKEN is materialized in the login env — render with bun run scripts/publish-site.ts, then wrangler pages deploy ~/Projects/leo-temp-pages-site --project-name=leo-temp-pages --commit-dirty=true directly. The script's --deploy flag still hardcodes the Bitwarden wrapper (needs bw-unlock); an env-token fast-path edit was offered to Leo but not yet approved.
• The compose stack was left UP on the Framework testbed (app on :8730) after Lisa's rate-card verification.
• The two Russell source docs are Obsidian-only, deliberately unpublished (security topology / client incident details): Cloudflare Access Briefing.md, Legacy Email Findings.md.