Design: migration report as explore/share workspace (chat remains the writer)

## Summary

**The problem, in plain English:** the post-Estimate half of a migration run is iterative and multiplayer — a founder toggles assumptions (HA, region, commitment posture), compares scenarios, and convinces a co-founder or CFO — but the plugin serves that loop through chat, which is single-player and ephemeral. The what-if workshop's compare tables vanish when the window closes; scenarios live in JSON nobody opens; the person actually making the call is usually not in the chat at all. Recent work (#185/#186 decision pack, `scenario_deltas`, `calculator_url`) has been converging on the fix without naming it: **the report should become the explore/share workspace — while chat remains the only writer.**

This issue proposes a phased design, reviewed across three parties (two models + maintainer-side review rounds), with the disagreements already resolved and recorded below.

## Design principle (the resolved argument)

An earlier framing — "the report replaces chat as UI for the post-Estimate half" — was **rejected** on review, and the rejection is load-bearing:

| Surface | Job |
|---|---|
| **Report** | Explore + share: read the scenario lattice, compare, copy the CFO pack |
| **Chat** | Commit: apply a scenario, Decide/Execute, Generate |

The plugin's invariants (working-tree == active scenario, fail-closed gates, agent-as-only-writer, replace-never-patch) mean an HTML file must never mutate `preferences.json` or phase state — directly or via a bridge. Two writers on gate-sensitive state is the failure mode this repo has already paid to prevent. Commitment always round-trips through chat via a copyable command (`apply scenario B3`).

## Phased plan

### v1 — promote existing primitives (small PRs, no new writer, no honesty risk)
- "Share with your CFO" section: exec card + the per-scenario `calculator_url` links (already exist; AWS computes regional prices server-side) promoted from beneath the compare table to a first-class section.
- Scenario compare table rendered in the report (from `scenarios/index.json`, already specced) with an "apply scenario N" copy-back command per row. Only JS: a copy button.

### v2 — the real bet: interactive report over a precomputed lattice
- **Vendored, versioned HTML/JS template** + agent-injected JSON data island. The agent stops generating interactive markup; it fills a template. (More reliable than agent-generated HTML — but only if the template has an owner; see open questions.)
- **Knob lattice priced at Estimate time**, embedded in the island. Toggling HA/region/arch/commitment is a **lookup, not a computation** — no pricing engine in the browser.
- **Pricing mechanism — line-item recomposition, not full engine runs.** The full knob cross-product (~100+ points) cannot go through the inner Design/Estimate machinery (the workshop caps at 5 scenarios because each inner run is expensive). Lattice points are recomposed from the Balanced breakdown (Multi-AZ doubles the DB line; Optimized drops the NAT line; region swaps the rate table) — which is what the engine does internally, but it is a second, cheaper pricing path and must be labeled as such ("recomposed from the Balanced breakdown, same ±bands").
- **Anchor-check acceptance criterion:** recomposed lattice totals must match full engine runs at the (max 5) workshop anchor scenarios within tolerance. This is the v2 correctness gate.
- **Region honesty designed in:** the workshop invariants forbid presenting cache-based numbers as regional rates. Region toggles either use per-region rate-card points priced at generation time, or deep-link to the Pricing Calculator. Never a cache swap behind a slick toggle.
- **Staleness rule (interactive artifacts decay differently than documents):** a static report ages visibly; an interactive one invites reuse weeks later with July's prices served at live-tool confidence. The data island carries the pricing date; every toggled result renders it; the template computes staleness client-side and visibly downgrades itself past the cache-accuracy window ("prices from YYYY-MM-DD — re-run Estimate for current rates").
- **Checklist status:** the report may *view* status injected at render time; it never owns state (`localStorage` state in a replace-never-patch artifact dies on every re-render by design).
- Validator grows a data-island schema check; a golden fixture locks the island contract.

### v3 — bidirectional workspace (IDE-served bridge)
Deliberately deferred. Build only if v2 evidence shows users iterate in the report and resent the copy-back hop. This is a different product with a different writer model; do not build on faith.

## Evidence plan

The Feedback phase decision-check (recently added) already asks "could you make your migrate/stay decision from this assessment?" and collects actual-duration calibration. v1/v2 should extend it with one question: whether the user shared the report and with whom. The v2→v3 decision is empirical; the remaining design questions are not answerable by further review rounds.

## Sequencing constraints

- v1/v2 sit **after** the Decide pack (#185/#186); do not block or scope-creep those PRs on this vision.
- No changes to model selection, Bedrock mappings, or tier classification thresholds.
- Trace/Pulse contract untouched (consistent with the standing deferral).

## Open questions for maintainers

1. **Template ownership** (the actual gating risk for v2, not the technology): a vendored JS/HTML template is a real front-end asset in a markdown-spec repo. Who owns it, and does the vendored-canonical + `shared:sync` discipline extend to it?
2. Lattice cap policy: cap the cross-product (price only "nearby" variants + calculator links for the rest) vs. price everything via recomposition. Proposal: cap, with the anchor-check either way.
3. Does v1's copy-back command belong in the decision report too (#186's `decision-cta` section is adjacent), or only in the full report?

## Prior art in this repo

- Decision pack + shared exec renderer: #185, #186
- Scenario deltas / baseline-quality labels / not-comparable rule: #186, #175
- Per-scenario `calculator_url` + region-honesty rule: workshop invariants (canonical)
- Outcome vocabulary + trust panel: #173
- Feedback decision-check + duration calibration: #176 + #186

Review #185 and #186 alongside the existing scenarios/index.json, calculator_url, validator, and golden-fixture plans. Confirm the v1 scope and resolve template ownership, lattice-cap policy, and the decision-report copy-back question; done means maintainers have a decided, sequenced implementation plan.

Written by the indexing model from the issue text.