#Copilot — Milestone 1b: live granularity, card lifetime and the adaptive call plan for CurrencyTransfer replays

#1. Overview

• Problem statement. Stevan reviewed a replay of call 3339895706 on 2026-09-27 (docs/design/FEEDBACK-2026-09-27.md). His session 1d160d96 matches run 49e3e48f decision for decision, on policy v4. The review found four problems:

  1. Nothing feels live. The transcript and Jev both run once per stitched turn: LiveTranscript.update draws a line at its t_end, and UtteranceDriver.tick sends utterance{i} at that moment. This call's turns run to 44.5 s and 112 words. The word-weighted wait from spoken to visible is 9.1 s, and the longest gap between decision points is 45.6 s. Jev itself answers in 304 ms at p50.
  2. The plan reads as a score sheet. It has 10 rows, 6 of them never ticked, and a live tally of 2 of 7.
     • Facts the copilot should simply know nag as steps ("Check we can serve them").
     • The purpose was never captured: "I get paid on the fifteenth" misses the trigger.
     • One tax-residency worry became two jurisdiction rows. A 3-word fragment closed it, and a re-raise 1.7 s later inserted a second row.
     • A complaint about the client's own bank at 02:22 opened "Client thinks our rate is too high".
  3. Suggestions are rare and vanish unread. Only 12 of 96 decisions showed an open point, on 3 distinct cards. The amount point was tinted for 1.0 s, and the first-transfer-date point was withdrawn uncovered after 23 s.
  4. The player jumps. "catching up (N queued)" moves the scrubber.

  The engineering analysis is docs/architecture/proposal-m1b-live-plan.md: measures in §2, rules in §3-§6, the story sketch in §7, risks in §8, disagreements in §9 and review changes in §10. Stevan's rulings are in policy/approvals/2026-09-27-m1b-decisions.json.

• Proposed solution. Four strands inside design G's one-card live view, plus verification:

  • (a) Live granularity in replay.
    • Words appear as they are spoken, in the browser only.
    • STITCH_V2 cuts long turns into sentence-sized parts (decision 1a).
    • Feedback moves at sentence ends; the card switches only at the end of the client's run (decision 1b).
    • The thresholds counted in decisions are re-tuned for the new cadence.
    • The per-call cost gate becomes $0.06 (decision 16).
  • (b) Card lifetime.
    • In the presenter: a 12 s floor, stacking up to 3, a sticky last suggestion and a rep-turn grace.
    • In the engine: hysteresis in the [0.3, 0.6) band, and pre-judged fits for the item about to open (decisions 3 and 17).
  • (c) The plan as a guide.
    • Every item gets a kind: fact, must-say or judgement.
    • Pre-call facts are seeded at evidence i=-1 from a closed-vocabulary precall_json (decision 2a).
    • The live list becomes known chips, Now, Coming up and Covered, with no counts (decision 2b).
    • A coaching review is shown to the rep (decision 2g).
    • The must-say rules follow decisions 2c, 2d and 2e.
    • Stevan's approved wording is applied (decision 2f).
    • The purpose trigger gains new words, and a salary-home prior ranks situations (decision 2h).
  • (d) The duplicate tick and the rate false positive.
    • A concern clears only on a client line of 4 or more words, and a re-raise within 60 s reopens the same row.
    • The objection criteria stop typing a complaint about the client's own bank as a CurrencyTransfer rate concern.

  This needs no new Cloudflare service and one D1 migration (0004_precall.sql).

• Target users. Stevan (founder; the only Access identity) reviewing replays now. CurrencyTransfer reps later, each reading their own review (decision 2g).

• Success metrics (M1b exit). scripts/m1b-acceptance-check.mjs (COPILOT-118b) asserts these, and COPILOT-118 runs it on the deployed Worker. The baseline is the 2026-09-27 run 49e3e48f and eval/reports/final-20260927*.json.

  • Cadence on 3339895706 (on estimated word times):
    • Decision points go from 96 to 125-145.
    • The longest gap between decision points is ≤ 15 s (was 45.6 s), and the p90 gap is ≤ 11 s (was 16.0 s).
    • Transcript text never appears before its estimated spoken time.
    • Sentence-end-to-first-feedback p50 and p95 at 1x are reported, measured on wall-clock pacing.
  • Suggestions on 3339895706:
    • More than 12 decisions show an uncovered point on the current item (today 12).
    • More than 3 distinct items ever show a point (today 3); 20 and 5 are expected.
    • No revealed point leaves before 12 s, except for the exemptions defined in COPILOT-107.
    • At most 3 points show at once. The amount point never renders tinted.
  • Plan on 3339895706:
    • At the last decision the live list has ≤ 4 open rows (10 today), no tally and no "Not needed" group.
    • At most one jurisdiction row (two today).
    • No rate or fees concern opens before 04:00.
    • With the demo seed, "What they're sending, and why" and "Where they live and bank" are satisfied at i=0.
    • The review reads "Must-says: 2 of 3 that applied".
  • Gates on every promoted policy candidate:
    • L1 ≥ 90 % per scenario (baseline v4: onboarding 91/91, cs 79/81).
    • L4 and L6 pass. Every input_tokens is ≤ 12,000 (decision 15), and cost per call is ≤ L6_LIMITS.cost_per_call_usd = 0.06 (decision 16).
    • e2e p95 at 1x is ≤ 3 s.
  • Curation survives the re-import:
    • 3 marks on 3339895706 and 1 label on 3303259297, before and after.
    • 3485591407 keeps pd_ct_id 109829.

#2. Requirements

#Functional Requirements

Core

• FR-1 Screenshot tooling for the deployed dashboard (COPILOT-102a). Transcript words are revealed between each line's start and end (COPILOT-102).
• FR-2 Re-stitching and curation:
  • STITCH_V2 parts (103);
  • the curation export (104a);
  • the i remap (104f);
  • the re-import CLI with an atomic curation precondition (104b);
  • the validated curation-restore route (104c);
  • Worker ingest on v2 (104d);
  • the guarded re-import of the four samples, with the curation restored (104e).
• FR-3 A presenter simulator (105a). The presenter's change moment becomes the end of the client's run, with new points at sentence ends; LIVE_CARD_AT_SENTENCE_END = false (105).
• FR-4 Decision-counted thresholds are re-tuned, the window becomes 16, the cost gate becomes $0.06, and a policy candidate carries stitch_version 2 (106).
• FR-5 Card lifetime:
  • a design board for the live-view changes (121);
  • presenter point lifetime R1-R4 (107);
  • engine hysteresis R5 (108a) and pre-judged fits R6 (108b);
  • the player's reserved status slot (120).
• FR-6 The plan as a guide:
  • Grammar and policy data: plan grammar, text identity and registry (110a); compatible engine readers and contract types (110f); generator and eval tooling (110g); the opt-in derived checklist (110h); the approved wording (110c); typed templates (110d); the bank_country slot with the served list (110b); an L1 fact-value check (110e).
  • Engine: fact and judgement semantics (111a); must-say applies/due (111b); amount corrections against second legs (111c).
  • Pre-call facts: schema and validation (112); write paths (112b); pure seeding and conflict provenance (113); the session propagation (113c); the served-list jurisdiction gate (113b).
  • Views: the guide pane (114); chips with their source (114b); the review model (115) and its view (115b).
  • Capture: purpose trigger words and the prior (116).
• FR-7 The concern clearing guard and reopen (117). The objection criteria exclude complaints about the client's own provider (119).
• FR-8 Verification: wall-clock replay pacing and arrival logs (118a); measurement and acceptance tooling (118b); final verification, register and runbook (118).

Secondary

• FR-9 The views render every new label only from an approved text in the pinned bundle; an older bundle keeps today's words (INV-COPILOT-015).
• FR-10 The served-country list ships empty. The jurisdiction gate and the "outside the served list" surfacing do nothing until a list is supplied (§7 Q3).

Out of scope

• COPILOT-109: decision 3 is option A. Its id stays reserved.
• Live audio, nova-3 streaming, the Aircall transport spike and the paid Workers plan (M3, decision 14). True partial decisions.
• The real sign-up join through pd_ct_id (M2; M1b fixes the shape it must produce). Multi-leg amount and pair slots. A tax-residency concern type (M2). A Saudi overlay template (decision 2h).
• The following, each excluded by the decision named:
  • raising the 12,000 cap (decision 15);
  • live-list variants B and C (decision 2b);
  • a team leaderboard (decision 2g);
  • a per-leg minimum and any batching line (decision 2e).
• Also out of scope:
  • a dismiss or defer control on suggestions;
  • a joint value for the funding-account list (§7 Q5);
  • nova-3 word times for uploads (§7 Q4).

#Non-Functional Requirements

• Performance.
  • e2e p95 (utterance sent to decision received) ≤ 3 s at 1x, the M1 gate; the 1.5 s target is reported.
  • Provider p95 ≤ 1.5 s. At most 2 subrequests per decision (COPILOT-058b).
  • A 125-165-decision replay at 20x completes through reconnect{after_i} with 0 errors.
  • The word reveal rewrites only the rows still being spoken.
• Cost and tokens.
  • Cost per replayed strong call ≤ L6_LIMITS.cost_per_call_usd (0.06 from 106). Stories read the constant, never a literal.
  • Every request ≤ 12,000 input tokens; p95 ≤ 11,000 is reported. prejudge is the first drop under budget.
  • Caps are measured on session requests only, never on a whole-bank probe; M1's COPILOT-023 failed on exactly that.
• Security and privacy.
  • Access fronts every route.
  • PUT /api/calls/:id/precall and POST /api/calls/:id/curation accept the service token only, validate every row (including the ownership of deterministic ids), and write audit_log.
  • A forced transcript replacement is refused atomically when the call's curation changed since its export.
  • precall_json holds only closed-list ids, ISO codes, digits and a source, on every write path (INV-COPILOT-004, INV-COPILOT-020).
  • Exports and fixtures are pseudonymised envelopes. docs/runbook/ is never published. node scripts/check-secrets.mjs exits 0.
• Scalability. D1 batch limits are unchanged (INV-COPILOT-008). The same step() serves 96 or 165 decision points. The served list and the precall shape are policy data, ready for the M2 join.
• Accessibility.
  • Both themes on every UI change. Colour is never the only signal: a rep-turn point arrives grey with its tick.
  • The "Covered" line is a keyboard-operable button with aria-expanded.
  • prefers-reduced-motion collapses the point fades. The word reveal follows the clock and is not an animation.
  • The status slot never moves the scrubber.

#Decisions (Stevan, 2026-09-27; policy/approvals/2026-09-27-m1b-decisions.json)

#3. Technical Architecture

flowchart LR
  subgraph devbox["devbox / otto worktree (no data/)"]
    SMP[("tests/fixtures/samples/*.json<br/>pseudonymised fragments")]
    ST2["stitch() STITCH_V2<br/>src/ingest/stitch.ts"]
    EXP["export-call-curation.mjs<br/>remap-i.mjs"]
    IMP["import-fixture.mjs --stitch 2"]
    PRE["precall-payload.mjs"]
    POL["policy/src → build-policy --next-version<br/>→ publish-policy (draft) → eval gate → publish"]
    EVAL["eval.mjs l1,l4,l6 · replay-ws · ws-probe<br/>presenter-sim · m1b-acceptance-check"]
    SMP --> ST2 --> IMP
  end
  subgraph CF["Cloudflare (Access on every hostname)"]
    W["Worker jev-copilot<br/>+ PUT /api/calls/:id/precall<br/>+ POST /api/calls/:id/curation"]
    D1[("D1 copilot<br/>+ 0004_precall.sql")]
    DO[("DO CallSession<br/>initialState(pin, seed) · step()")]
    AI[["typesafe/jev via AI Gateway jev-copilot"]]
  end
  subgraph WEB["Browser (owns the clock)"]
    TR["transcript.ts: word reveal"]
    PR["presenter.ts: run end, R1-R4"]
    PV["plan.ts / chips.ts: guide<br/>review-plan.ts: coaching"]
  end
  IMP -->|"POST /api/calls/import (force)"| W
  EXP -->|"D1 reads · POST curation"| W
  PRE -->|"PUT precall (service token)"| W
  POL -->|"POST /api/policy · eval-runs · publish"| W
  EVAL --> W
  W --> D1
  DO --> D1
  DO -->|"≤ 2 subrequests per decision"| AI
  TR --- PR --- PV
  WEB <-->|"WS decision{plan: items, facts[source], known, must_says, dropped_hard}"| DO

Key components. Line numbers are at 51dbb7e (code unchanged since a83e53e). The symbol is the anchor: executors re-locate by symbol if a line moves.

Data flow for one replayed part. Under v2, a 44.5 s client turn arrives as 4-6 kind:'turn' parts, each with its own t and t_end, so the protocol, the DO and the decision table are unchanged.

1. The browser clock passes a part's u.t: its row appears and grows word by word.
2. At the part's t_end, the browser sends utterance{i}.
3. The DO builds the state: seeded facts at i=-1, a 16-unit window, and the pre-judge questions on client parts.
4. The DO answers from the cache or from Jev and runs step(): kinds, known facts, must-say applies/due, hysteresis, and the concern guard and reopen.
5. It commits in ≤ 2 subrequests and sends decision.
6. The presenter applies ticks, chips, the caution and any new point on the open card as the decision arrives. It applies a card switch at the client's run end, after the 20 s dwell, and never during a rep turn.
7. R1-R4 hold what is already on screen.

Integration points.

• Jev: unchanged. The DO calls env.AI.run('typesafe/jev', …, {gateway:{id:'jev-copilot'}}).
• D1: migration 0004_precall.sql, applied remotely by 112b.
• Policy gate: POST /api/eval-runs, then POST /api/policy/:scenario/publish (architecture §9).
• Deploys and live commands: node scripts/deploy.mjs for deploys; live commands run through node scripts/with-cf-env.mjs, using the jev-scripts Access service token.

Conventions. The M1 conventions in prd.md §3 still apply: test commands, with-cf-env for live commands, pseudonymised fixture envelopes, replacement semantics, and null for unknown. M1b adds:

1. Deploy and probe. node scripts/deploy.mjs refuses a dirty tree or a branch behind main, and deploys with --var GIT_SHA:<HEAD>. Every live script asserts GET /api/health version == git rev-parse HEAD first: replay-ws.mjs, ws-probe.mjs, eval.mjs, probe-player.mjs, presenter-sim.mjs, m1b-acceptance-check.mjs, and shoot-dashboard.mjs --deployed.

   • Commit sequence, per story:

     1. Commit the code. That commit is the deployed revision.
     2. node scripts/deploy.mjs.
     3. Run the live steps.
     4. Make at most one derived-artefact commit. It holds only what the live run produced or pinned: screenshots, eval/reports/*, docs/reports/*, docs/verification/*, and test pins, remap fixtures and label remaps derived from the run. It touches no runtime file under src/, web/, scripts/, policy/ or migrations/.
     5. Run npm run typecheck and npx vitest run on the final commit; both pass.

     This is M1's practice, and it is what makes health.version meaningful.

2. Headless criteria only. Every criterion must be satisfiable by the executor under the jev-scripts service token. None needs a signed-in human, a Cloudflare dashboard figure, or a reply or sign-off from Stevan; those are in §5.6. In M1, COPILOT-023, 054, 055, 060 and 072 had to be amended mid-run because they did.

3. Token caps on session requests only. The 12,000 cap is asserted on replay and eval max_input_tokens, and on the worst case (tests/unit/worst-case.ts, via npx vitest run tests/unit/engine-groups.test.ts tests/unit/policy-build.test.ts). Whole-bank figures and probe-questions.mjs figures are information only.

4. Policy candidates. A story that changes policy/src (the policy chain in HOT FILES) follows these steps:

   1. Regenerate what the change makes stale: the policy fixtures (the scripts/build-policy.mjs header commands), the stub answers (node scripts/gen-stub-answers.mjs), policy/REDPEN.md (node scripts/redpen.mjs) and policy/LABELS.md (node scripts/labels-sheet.mjs).
   2. Build both scenarios with node scripts/build-policy.mjs --scenario <s> --next-version --out policy/build/<s>.v<N>.json. Never use a literal version. --next-version reads the tracked policy/build/, so no server is needed.
   3. Commit the code, the sources and the bundles together, then deploy, so the Worker's loader accepts the new shapes before any upload.
   4. Upload each draft with node scripts/publish-policy.mjs --scenario <s> --version <N>. It answers 409 not_evaluated, which is expected.
   5. Run the story's live probes pinned to the candidate (--policy-version <N>).
   6. Promote only through the gate: run node scripts/eval.mjs --scenario both --layers l1,l4,l6 --policy-version <N> --fresh --run <story>-<yyyymmdd>, then publish-policy.mjs --scenario <s> --version <N> for both scenarios. The gate is L1 ≥ 90 % per scenario, plus L4 and L6.
   7. List every case that passed in eval/reports/final-20260927-{onboarding,cs}.l1.json and now fails, with its score.

   A failed candidate stays a draft, and the story stays passes:false with its failing cases. No threshold is lowered and no label is edited to make a gate pass.

5. New policy fields are optional. Every field M1b adds to src/policy/types.ts is optional; absent means M1 behaviour. This covers kind, applies/due/satisfied_by/surface_when, texts_from, known_note, view_labels, situation_fit_hard, concern_reopen_window_s, served_countries, priors and the prejudge drop step. New code deployed before its candidate is published therefore never breaks the published bundle. Each story tests its field absent on a clone of the committed fixture.

6. Times, not line numbers, in live probes. Line numbers in this PRD are transcript_rev 1 (the v1 stitch); after 104e the four samples are v2, with new i. Unit tests on tests/fixtures/stitched/<call>.v1.json keep the v1 numbers. Live probes select by call time (utterances.t), or through tests/fixtures/remap/<call>.json (104e), never by a literal i.

7. UI evidence from the deployed dashboard. Use node scripts/design/shoot-dashboard.mjs docs/design/evidence '<shots>' --deployed --at <mm:ss> --expect '<selector>', where each shot is [name, query, scheme, 1440, 900] and --at/--until/--expect/--expect-none come from 102a. Take a light shot and a dark shot; the review view adds view=review to the query. Before shooting, run a cache-warming replay-ws without --eval-uid, so the dashboard's session hits the same answers. A state that depends on Jev is shot with --until '<selector>', which pauses the page's own session the first time that state renders. A candidate story shoots after it publishes, because the page's session uses the published policy.

8. Fixtures. The new kinds curation, decisions and remap join FIXTURE_KINDS (scripts/lib/fixtures.ts) and the schema-driven tests/unit/fixtures-clean.test.ts. They hold pseudonymised text only. tests/fixtures/exports/ keeps its call-coach exports. Test-only inputs that are not fixtures (a sample approvals reply, synthetic transcripts) are built inside the test and written to a temporary directory.

9. Status notes. Block reasons and status notes use plain words, with no apostrophes or shell metacharacters. In M1 an apostrophe crashed otto (fixed in otto ab20ebb); nothing relies on that fix.

10. Rep-facing words.

    • A policy text (item titles, hints and notes, plan.* labels, chips, situation texts) renders only when the pinned bundle holds it approved (INV-COPILOT-003, INV-COPILOT-015).
    • UI chrome is the fixed strings in web/src named by docs/design/DESIGN.md: pane and section names ("Now", "Coming up", "Covered", "Plan for this call" today), review-panel labels, and the rule reasons listed in DESIGN.md §Review view. Chrome is never built from call data, so it needs no red pen, as today.

HOT FILES. Stories that edit the same file are ordered by dependencies. Every edit is additive: append fields, rules and registrations; never reorder or rename. The run is sequential: otto implement, one story per iteration, as in M1.

#4. Product Invariants

INV-COPILOT-001 to INV-COPILOT-014 carry forward unchanged; the full text is in prd.md §4, and stories cite them by id.

• INV-COPILOT-001 src/engine/** is pure: no cloudflare:workers import, and no Date.now, Math.random, fetch or crypto.getRandomValues. Identical input gives identical output, so every decision is replayable.
• INV-COPILOT-002 said_* items persist only on rep turns. *_known facts persist on any turn. Nothing un-persists within a session.
• INV-COPILOT-003 Every rep-facing policy string is approved text or a typed approved template. The loader hard-rejects [VERIFY and any line without an allowlisted approved_by, with no bypass.
• INV-COPILOT-004 Transcript text is pseudonymised before it reaches D1, the DO, Jev, R2 eval/ or the browser. Coach prose never enters D1.
• INV-COPILOT-005 Every answer row stores its hashes, its model and the exact post-budget state. Every paid request writes a jev_requests row. A cached answer is never served to a different state.
• INV-COPILOT-006 No request above 12,000 estimated tokens leaves the DO. Score levels are strings. chars_per_token is policy data.
• INV-COPILOT-007 Access fronts every hostname, and the Worker verifies the JWT. No credential appears in the repo or in a published page.
• INV-COPILOT-008 D1 statements bind ≤ 100 parameters (chunkForD1).
• INV-COPILOT-009 The browser owns the clock. The DO sets no timers or alarms and processes messages on one serial chain.
• INV-COPILOT-010 HTTP 402 code 2021 stops the session and is never retried. Errors hold the previous snapshot and are marked unknown.
• INV-COPILOT-011 REWRITE_ENABLED defaults to false.
• INV-COPILOT-012 No closing or activation probability appears anywhere.
• INV-COPILOT-013 A policy is promoted only through a passing eval run; there is no bootstrap.
• INV-COPILOT-014 Every transcript line, policy text, note or tag reaches the DOM only through textContent/createTextNode.

New in M1b:

• INV-COPILOT-015 No unapproved text is shown (it extends INV-003).
  • A policy text enters policy/src only approved. The approval comes from an approver-supplied file (Stevan's policy/proposals/2026-09-27.json carries approved_by), applied by scripts/apply-label-approvals.mjs. No story sets approved_by itself.
  • The views render a new text id only when the pinned bundle holds it approved; otherwise they keep today's approved text or omit the line.
  • The situation address_ties_me_to_tax_residency stays out of policy/src until decision 13. Its [VERIFY] point is a draft; its approved headline and hint wait with it, because the builder requires a situation's core_text_id to be one of its points (src/policy/build.ts:587).
  • Sources: FEEDBACK §2d; decision 2f.
• INV-COPILOT-016 A fact item never nags.
  • A fact item has no live row. When satisfied it moves to plan.known with its source, and it returns as the card only while its surface_when fires.
  • Fact and judgement items are never counted in any score, live or in the review.
  • Sources: FEEDBACK §2c-§2d; proposal §5.1.
• INV-COPILOT-017 One concern row per episode window.
  • A concern clears only on a client utterance of ≥ 4 words that carries the Jev clearing signal.
  • A raise of the same type within concern_reopen_window_s (60 s of call time) of the last close keeps the previous start_i, so the same row reopens.
  • Sources: FEEDBACK §2b; proposal §6.
• INV-COPILOT-018 Nothing renders before it is said.
  • A transcript row appears only once the clock passes its u.t, and word k only at its estimated time. Nothing beyond the clock is drawn.
  • A decision's feedback appears only after its utterance's t_end and the decision's arrival.
  • A seeded fact names its real source: "From sign-up" only for signup. A seeded chip has no time link.
  • Sources: FEEDBACK §1, §2a; proposal §3.2.
• INV-COPILOT-019 Curation survives re-stitching.
  • A forced re-import of a call that holds marks or labels runs only with the curation counts and latest timestamps of its export (tests/fixtures/curation/<call>.rev<N>.json, current transcript_rev). The replacement's claim statement checks them atomically, so a mark written after the export makes the replacement change nothing and answer 409.
  • Marked moments, marks and labels (including gold_json.i) are re-inserted at the remapped i by an idempotent, audited batch. Mark and label counts are equal before and after.
  • Sources: proposal §8 risk 1, §10 item 1.
• INV-COPILOT-020 Pre-call facts are closed-vocabulary and snapshotted.
  • On every write path, precall_json holds only policy slot label ids, ISO 4217 codes from the bank, {digits, code} amounts and a source in {signup, crm, demo}. signup is reserved for the M2 join.
  • The value is copied, with its converted seed, into sessions.precall_json once at session start, and never changes for that session.
  • A forced transcript replacement without precall in its payload keeps the call's value (112b).
  • Sources: proposal §5.2; INV-001, INV-004.

#5. User Stories

Every story is one code commit of one concern, plus at most one derived-artefact commit (§3 convention 1). "Estimate" counts otto iterations. A story with an eval gate or a Jev-dependent probe also carries a one-iteration retry budget, reported separately in the sizing table. Line numbers are v1 (transcript_rev 1) unless a criterion says otherwise. Ordering reasons for dependencies are in each story's Notes. Completed M1 stories on main (COPILOT-046, 058e, 065, 070 and the rest) are prerequisites, never dependency ids.

#Phase A — Live granularity in replay

• ID: COPILOT-102a

• Title: Screenshot tooling: --at, --until, --expect and --expect-none for the deployed dashboard [INTEGRATION-CRITICAL]

• Description: As the builder, I want the screenshot script to pause on a time or on a rendered state and to assert what the page shows, so that every M1b UI story's evidence is taken in the page's own session and fails when the state is absent.

• Acceptance Criteria:

  • scripts/design/shoot-dashboard.mjs (HOT: this story owns the flags) gains four flags, documented in its header:

    • --at <mm:ss>: after load, press 20× and Play, and pause once the player clock reaches the time. Wait until the session queue is empty, then shoot.
    • --until '<css selector>': play at 20× and pause the first time the selector matches, polling every frame; exit 1 if it never matches before the call ends.
    • --expect '<css selector>': after the pause, poll up to 10 s for a match; print the match count; exit 1 when there is none. It never prints page text.
    • --expect-none '<css selector>': exit 1 when there is any match.

    Each flag's core is a pure function in scripts/design/lib/shoot-flags.mjs (new).

  • Tests. tests/unit/shoot-dashboard.test.ts, over happy-dom fixture pages, covers flag parsing; --until pausing on the first match; --expect failing with no match; and --expect-none failing on a match. npx vitest run tests/unit/shoot-dashboard.test.ts → all passed; npm run typecheck exits 0.

  • SAFETY: without the new flags, the script behaves exactly as today (--deployed, --play, --wait).

  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD, asserted by the script), against real Playwright playback of 3339895706. Each case prints its exit code:

    1. Positive. node scripts/design/shoot-dashboard.mjs /tmp/m1b-102a '[["pos","?call=3339895706","light",1440,900]]' --deployed --until '.item.current' --expect '.item.current' → 0, and the PNG exists.
    2. --at. … '[["at","?call=3339895706","dark",1440,900]]' --deployed --at 00:30 --expect '.item' → 0; the printed pause time is ≥ 30 s, and the queue is empty at the shot.
    3. Negative, --expect-none. … --deployed --at 00:30 --expect-none '.item' → 1.
    4. Negative, --until. … --deployed --until '[data-never-present]' → 1, after the call ends at 20×.

    Quote the four exit codes.

• Dependencies: none

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-102

• Title: Transcript text appears word by word between a line's start and end [INTEGRATION-CRITICAL]

• Description: As a rep watching a replay, I want each line's words to appear as they are spoken rather than when the line ends, so that a 45 s client turn reads as it happens and nothing appears before its estimated spoken moment.

• Acceptance Criteria:

  • web/src/transcript.ts LiveTranscript.update (today passedIndex over t_end, :207-212) changes as follows:

    • The row for line i is inserted once the clock t ≥ u.t.
    • Its text is the first k words, where k = floor(u.words × clamp((t − u.t) / (u.t_end − u.t), 0, 1)). A zero-span line shows whole.
    • The row carries data-partial until t ≥ u.t_end.
    • The latest-line tint sits on the row being spoken.
    • Rows stay in i order, so a backchannel whose t falls inside a partial line sits above it (v1 lines 6 and 7 inside line 8).
    • A seek back removes rows with u.t > t and truncates partial ones.
    • Covered tags attach only to complete rows.
    • Nothing beyond the clock is drawn.
    • Words are spread evenly over the line's own span, because GET /api/calls/:id has no fragment times. The v2 parts keep each span to about 12 s.
    • Text reaches the DOM only through textContent.
    • The reveal rule is a pure exported function, revealedWords(u, t), which 118b reuses.

  • docs/design/DESIGN.md §Transcript pane gains: "Text appears word by word between the line's start and end. Inside a line the times are estimated by spreading its words evenly until live transcription supplies real ones (M3)."

  • Tests. tests/unit/web-transcript.test.ts on tests/fixtures/stitched/3339895706.v1.json. Line 8 has t 44.99, t_end 89.45 and 112 words.

    • At 44.9 s, row 8 is absent.
    • At 60.0 s, it shows 37 ± 1 words and has data-partial.
    • At 89.5 s, it is complete, without data-partial.
    • At 70.0 s, row 7 (t 69.35) sits above row 8.
    • A seek from 89.5 s to 50.0 s leaves row 8 at 12 ± 1 words and removes row 7.

    npx vitest run tests/unit/web-transcript.test.ts tests/unit/web-dom-safety.test.ts → all passed. npm run typecheck exits 0. grep -rn "innerHTML\|insertAdjacentHTML" web/src prints nothing.

  • [UI] Design artifact: DESIGN.md §Transcript pane (G) and docs/design/shotgun/G/live.html. No new token or colour.

  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD):

    1. node scripts/deploy.mjs.
    2. node scripts/design/shoot-dashboard.mjs docs/design/evidence '[["COPILOT-102-light","?call=3339895706","light",1440,900],["COPILOT-102-dark","?call=3339895706","dark",1440,900]]' --deployed --at 01:00 --expect '[data-partial]' exits 0 and writes both PNGs. Quote the match counts.

  • INVARIANT: INV-COPILOT-018; INV-COPILOT-014; INV-COPILOT-009.

• Dependencies: COPILOT-102a

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-103

• Title: STITCH_V2: sentence-and-time split of long turns, with true part start times

• Description: As the engine, I want long turns split into sentence-sized parts under decision 1a's rule, so that Jev is asked every 5-12 s during a monologue, while v1 output stays byte-identical.

• Acceptance Criteria:

  • Parameters (src/ingest/stitch.ts):
    • StitchParams gains optional splitMinWords, splitMinS, splitForceS and splitLookaheadS.
    • export const STITCH_V2 = Object.freeze({ ...STITCH_V1, version: 2, splitMinWords: 6, splitMinS: 5, splitForceS: 12, splitLookaheadS: 3 }).
  • Where it runs: inside each merged turn, after the merge step (:160-171) and before the parts loop (:186-213).
  • Cut rules:
    • A part is cut at a sentence end (a word ending ., ? or !) once it holds ≥ splitMinWords words and its estimated span is ≥ splitMinS.
    • When the span passes splitForceS without such a cut, the part is cut at the first sentence or clause boundary (. ? ! ; or ,) within the next splitLookaheadS seconds. With no boundary in that window, it is cut at the word boundary where the lookahead ends. The lookahead is bounded, so no part exceeds splitForceS + splitLookaheadS, with one exception: a single word longer than that.
    • A trailing piece under 4 words that is not the last of its turn joins the part before it.
  • Spans come from the member fragments' real start and end, and from word share inside a fragment.
  • Part times: the first part keeps turn.t; each later part's t is the previous part's t_end; the last part's t_end is turn.t_end.
  • Unchanged from v1:
    • The v1 maxWords split still applies inside a part.
    • kind, member_ids (the turn's) and decision_point, as today.
    • The output order (t_end, then t, :230-233).
    • No merge across speakers.
    • Without the new params, stitch() is exactly v1.
  • Tests (tests/unit/stitch.test.ts):
    • Golden. stitch(fragments, STITCH_V1) on the four samples' fragments (tests/fixtures/samples/<call>.json) deep-equals the utterances of tests/fixtures/stitched/<call>.v1.json.
    • 3339895706 under STITCH_V2:
      • 125-145 decision points.
      • The longest gap between consecutive decision points (by t_end) is ≤ 15 s, and the p90 is ≤ 11 s.
      • No part is under 4 words unless it is the last of its turn.
      • Within each turn, t is non-decreasing and every t_end ≥ t.
      • The test prints the three numbers, plus the other three samples' decision-point counts (about 165, 68 and 44 expected).
    • Sparse punctuation. A synthetic 40 s fragment with no punctuation cuts every ≤ 15 s. A comma 2 s after 12 s is taken, and one 5 s after is not.
  • v2 fixtures. node scripts/make-fixtures.mjs --stitch-only (new; it needs no data/, so it runs in an otto worktree) rebuilds tests/fixtures/stitched/<call>.v1.json and writes <call>.v2.json (kind stitched, stitch_version: 2) from the committed tests/fixtures/samples/<call>.json for the four samples. After the run:
    • git diff --exit-code tests/fixtures/stitched/*.v1.json passes;
    • git status --porcelain tests/fixtures/stitched lists exactly the four .v2.json files.
  • npx vitest run tests/unit/stitch.test.ts tests/unit/fixtures-clean.test.ts → all passed; npm run typecheck exits 0.
  • SAFETY: STITCH_V1, the default parameter of stitch(), INGEST and every Worker caller stay unchanged here. 104d moves the Worker and 106 the policy.
  • INVARIANT: INV-COPILOT-004 (fixtures are built from pseudonymised samples only).

• Dependencies: none

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-104a

• Title: Export the review sessions, the curation and the CRM key before any re-import, from one consistent snapshot [INTEGRATION-CRITICAL]

• Description: As Stevan, I want my replay session, the run it matched, and every mark, label and CRM key saved as fixtures before a transcript is replaced, so that a forced re-import, which deletes every derived row of the call (DERIVED_TABLES, src/routes/calls-import.ts:24), loses nothing.

• Acceptance Criteria:

  • Curation export. scripts/export-call-curation.mjs --call <id> runs read-only SELECTs through node scripts/with-cf-env.mjs npx wrangler d1 execute copilot --remote --json. It writes tests/fixtures/curation/<call>.rev<N>.json (kind curation), where N is the call's current transcript_rev: 1 for 3339895706, 3303259297 and 3347356034, and 2 for 3485591407 on 2026-09-27.
    • Contents:
      • the call row's transcript_rev, stitch_version and pd_ct_id;
      • the moments that carry a mark, with their marks;
      • the call's labels, with their label_id and gold_json;
      • i, t, t_end, speaker, kind, words, member_ids for every utterance, without text;
      • expected_curation: {marks, labels, last_mark_at, last_label_at};
      • policy_at_export: {version, checklist_ids, risk_ids}: the call scenario's published policy at export time, the evidence for a label whose target id a later policy retires.
    • Consistency. (transcript_rev, content_hash, expected_curation, sha256 of the exported rows) is read before and after the rows. The export is written only when both reads are equal and match the exported rows. Otherwise it retries, up to 3 times, then exits 1. So a replacement, a restore or a new mark during the export is detected. tests/unit/export-curation.test.ts simulates a replacement between the two reads.
    • Quoted counts: 3339895706 has 3 marks; 3303259297 has 1 label (i 75, gold_json.i 75); 3485591407 has pd_ct_id 109829; the rest have none.
  • Decisions export. --sessions 49e3e48f-c169-458d-85a6-ae6c5c4e745d,1d160d96-9b60-480c-bb67-c146f8739b13 writes tests/fixtures/decisions/3339895706.v4.<first 8 characters of the session id>.json (kind decisions).
    • Per decision: i; decision_json without jev telemetry; and the Jev answers it consumed (the answers row at answers_state_hash/answers_qset_hash, the move_answers row at move_state_hash/move_qset_hash, or null).
    • Quoted counts: 96 decisions up to i=121, and 86 up to i=107.
    • These answers are the evidence that 105a, 107 and 117 replay and 119 quotes (v1 i=30). A re-import deletes the D1 rows.
  • Fixture kinds. FIXTURE_KINDS (scripts/lib/fixtures.ts) gains curation, decisions and remap. tests/unit/fixtures-clean.test.ts covers them, including a test of the consistency retry on changing counts. npx vitest run tests/unit/fixtures-clean.test.ts tests/unit/export-curation.test.ts → all passed.
  • Docs. docs/demo-script.md and docs/runbook/m1-acceptance.md each gain one line: "Utterance numbers here are transcript_rev 1 (the v1 stitch); COPILOT-104e regenerates them."
  • [INTEGRATION-CRITICAL] Live probe: both export commands, run against remote D1, print the counts and expected_curation above. Quote them.
  • SAFETY: SELECT only; no write.
  • INVARIANT: INV-COPILOT-019; INV-COPILOT-004.

• Dependencies: none

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-104f

• Title: The v1→v2 i remap on effective spans, speakers and fragments

• Description: As the operator, I want every exported moment, mark and label mapped from the v1 lines to the v2 parts that hold the same words, so that curation lands on the same words after the re-import.

• Acceptance Criteria:

  • scripts/remap-i.mjs --export <curation file> --to tests/fixtures/stitched/<call>.v2.json prints the map as JSON. Its pure core is scripts/lib/remap-i.ts, and --apply is 104c's.

    • Effective spans. v1 split parts of one turn share t and member_ids (v1 lines 89 and 90: t 464.435, member_ids [119], t_end 500.045 and 505.81). So each later part's effective span starts at the previous same-turn part's t_end: line 90's span is [500.045, 505.81].
    • Line to parts. An old line maps to the v2 parts of the same speaker whose member_ids intersect its own and whose [t, t_end) overlaps its effective span. A backchannel maps to the v2 backchannel with the same member_ids.
    • Tie-breaks. A time belongs to the part whose [t, t_end) contains it; the last part owns its t_end.
    • Moments. A moment's start_i/end_i map to the first and last matched part.
    • Labels. A label maps to the part containing the old line's effective end. Both labels.i and gold_json.i are rewritten, and label_id is kept.
    • Moment ids. moment_id is rebuilt by momentId() (src/engine/moments.ts:114), keeping the policy-hash suffix. Each mark's moment_id follows; mark ids are kept.
    • Unmatched lines. It lists every old line with no match; none are expected.

  • Tests. tests/unit/remap-i.test.ts covers:

    • a split turn (v1 i=8);
    • v1 i=89 and i=90, each to the parts inside its own effective span (a moment on i=90 must not map back to 464.435);
    • a label at the end of a long rep turn;
    • overlapping speakers;
    • a boundary tie;
    • gold_json.i rewritten with label_id kept;
    • a mark following its moment;
    • a restored false-positive label still dismissing its item when applyDurableMutations (src/session/checkpoint.ts:290) re-applies it on a v2 state.

    npx vitest run tests/unit/remap-i.test.ts → all passed; npm run typecheck exits 0.

• Dependencies: COPILOT-103, COPILOT-104a

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-104b

• Title: Re-import CLI and route: --stitch 2, pd_ct_id kept, and an atomic curation precondition on forced replacement [INTEGRATION-CRITICAL]

• Description: As the operator, I want a forced transcript replacement to refuse atomically when the call's marks or labels changed since the export, and to keep the call's CRM key, so that 104e's destructive step cannot delete curation made after the export.

• Acceptance Criteria:

  • Route (src/routes/calls-import.ts; HOT, first):

    • A forced replacement of a call that holds marks or labels requires expected_curation: {marks, labels, last_mark_at, last_label_at} in the request; without it the answer is 409 curation_required.
    • The replacement's claim statement (the UPDATE calls … WHERE … of the one db.batch()) adds AND conditions comparing the current counts and the latest created_at of the call's marks and labels with those values. A mark or label written after the export therefore makes the claim change 0 rows, and the route answers 409 curation_changed with the database untouched.
    • A first import (no call row) needs no expected_curation.
    • A forced replacement that omits it has its claim assert zero marks and zero labels, atomically. A mark written after a preliminary empty check therefore makes the claim change 0 rows (409 curation_changed).
    • A payload without pd_ct_id keeps the stored one (COALESCE); one with it replaces it.

  • CLI. scripts/import-fixture.mjs --stitch 1|2 (default 2) wraps tests/fixtures/stitched/<id>.v<stitch>.json, and sends pd_ct_id and expected_curation from tests/fixtures/curation/<id>.rev<N>.json.

    • On a forced replacement of a call with curation, it exits 1 when that export is missing for the call's current transcript_rev.
    • --print-payload prints the request without sending it.
    • scripts/import-call-coach.mjs gains the same --stitch flag.

  • Demo check. scripts/lib/demo-check.ts and scripts/demo-check.mjs:53 read tests/fixtures/stitched/<call>.v<N>.json for --stitch N (default 2). tests/unit/demo-check.test.ts covers both versions, and its existing integration test pins --stitch 1 with the v1 final-20260927 report until 104e re-pins it to v2.

  • Tests (tests/workers/calls-import.test.ts):

    • a mark written between reading expected_curation and the claim gives 409 curation_changed, and every row is unchanged;
    • a missing expected_curation on a call with curation gives 409 curation_required;
    • with expected_curation omitted, a mark written after an empty check gives 409 curation_changed;
    • a first import succeeds with no export (regression);
    • pd_ct_id is kept on a forced v2 replacement.

    npx vitest run -c vitest.workers.config.ts tests/workers/calls-import.test.ts and npx vitest run tests/unit/demo-check.test.ts → all passed; npm run typecheck exits 0.

  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD), negative only:

    1. node scripts/import-fixture.mjs --call 3339895706 --stitch 2 --force --expected-rev 1 --print-payload, with expected_curation.marks set to 0 by jq, is sent with curl -s -X POST and the service-token headers to /api/calls/import?force=1&expected_rev=1. It answers 409 curation_changed.
    2. node scripts/with-cf-env.mjs npx wrangler d1 execute copilot --remote --command "SELECT transcript_rev, stitch_version FROM calls WHERE call_id='3339895706'" still shows 1 and 1. Quote both.

  • INVARIANT: INV-COPILOT-019; INV-COPILOT-008.

• Dependencies: COPILOT-103, COPILOT-104a

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-104c

• Title: A validated, idempotent curation-restore route and remap-i --apply [INTEGRATION-CRITICAL]

• Description: As the operator, I want the remapped marks and labels restored through one validated route, which refuses rows that belong to another call and ignores a repeated post, so that restoration after a re-import is safe to repeat.

• Acceptance Criteria:

  • src/routes/curation.ts adds POST /api/calls/:id/curation, registered by one dispatch line in src/index.ts (HOT). Service token only; an email actor gets 403.
  • Body: {expected_rev, moments[], marks[], labels[], policy_at_export?}.
  • Field-level schema. Every row is validated against it before any write; a failure answers 422, naming the row and field.
    • Columns (the schema's real ones, migrations/0001_init.sql):
      • moments: moment_id, call_id, scenario, kind, start_i, end_i, topic, jev_json, policy_hash, priority, review_state, created_at;
      • marks: mark_id, moment_id, verdict, note, use_as_example, admin, created_at;
      • labels: label_id, call_id, i, question_id, gold_json, admin, created_at.
    • Identifiers:
      • call_id equals the URL's;
      • moment_id equals momentId(call_id, kind, topic, start_i, policy_hash) recomputed from the row;
      • mark_id and label_id are strings of the existing id formats;
      • each mark's moment_id is a moment in the same body;
      • question_id is a policy id;
      • kind and verdict are the schema's CHECK values.
    • Integers: 0 ≤ start_i ≤ end_i < n_utterances at expected_rev, and 0 ≤ labels.i < n_utterances.
    • Audit metadata: created_at is ISO 8601, and admin is an email or a service-token common name, as the writers store it.
    • gold_json: it parses to exactly the durable-label shape FalsePositiveLabel (src/session/checkpoint.ts:207): {value: false, kind: 'false_positive', target, id, i}, with no other property.
      • target is one of DismissTarget (src/engine/dismiss.ts:8): risk, must_say or concern.
      • id fits the target: a risk-flag id or a checklist id of the call's scenario policy, or for concern the id form the dismiss path writes.
      • Retired ids. A must_say or risk label whose id the current policy no longer checks (110d retires six onboarding ids) is accepted when the body carries policy_at_export (104a) and the id is in its checklist_ids or risk_ids. It is restored unchanged (the closed gold_json shape) and reported under retired in the response and in the audit row, with the export's policy version as its evidence. A dismissal of an id the engine no longer checks has no effect, so restoring it is harmless and keeps the record. An id in neither the current nor the exported policy is still 422.
      • i equals the label's i, and id equals question_id.
      • Any other shape, kind or property answers 422.
    • Text:
      • marks.note and moments.topic pass assertRedactedText/isPseudonymised;
      • every string inside moments.jev_json passes them too, and jev_json parses;
      • identifiers, timestamps and admin are not prose and skip the guards.
    • Input duplicates: a duplicate id within the body answers 422.
  • Collisions. The primary keys are the identity (moment_id, mark_id, label_id). A key that already exists answers 409 conflict, naming the row, unless the stored row belongs to this call and is identical in every column. An identical stored row is a no-op.
  • Writes. One db.batch() guarded by revGuard(call_id, expected_rev), plus audit_log{action:'call.remap_i'} with the counts. A stale expected_rev answers 409 with nothing written.
  • Apply. scripts/remap-i.mjs --apply posts the remapped export.
  • Tests (tests/workers/curation.test.ts): a real-row round trip (rows exported from a seeded test database, remapped by 104f and posted back are identical except the remapped fields); insert; identical re-post (zero counts); another call's moment_id or label_id → 409; a non-deterministic moment_id → 422; a duplicate in the body → 422; each field rule; a gold_json with an extra property, another kind, an unknown target or a foreign id → 422; a label on a retired id with policy_at_export evidence → restored, and reported as retired; stale rev → 409; email → 403; the audit row. npx vitest run -c vitest.workers.config.ts tests/workers/curation.test.ts → all passed.
  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD), on a disposable synthetic call:
    1. node scripts/make-synthetic-call.mjs --from 3347356034 --decision-points 20 --id m1b-curation-probe imports it.
    2. POST one moment, one mark and one label built for it → 200, counts 1/1/1.
    3. POST the identical body again → 200, zero counts.
    4. SELECT the three rows and compare them with the body; quote both.
    5. POST a label reusing the probe's label_id with a different gold_json → 409 conflict.
    6. Quote the audit rows.
  • INVARIANT: INV-COPILOT-019; INV-COPILOT-004; INV-COPILOT-007; INV-COPILOT-008.

• Dependencies: COPILOT-104f

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-104d

• Title: Worker ingest on STITCH_V2: uploads and speaker-map re-stitching produce sentence-sized parts [INTEGRATION-CRITICAL]

• Description: As Stevan, I want uploaded calls stitched under the same v2 rule as the imported samples, so that an upload never replays with 45 s turns.

• Acceptance Criteria:

  • src/routes/ingest.ts:381 and src/routes/speaker-map.ts:308 call stitch(…, STITCH_V2) and write stitch_version = 2 (ingest.ts:407, speaker-map.ts:354). INGEST (src/policy/build.ts) is unchanged here; 106 changes it with its candidate.

  • Forced paths. Both forced replacement paths (ingest.ts's claim at :400-412 and speaker-map.ts's at :350-356) gain 104b's atomic curation condition. The claim asserts the expected_curation sent, or zero marks and labels when none is sent, so a mark written concurrently makes the claim change 0 rows (409 curation_changed).

  • Tests.

    • tests/workers/ingest.test.ts asserts stitch_version = 2 and v2 decision points on a new upload.
    • tests/workers/speaker-map-apply.test.ts asserts the same after a forced speaker-map re-stitch.
    • For both paths, a concurrent mark written before the claim gives 409 and leaves every row unchanged.

    npx vitest run -c vitest.workers.config.ts tests/workers/ingest.test.ts tests/workers/speaker-map-apply.test.ts → all passed.

  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD):

    1. Pick one of the four uploaded copies of 3339895706 (up_06337679…, up_0873645c…, up_869446e2…, up_ef077387…) with 0 marks and 0 labels.
    2. Re-stitch it through POST /api/calls/<upload id>/speaker-map with force and its stored role map (the COPILOT-070 path; no transcription cost).
    3. SELECT stitch_version, n_decision_points FROM calls WHERE call_id = '<upload id>' shows 2 and a count above the v1 96. Quote it.

    The other copies stay v1, and 118's register says so.

  • INVARIANT: INV-COPILOT-004 (the re-stitch works on stored pseudonymised fragments).

• Dependencies: COPILOT-103, COPILOT-104b

• Priority: MEDIUM

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-104e

• Title: Re-import the four samples under STITCH_V2, restore the curation, remap the labels and the demo script, measure cost [INTEGRATION-CRITICAL]

• Description: As Stevan, I want the four sample calls re-imported at the new granularity, with my marks, labels and the CRM key carried over and the cost measured, so that the deployed replay shows sentence-level cadence without losing any curation.

• Acceptance Criteria:

  • [INTEGRATION-CRITICAL] Live run on the deployed Worker (health.version == HEAD), in this order:

    1. Before.

       • node scripts/with-cf-env.mjs npx wrangler d1 execute copilot --remote --command "SELECT COUNT(*) AS n FROM marks k JOIN moments m ON m.moment_id = k.moment_id WHERE m.call_id = '3339895706'" → 3.
       • … "SELECT COUNT(*) AS n FROM labels WHERE call_id = '3303259297'" → 1.
       • Quote the published policy versions (GET /api/policy/onboarding, …/customer_success). This story's evaluation pins them.

    2. For each sample:

       • node scripts/import-fixture.mjs --call <id> --stitch 2 --force --expected-rev <N> prints imported <id> rev <N+1>; 104b's precondition guards it.
       • node scripts/remap-i.mjs --export tests/fixtures/curation/<id>.rev<N>.json --to tests/fixtures/stitched/<id>.v2.json --apply prints the inserted counts.
       • After an interruption, re-running --apply completes the restore (104c is idempotent). If import-fixture answers 409 curation_changed, re-export (104a) and repeat.

    3. After. … "SELECT c.call_id, c.transcript_rev, c.stitch_version, c.pd_ct_id, c.audio_r2_key IS NOT NULL AS has_audio, SUM(u.decision_point) AS dp FROM calls c JOIN utterances u ON u.call_id = c.call_id WHERE c.call_id IN ('3339895706','3303259297','3485591407','3347356034') GROUP BY c.call_id" must show:

       • stitch_version 2 on all four;
       • dp 125-145 for 3339895706 (the others quoted);
       • has_audio 1 for 3339895706;
       • pd_ct_id 109829 for 3485591407.

       The two counts of step 1 again give 3 and 1.

    4. Replay. node scripts/replay-ws.mjs --call 3339895706 --scenario onboarding --speed 20 --eval-uid m1b-stitch2-<yyyymmdd>-r → errors == 0, requests == decision_points, max_input_tokens ≤ 12000. Quote reconnects (about 5).

    5. Eval. node scripts/eval.mjs --scenario both --layers l4,l6 --policy-version <the version of step 1> --run m1b-stitch2-<yyyymmdd>.

       • L6 passes: every input ≤ 12,000, and cost_by_call ≤ L6_LIMITS.cost_per_call_usd for 3339895706 and 3303259297 (about $0.047 and $0.048 expected).
       • Quote L4, pass or fail; the L4 gate on v2 is 106's.
       • Append "M1b: STITCH_V2 (104e)" to docs/reports/cost-latency.md.

  • Derived-artefact commit (§3 convention 1):

    • tests/fixtures/remap/<call>.json (kind remap), the four v1→v2 maps.
    • eval/labelled/must-say.json with every i rewritten through the map. t and label values stay unchanged, with a remapped: {from_rev, date} note per call.
    • docs/demo-script.md rows (i, [mm:ss]) from eval/reports/m1b-stitch2-<yyyymmdd>.l4l6.json, with tests/unit/demo-check.test.ts re-pinned to it and --stitch 2 (a test-only change).
    • The i references in docs/runbook/m1-acceptance.md, rewritten.

    Then node scripts/demo-check.mjs eval/reports/m1b-stitch2-<yyyymmdd>.l4l6.json docs/demo-script.md exits 0, and on the final commit npx vitest run and npm run typecheck pass (including tests/unit/eval-cases.test.ts, eval-like-for-like-cases.test.ts, eval-l4l6.test.ts and demo-check.test.ts).

  • INVARIANT: INV-COPILOT-019; INV-COPILOT-004; INV-COPILOT-005.

• Dependencies: COPILOT-104b, COPILOT-104c, COPILOT-118a

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration (retry budget: 1, eval)

• Notes: The destructive step. 110c and 110d may have promoted candidates before this story runs, so the evaluated versions are the ones published at step 1, not an assumed v4.

• ID: COPILOT-105a

• Title: A presenter simulator over a recorded session [INTEGRATION-CRITICAL]

• Description: As the builder, I want to run the page's presenter over a session's recorded decisions and see every change, point and exit on the call clock, so that the cadence and lifetime rules can be measured and their screenshots located without guessing.

• Acceptance Criteria:

  • scripts/presenter-sim.mjs --session <session_id> [--log <replay log>] (new; asserts health.version == HEAD):

    • It reads the session's decisions from D1 (with-cf-env, read-only) and the utterances from GET /api/calls/:id.
    • It runs present() (web/src/presenter.ts) at 0.1 s steps. With --log (118a's format), each decision uses its recorded arrival; otherwise arrival is projected as t_end + 0.3 s and the output is labelled projected.
    • It prints JSON:
      • every card switch, with whether a client run was in progress;
      • the first point added to the open card mid-run;
      • the first time ≥ 2 points show;
      • every lastSuggestion interval;
      • every point's on-screen interval, with its exit reason;
      • the first time each item id opened.

    Later stories append fields.

  • Tests. tests/unit/presenter-sim.test.ts runs the simulator's core over tests/fixtures/decisions/3339895706.v4.49e3e48f.json and the v1 utterances. It reproduces the FEEDBACK §3 figures under today's presenter: the amount point on screen for 1.0 s, and the first-transfer-date point for 23 s. npx vitest run tests/unit/presenter-sim.test.ts → all passed.

  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD):

    1. node scripts/replay-ws.mjs --call 3339895706 --scenario onboarding --speed 20 --session m1b-105a-<yyyymmdd> → errors == 0.
    2. node scripts/presenter-sim.mjs --session <session_id> prints its JSON. Quote the switch count and the point intervals.

  • INVARIANT: INV-COPILOT-009 (it reads; it sets no timer anywhere).

• Dependencies: COPILOT-104a

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-105

• Title: Presenter: the change moment is the end of the client's run; new points on the open card move at sentence ends [INTEGRATION-CRITICAL]

• Description: As a rep, I want feedback (ticks, chips, caution, a new point on the open card) within a sentence of what was said, while the card itself waits for the client to finish (decision 1b), so that sentence-level decisions feel live without the headline jumping mid-turn.

• Acceptance Criteria:

  • web/src/presenter.ts (HOT, first):

    • Run end. isClientRunEnd(us, u, upto = us.length) is a client turn whose next turn (skipping backchannels and acks) is not the client's, or does not exist before upto. upto means that in live audio (M3) only what has arrived is read.
    • Change moments. dueFor (:153), nextClientEnd (:140) and releaseAt (:164) use run ends only.
      • A plan that changes the current item applies at the first boundary at or after L = max(arrival, dwell end, the end of the client run its decision belongs to). A boundary is L itself when no utterance is in progress at L; otherwise it is the end of the client run or the rep turn in progress. A client part that ends mid-run is never a boundary.
      • A decision on a run's last part therefore applies on arrival, once the dwell has passed.
      • An inserted item (isInsert, :125) uses the same rule, without the dwell.
      • After the call's last t_end, anything pending applies (as today).
    • On arrival. Ticks, chips, the caution and the purpose still apply on arrival. A plan whose current item id equals the open card's applies on arrival for any client-part decision: its new point shows at once, at most one per applied plan (apply, :176).
    • Flag. export const LIVE_CARD_AT_SENTENCE_END = false. When true, every client part end is a change moment.
    • Marker. A point revealed while a client run is still in progress carries data-midrun="1" (set by the presenter, rendered by web/src/plan.ts; HOT, first) until that run ends.

  • docs/design/DESIGN.md §Cadence rules:

    • Rule 1 is rewritten: items change state at the end of the client's run (the last client part before the rep speaks), after the dwell; or at every client part end while the flag is true.
    • Rule 4 gains "a new point on the open card may appear at any client sentence end".
    • The constants table gains the flag.

  • Tests. tests/unit/web-presenter.test.ts on tests/fixtures/stitched/3339895706.v2.json, with synthetic plans:

    • a card switch decided on a middle part of v1 line 8's parts applies at the last part's t_end;
    • a switch whose dwell ends mid-run applies at that run's end, not at the dwell's end;
    • a decision on a run's last part, arriving after the run ended, applies on arrival once the dwell has passed;
    • a point added to the open card on a middle part shows at that part's t_end plus arrival, with data-midrun="1", and the card id is unchanged until the run ends;
    • with the flag true, the switch applies at the middle part;
    • the existing cases pass, updated only where the change moment moved (named in the progress note).

    npx vitest run tests/unit/web-presenter.test.ts tests/unit/presenter-sim.test.ts tests/unit/web-plan.test.ts → all passed; npm run typecheck exits 0.

  • [UI] Design artifact: DESIGN.md §Cadence rules (rules 1 and 4) and docs/design/shotgun/G/NOTES.md (c).

  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD):

    1. node scripts/replay-ws.mjs --call 3339895706 --scenario onboarding --speed 20 --session m1b-105-<yyyymmdd> → errors == 0.
    2. node scripts/presenter-sim.mjs --session <session_id> prints 0 switches while a client run is in progress, and the first mid-run point time. Quote both. LIVE-PROBE [INTEGRATION-CRITICAL] on the deployed Worker (health.version == HEAD): (1) node scripts/replay-ws.mjs --call 3339895706 --scenario onboarding --speed 20 --session m1b-105- → errors == 0; (2) node scripts/presenter-sim.mjs --session <session_id> prints 0 switches while a client run is in progress, and the first mid-run point time with the run's state at that instant (quote both); (3) node scripts/design/shoot-dashboard.mjs docs/design/evidence '[["COPILOT-105-light","?call=3339895706","light",1440,900],["COPILOT-105-dark","?call=3339895706","dark",1440,900]]' --deployed --until '.item.current [data-midrun="1"]' exits 0: it pauses on a point the presenter added while the client's run was still open (data-midrun="1" on the current item), and the presenter-sim line for that instant shows client_run true and the same card id open from that point until the run's end; whether the client's text was still being revealed at that instant ([data-partial]) is reported, not required, because on this call the only mid-run point lands after the client's part ended while a trailing fragment keeps the run open (amended 2026-09-27: the rule under test is that points move at sentence ends while the card waits for the run's end, not a coincidence of reveal and point on one recording). Quote it.

  • INVARIANT: INV-COPILOT-009; INV-COPILOT-018.

• Dependencies: COPILOT-102, COPILOT-102a, COPILOT-103, COPILOT-104e, COPILOT-105a

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• Notes: 104e puts the v2 transcript in D1 for the live probe.

• ID: COPILOT-106

• Title: Re-tune the decision-counted thresholds and the window for sentence-level cadence; cost gate $0.06; a policy candidate on stitch_version 2 [INTEGRATION-CRITICAL]

• Description: As the policy owner, I want the counters tuned for one decision per turn re-tuned for the new cadence and gated by the eval, and the cost gate set as Stevan ruled (decision 16), so that concerns, purposes and cooldowns keep their real-time meaning and the gate says what it means.

• Acceptance Criteria:

  • Policy source and engine:

    Setting	Where	Change
    thresholds.concern_max_age	policy/src/rules-onboarding.json, rules-customer-success.json	8 → 12
    thresholds.card_cooldown_utts	same	3 → 4
    token_budget.window	same	12 → 16
    purpose_max_decisions	plan-onboarding.json, plan-customer-success.json	8 → 12
    COVERED_DWELL	src/engine/plan.ts:69	4 → 6
    INGEST.stitch_version	src/policy/build.ts:120	reads STITCH_V2.version; tests/unit/policy-build.test.ts expects {stitch_version: 2, redact_version: 1}

    Kept, and named in the progress note: confirm_updates 2, stage_confirm 2, ema_alpha 0.4, soft 11,000 and hard 12,000 (decision 15).

  • Cost gate. scripts/lib/eval-l6.ts L6_LIMITS.cost_per_call_usd goes 0.05 → 0.06 (decision 16). tests/unit/eval-l4l6.test.ts asserts that the check reads the constant: $0.055 passes and $0.065 fails. docs/architecture.md §9 (the L6 row) and docs/reports/cost-latency.md state $0.06.

  • Regeneration and worst case. Fixtures and stubs are regenerated. npx vitest run tests/unit/engine-groups.test.ts tests/unit/policy-build.test.ts: the worst case at window 16 is ≤ 12,000 for both scenarios (quoted). npx vitest run tests/unit and npm run typecheck exit 0.

  • [INTEGRATION-CRITICAL] Candidate and gate (§3 convention 4):

    1. node scripts/eval.mjs --scenario both --layers l1,l4,l6 --policy-version <N> --fresh --run m1b-tune-<yyyymmdd>. It must show:
       • L1 onboarding and cs ≥ 90 %;
       • L4: PASS on the v2 transcripts;
       • L6 PASS, with cost per call ≤ 0.06 quoted per call;
       • evaluated=true.
    2. window_to_8 fallbacks ≤ 11 % of the run's decisions (baseline 10.5 %). Quote node scripts/with-cf-env.mjs npx wrangler d1 execute copilot --remote --command "SELECT COUNT(*) AS n, SUM(json_extract(d.decision_json,'$.jev.budget.dropped') LIKE '%window_to_8%') AS k FROM decisions d JOIN sessions s ON s.session_id = d.session_id WHERE s.eval_uid LIKE 'm1b-tune-<yyyymmdd>%'". n must be > 0, and k / n must be numeric and ≤ 0.11. The path is $.jev.budget.dropped, because $.budget is a number.
    3. Publish both. Append "M1b: cadence re-tune (106)" to docs/reports/cost-latency.md.

  • INVARIANT: INV-COPILOT-006; INV-COPILOT-013.

• Dependencies: COPILOT-104e, COPILOT-105, COPILOT-119

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration (retry budget: 1, gate)

• Notes: 119 is the policy-chain order. The L6 constant and INGEST change with this candidate because its gate evaluates them (round-1 judgement, §7).

#Phase B — Card lifetime

• ID: COPILOT-121

• Title: Design board for the M1b live view: stacked points with the last suggestion, the guide pane, the player status slot [INTEGRATION-CRITICAL]

• Description: As Stevan, I want M1b's three visual changes drawn in G's own markup, in both themes, with a recommended variant each, so that 107, 114 and 120 build one design and my sign-off is a single review. This is the shotgun round the proposal put before 107 and 114; FEEDBACK §4 adds the status slot.

• Acceptance Criteria:

  • docs/design/shotgun/M1b/ (new) holds three things:
    • board.html;
    • variant pages built from copies of docs/design/shotgun/G/live.html and live.css (G's files stay unchanged: git diff --exit-code docs/design/shotgun/G);
    • a data.js of states drawn from 3339895706 (pseudonymised text only, and the approved wording of policy/proposals/2026-09-27.json).
  • The board poses three questions, with two variants each, in the /design-shotgun board format:
    1. Stacked points. Two stacked points against three (decision 3 set 3; the board shows the reading load). Both variants show a point that arrives grey with its tick after a rep turn (R4), and the grey "Last suggestion: …" line under a new card (R3).
    2. The guide pane (decision 2b). Chips with a source suffix, the "Guide for this call" head with its subtitle, Now, "Coming up" (≤ 3 grey rows, no state word) and a collapsed "Covered: …" line. Two densities of the Covered line.
    3. The player status. "catching up (N queued)" in a reserved slot after the speed control, or as an overlay above the bar.
  • node docs/design/shotgun/M1b/render.mjs (adapted from docs/design/shotgun/G/render.mjs) exits 0. It writes every variant at 1440x900, in light and dark, to docs/design/evidence/COPILOT-121-<question>-<variant>-{light,dark}.png.
  • docs/design/evidence/COPILOT-121-board.md records, per question, the variants, the recommendation and the reason, plus "Sign-off: pending (PRD §5.6 M-1)". docs/design/DESIGN.md §Variants gains "M1b board (COPILOT-121): recommended, pending sign-off", with a link. Only §Tokens "Live view tokens (G)" are used, with no new colour; the accent stays on points, ticks, the current dot and the Live pill.
  • [UI] Design artifact: DESIGN.md §Live view (G) and docs/design/shotgun/G/. Both themes, as above.
  • [INTEGRATION-CRITICAL] Live probe (Playwright, a real browser): node docs/design/shotgun/M1b/render.mjs exits 0. ls docs/design/evidence/COPILOT-121-*-light.png docs/design/evidence/COPILOT-121-*-dark.png | wc -l prints 12: 3 questions × 2 variants × 2 themes. Quote both.

• Dependencies: none

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-107

• Title: Presenter point lifetime: 12 s floor, stacking to three, sticky last suggestion, rep-turn grace [INTEGRATION-CRITICAL]

• Description: As a rep, I want a suggestion to stay long enough to read, later suggestions to stack under it, and never to see a point I have just made flash on, so that "say this" is usable while listening (decision 3, rules R1-R4).

• Acceptance Criteria:

  • web/src/presenter.ts (HOT, after 105):

    • Constants: LIVE_POINT_MIN = 12, LIVE_POINTS_MAX = 3 (decision 3), LIVE_LAST_SUGGESTION = 12 and LIVE_REP_POINT_GRACE_S = 3.
    • State: Presented gains revealedAt: Record<string, number> and lastSuggestion: { point, until } | null.
    • The rules below are pure functions of the clock, and seekPresented resets them. They apply in this order of precedence:
      1. Covered. A covered point folds, as today.
      2. Hard drop. A point whose situation is in the plan's dropped_hard (108a; absent means none) leaves within 1 s.
      3. Cap (R2). When a new point arrives while LIVE_POINTS_MAX are shown, the oldest uncovered point leaves at once, even inside its floor. This is the one exception to R1, and decision 3 sets it.
      4. Card switch (R3). On a card switch, the old card's points leave with it. Its newest uncovered point continues as lastSuggestion for LIVE_LAST_SUGGESTION.
      5. Floor (R1). A point dropped by an uncertain miss, or by a new plan on the same card, keeps its slot, tinted or grey, until its 12 s floor ends.
    • The sticky line counts toward LIVE_POINTS_MAX. While it shows, the card shows at most 2 points. A new point that would exceed the cap removes the sticky line first, because it is the oldest suggestion. A switch onto a card with 3 points drops it at once.
    • Rep-turn grace (R4). A point first introduced by a plan decided on a rep turn is held until the next rep-turn decision arrives, or until LIVE_REP_POINT_GRACE_S passes, whichever comes first.
      • A client decision in between (v1 line 10) does not release it, because only rep turns carry covered:: (coveredToAsk, src/engine/plan.ts:302).
      • If the releasing decision carries the point's covered_at, the point renders grey without the tint.
    • Client-due insert. isInsert (:125) also treats an item with due_by: 'client' (110f's contract field) as inserted.

  • web/src/plan.ts (HOT, first):

    • lastSuggestion renders as one grey line under the new card, labelled plan.last_suggestion from the pinned bundle's approved plan.view_labels ("Last suggestion", 110c).
    • Without that label, the line is the approved point text alone, grey, with no prefix (INV-COPILOT-015).
    • The card carries data-points="<n>".

  • docs/design/DESIGN.md §Cadence rules:

    • rule 10: the floor, with the precedence above;
    • rule 11: stacking, capped at 3;
    • rule 12: the last suggestion and the rep-turn grace;
    • rule 2 gains "a must-say made due by the client is inserted like a concern";
    • the constants table gains the four values.

  • scripts/presenter-sim.mjs (105a) additionally prints the shortest on-screen time of any point, excluding exits 1-4, and the points that left within 12 s for any other reason.

  • Tests.

    • tests/unit/web-presenter.test.ts replays tests/fixtures/decisions/3339895706.v4.49e3e48f.json over the v1 utterances, with arrival = t_end + 0.3 s on a 0.1 s clock:
      • The amount point, first introduced on v1 i=9 (rep, t_end 99.2), is never rendered tinted.
      • Every point that exits for a reason other than 1-4 has been on screen ≥ 12 s.
      • After each switch the presenter computes, the switched-away card's newest uncovered point is lastSuggestion for 12 s, unless a cap eviction removes it first. On this fixture that is the first-transfer-date point, after the switch following v1 i=17.
      • Never more than 3 suggestions show, counting points and the sticky line together.
      • A switch onto a three-point card drops the sticky line.
      • A synthetic item with due_by: 'client' opens without waiting out the dwell.
    • tests/unit/web-plan.test.ts covers the line with and without the label.

    npx vitest run tests/unit/web-presenter.test.ts tests/unit/web-plan.test.ts tests/unit/presenter-sim.test.ts tests/unit/web-dom-safety.test.ts → all passed; npm run typecheck exits 0.

  • [UI] Design artifact: DESIGN.md §Cadence rules 10-12 and §The current item; the recommended card variant on the 121 board.

  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD):

    1. node scripts/replay-ws.mjs --call 3339895706 --scenario onboarding --speed 20 --session m1b-107-<yyyymmdd> (published policy; no --eval-uid) → errors == 0.
    2. node scripts/presenter-sim.mjs --session <session_id>. Quote the first ≥ 2-point time and the shortest on-screen time.
    3. node scripts/design/shoot-dashboard.mjs docs/design/evidence '[["COPILOT-107-light","?call=3339895706","light",1440,900],["COPILOT-107-dark","?call=3339895706","dark",1440,900]]' --deployed --until '[data-points="2"],[data-points="3"]' exits 0.

    If 3339895706 never shows two points, steps 1-3 run on 3303259297, and the note says so.

  • INVARIANT: INV-COPILOT-009; INV-COPILOT-015; INV-COPILOT-018.

• Dependencies: COPILOT-102a, COPILOT-104a, COPILOT-105, COPILOT-105a, COPILOT-110c, COPILOT-110f, COPILOT-121

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-108a

• Title: Engine: situation hysteresis in the uncertain band, counted once per utterance [INTEGRATION-CRITICAL]

• Description: As the engine, I want a shown situation to survive one uncertain answer but leave at once on a clear miss (decision 17), so that cards do not flicker on one borderline answer.

• Acceptance Criteria:

  • src/engine/situation.ts (R5):

    • New fields. SituationFit gains shown: string | null, misses: number and miss_i: number | null, additively in src/engine/types.ts.
    • New threshold. An optional situation_fit_hard: 0.3 goes in rules-*.json. When it is absent, the M1 rule applies (§3 convention 5).
    • Counting a miss. recordFits (:172) is called twice per decision, by step() and by updatePlan, and stays idempotent. It changes misses only when miss_i !== u.i, so one decision counts at most one miss.
      • It increments misses when the shown situation's answer is in [situation_fit_hard, situation_fit), or when its question was dropped. It sets miss_i = u.i.
      • It resets misses to 0 at ≥ situation_fit.
      • Below situation_fit_hard, it clears shown at once and adds the situation id to the plan's new dropped_hard: string[] (one additive field in src/engine/plan.ts).
    • Keeping the shown situation. shownSituationId (:228) keeps shown while misses < 2, unless another candidate qualifies under like-for-like §3.3 rules 1-2.

  • docs/policy/like-for-like.md §3.3 gains the amendment: "rules 1-2 decide entering; a shown situation leaves on a second answer in [0.3, 0.6) or a second dropped question, at once under 0.3, or when another candidate qualifies (decision 17, 2026-09-27)."

  • Tests (tests/unit/engine-situations.test.ts, tests/unit/engine-fit.test.ts):

    • Through the full step() path, one answer of 0.45 counts one miss and the situation survives it.
    • A second such answer on the next decision removes it.
    • One dropped question is survived.
    • An answer of 0.05 removes it at once, with its id in dropped_hard.
    • It leaves when another candidate qualifies (fit ≥ 0.6, with the Choice agreeing).
    • With situation_fit_hard absent, M1 behaviour holds.
    • The delivery-date MUST-NOT case (like-for-like §4.1) still shows nothing.

    npx vitest run tests/unit/engine-*.test.ts → all passed; npm run typecheck exits 0.

  • [INTEGRATION-CRITICAL] Candidate and gate (§3 convention 4). After the build and the deploy (health.version == HEAD):

    1. node scripts/replay-ws.mjs --call 3339895706 --scenario onboarding --speed 20 --policy-version <N> --session m1b-108a-<yyyymmdd> --eval-uid m1b-108a-<yyyymmdd> → errors == 0, max_input_tokens ≤ 12000.
    2. Quote the count of decisions whose plan.dropped_hard is non-empty.
    3. The gate run --run m1b-hysteresis-<yyyymmdd> passes. Publish.

  • INVARIANT: INV-COPILOT-001; INV-COPILOT-003.

• Dependencies: COPILOT-106

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration (retry budget: 1, gate)

• ID: COPILOT-108b

• Title: Engine: pre-judged fits and situation choice for the item about to open, with a prejudge drop step [INTEGRATION-CRITICAL]

• Description: As the engine, I want the next item's situations judged before it opens, so that a new card opens with points instead of "Listening" (decision 3, R6).

• Acceptance Criteria:

  • Pre-judge questions. On client parts, fitsToAsk (src/engine/situation.ts:152) also asks fits:: for up to 3 situations of the item that would become current next: the ranking's leading challenger, or else the next open item. When that item has ≥ 2 candidates, it also asks the item's situation::<move> Choice, because shownSituationId needs both.

  • Seeding. retargetFit (:205) seeds the new item's fits and choice from those answers, instead of {}/null, when they were asked on the previous decision.

  • Budget. The pre-judge questions are a list of their own in planRequest, with a code-rule drop step prejudge dropped before fact_values (src/engine/budget.ts:121). The drop is recorded in budget.dropped. docs/policy/like-for-like.md §3.4 gains the pre-judge budget line.

  • Probe flag. scripts/lib/probe-flags/count-points.ts, plus one registration line in scripts/lib/probe-flags/index.ts (HOT), adds --count-points. It reconnects with load{resume:true} and prints, over hello.history:

    • decisions_with_point: decisions whose current item has ≥ 1 uncovered point;
    • items_with_point: distinct such items;
    • withdrawn_within_12s: points that leave the current item uncovered and not hard-dropped within 12 s of call time.

  • Tests.

    • tests/unit/engine-fit.test.ts: ask_about_the_transfer (situations amount_not_said and first_transfer_date_not_said) opens after a pre-judged fits::amount_not_said ≥ 0.6 and a Choice of amount_not_said at ≥ 0.4, and shows a point on its first decision.
    • tests/unit/engine-budget.test.ts: prejudge drops before fact_values.
    • npx vitest run tests/unit/engine-groups.test.ts tests/unit/policy-build.test.ts: the worst case with the pre-judge questions is ≤ 12,000 (quoted).

    npx vitest run tests/unit/engine-*.test.ts → all passed; npm run typecheck exits 0.

  • [INTEGRATION-CRITICAL] Candidate and gate. The drop step is policy data (token_budget.drop_order). After the build and the deploy:

    1. node scripts/replay-ws.mjs --call 3339895706 --scenario onboarding --speed 20 --policy-version <N> --session m1b-108b-<yyyymmdd> --eval-uid m1b-108b-<yyyymmdd> → errors == 0, max_input_tokens ≤ 12000.
    2. node scripts/ws-probe.mjs --call 3339895706 --session m1b-108b-<yyyymmdd> --resume --count-points prints decisions_with_point > 12 and items_with_point > 3 (today's 12 and 3; 20 and 5 expected), and withdrawn_within_12s. Quote all three.
    3. The gate run --run m1b-prejudge-<yyyymmdd> passes, with cost per call ≤ L6_LIMITS.cost_per_call_usd. Quote the delta against 106's run (about $0.003-0.005 expected).
    4. Publish. Append the values to docs/reports/cost-latency.md.

  • INVARIANT: INV-COPILOT-001; INV-COPILOT-006.

• Dependencies: COPILOT-108a

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration (retry budget: 1, gate)

• ID: COPILOT-120

• Title: The player status has a reserved slot: "catching up (N queued)" never moves the scrubber [INTEGRATION-CRITICAL]

• Description: As a rep, I want the player bar to stay still when the session falls behind and catches up, so that the scrubber does not jump left and right while I watch (FEEDBACK §4).

• Acceptance Criteria:

  • web/src/player.ts and its stylesheet:
    • The status text (catchingUpLabel, :71) renders in an element that is always present (data-status, aria-live="polite").
    • It sits where the 121 board recommends.
    • Its width is reserved for the longest status, so nothing else in the bar changes size or position.
  • tests/unit/web-player-status.test.ts (happy-dom): the element exists with and without a queue; only its text changes; its reserved-width class is present both ways. npx vitest run tests/unit/web-player-status.test.ts → all passed.
  • scripts/probe-player.mjs gains --check status-slot and --scheme light|dark:
    • It plays at 20× (a queue forms) and samples the scrubber's getBoundingClientRect() every 100 ms while the status changes.
    • It exits 1 if the scrubber's x or width ever differs by more than 0.5 px.
    • It prints the sample count, how many samples had the status visible (≥ 1 required), and the largest deviation.
    • --shot <file> shoots while the status is visible.
  • docs/design/DESIGN.md §Player and §States "Catching-up badge" gain the slot rule.
  • [UI] Design artifact: DESIGN.md §Top bar (the replay player) and §States; the 121 board's status question; both themes.
  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD): node scripts/probe-player.mjs --call 3303259297 --view live --check status-slot --scheme light --shot docs/design/evidence/COPILOT-120-light.png, and the same with --scheme dark --shot docs/design/evidence/COPILOT-120-dark.png. Both exit 0. This is the live view's compact bar; probe-player defaults to the review view. Quote the largest deviation.

• Dependencies: COPILOT-121

• Priority: MEDIUM

• Executor: claude:opus

• Estimate: 1 otto iteration

• Notes: The M1 player (COPILOT-046) is a completed prerequisite on main; it is not a dependency id in this plan.

#Phase C — Plan semantics and pre-call facts

#Phase C — Plan semantics and pre-call facts

• ID: COPILOT-110a

• Title: Plan grammar: policy types, builder validation, text identity and registry, and the typed readers; no policy data change

• Description: As the policy owner, I want the item-kind grammar, the new applies forms and the two new text locations (view labels and known notes) defined, validated, registered for approval and read safely, before any policy data uses them, so that a bundle with or without them builds, loads and typechecks.

• Acceptance Criteria:

  • Policy types (src/policy/types.ts; HOT, first). Every field is optional (§3 convention 5).

    • Template items gain:
      • kind: 'fact' | 'must_say' | 'judgement';
      • satisfied_by: { slots?, facts?, served_check?, rule?: 'served' };
      • surface_when: { any: [ {unknown_after_stage}, {slot_outside_served}, {source_conflict}, {signal}, {slot_in}, {stage}, {always: true} ] };
      • due: {signal} | {any: [...]};
      • texts_from: <template id>;
      • known_note: ApprovedText.
    • done_when becomes optional; it is absent on a judgement item.
    • applies gains {slot_in: {<slot>: [ids]}, or_unknown?: true, unknown_unless?: {<slot>: [ids]}} and {signal: <id>}.
    • plan.view_labels?: ApprovedText[].
    • plan.initial_template?: <template id>: the template before a purpose locks (113).

  • Builder (src/policy/build.ts):

    • It validates each new shape when present: every named signal, slot, stage, template and must-say id exists, else it throws naming the template and the item.
    • The rule at :480-481 is relaxed: not_needed_reason is required when applies is not always, and allowed when it is.

  • Text identity (assertTexts, :242):

    • An item's own texts keep the scheme plan.template.<purpose>.<item>.{title,hint,not_needed}, plus .known_note when present.
    • A field filled by texts_from: T keeps its canonical id, plan.template.T.<item>.<field>. assertTexts accepts that id for exactly the inherited fields, and only when T's item of the same id holds the identical text.
    • plan.view_labels ids must be one of plan.head.title, plan.head.subtitle, plan.known.{signup,call,demo}, plan.last_suggestion and plan.concern.raised_again.
    • The duplicate check counts an inherited text once. The same id with different content is still rejected.

  • Text registry (src/policy/text.ts). textEntries yields known_note and plan.view_labels entries (kind plan), inherited texts once. The loader's approval check (unapproved_text) and lookupText then cover them.

  • Typed readers, so the typecheck stays green in this commit:

    • src/engine/plan.ts:422 treats a missing done_when as never done.
    • web/src/review-plan.ts:423 mustSayOf skips an item without done_when.
    • The applies evaluator: planApplies (src/engine/plan.ts:136) today narrows when_slot, then passes the rest to checklistApplies. It handles slot_in (with or_unknown and unknown_unless) and signal before that call, and the hero rule (src/engine/hero.ts:40) accepts the widened union.
    • SessionState.signals_seen: Record<string, number> records the first i at which each signal was ≥ signal_on on a client turn. A checkpoint without it reads as {}.

  • Tests.

    • tests/unit/policy-plan.test.ts: each invalid shape is rejected, naming the item; texts_from fills only the missing fields and keeps canonical ids; the real mapping (the walkthrough's explain_who_holds_the_money inheriting the first-call title and hint) builds.
    • tests/unit/policy-build.test.ts: a .known_note on a fact item builds; the committed fixtures build byte-identically.
    • tests/unit/policy-loader.test.ts: a draft view_labels entry and a draft known_note are rejected (unapproved_text).
    • tests/unit/rep-facing-text.test.ts: approved ones resolve through lookupText.
    • tests/unit/web-review-plan.test.ts: a judgement item without done_when renders without error.
    • tests/unit/engine-hero.test.ts: each new applies form holds and fails as specified.
    • tests/unit/engine-step.test.ts: signals_seen is recorded, and an old checkpoint rehydrates.

    npx vitest run tests/unit/policy-plan.test.ts tests/unit/policy-build.test.ts tests/unit/policy-loader.test.ts tests/unit/rep-facing-text.test.ts tests/unit/engine-plan.test.ts tests/unit/engine-hero.test.ts tests/unit/engine-step.test.ts tests/unit/web-review-plan.test.ts → all passed; npm run typecheck exits 0.

  • SAFETY: policy/src is unchanged (git diff --exit-code policy/src); no candidate, no deploy.

  • INVARIANT: INV-COPILOT-003; INV-COPILOT-015; INV-COPILOT-001.

• Dependencies: none

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-110f

• Title: The M1b wire contract types and the --known probe [INTEGRATION-CRITICAL]

• Description: As the engine and the probes, I want the new grammar read safely and the new wire fields defined before any policy data or view uses them, so that every later story can deploy without breaking the published bundle.

• Acceptance Criteria:

  • Contract types (src/engine/types.ts, src/session/protocol.ts; HOT, additive and optional):

    • CallPlan.known, CallPlan.must_says and CallPlan.dropped_hard;
    • PlanItem.due_by: 'client';
    • FactValue.source and FactChip.source, over 'signup' | 'crm' | 'demo' | 'call';
    • FactValue.replaced: {value, source}.

    FactChip.at stays non-null. A seeded chip's at is {i: -1, t: 0} (113), and 114b renders no link for it.

  • Probe flag. scripts/lib/probe-flags/known.ts, plus one registration line in scripts/lib/probe-flags/index.ts (HOT), adds --known. It reconnects with load{resume:true} and prints, per decision of hello.history: the chips' slots and sources, the plan.known ids, and any known id also in plan.items.

  • Tests.

    • tests/unit/session-protocol.test.ts: the new optional fields round-trip, and a decision without them still parses.
    • The committed fixtures give plans deep-equal to today's.

    npx vitest run tests/unit/session-protocol.test.ts tests/unit/engine-plan.test.ts tests/unit/engine-purity.test.ts → all passed; npm run typecheck exits 0.

  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD):

    1. node scripts/replay-ws.mjs --call 3303259297 --scenario customer_success --speed 20 --session m1b-110f-<yyyymmdd> → errors == 0, with decisions unchanged in shape.
    2. node scripts/ws-probe.mjs --call 3303259297 --session m1b-110f-<yyyymmdd> --resume --known prints chips with source call and an empty plan.known. Quote it.

  • INVARIANT: INV-COPILOT-001; INV-COPILOT-005.

• Dependencies: COPILOT-110a

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-110g

• Title: Generators and eval tooling read the new grammar: the red-pen sheet, the labels sheet, and L4's retired ids

• Description: As the policy owner, I want the red-pen and labels sheets to describe kinds, the new applies forms, items without done_when, known notes and view labels, and L4 to tolerate checklist ids the policy retires, so that regeneration and the gate keep working once 110d converts the data.

• Acceptance Criteria:

  • Red-pen sheet (scripts/redpen.mjs):

    • describeApplies (:61) describes slot_in (with or_unknown and unknown_unless) and signal.
    • describeDone (:80) handles a missing done_when ("a judgement call: not ticked"), and the sheet gains a kind column.
    • Before rendering, it resolves the source through the builder's own helpers, exported from src/policy/build.ts:
      • resolveTextsFrom fills inherited titles and hints, since :108 reads item.title.text;
      • deriveChecklist (110h) replaces checklist: "derived", since :285 calls checklist.map.
    • It still throws on a truly unknown form.

  • Labels sheet (scripts/labels-sheet.mjs) lists known_note and plan.view_labels texts with their approval state.

  • L4. scripts/lib/eval-l4.ts partitions eval/labelled/must-say.json against the evaluated checklist. A labelled id the policy no longer checks is reported under retired, left out of recall and precision, and never exits 2. must-say.json is not edited.

  • Tests.

    • tests/unit/redpen.test.ts (new) renders a fixture clone converted to 110d's real shapes: every new applies form, a judgement item without done_when, the walkthrough item with texts_from and no own title, and checklist: "derived". It asserts the inherited title and the derived checklist ids appear. An unknown form throws.
    • tests/unit/eval-l4l6.test.ts: a retired id.
    • node scripts/redpen.mjs --check and node scripts/labels-sheet.mjs --check still exit 0 on the committed sources.

    npx vitest run tests/unit/redpen.test.ts tests/unit/eval-l4l6.test.ts → all passed.

• Dependencies: COPILOT-110a, COPILOT-110h

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-110h

• Title: The derived must-say checklist per template, opt-in, and the hero reading it

• Description: As the policy owner, I want the must-say checklist derived from each template's must-say items instead of a hand list, so that the checklist and the plan cannot drift. The derivation is opt-in per bundle, so no policy data changes here.

• Acceptance Criteria:

  • Opt-in. src/policy/build.ts: with checklist: "derived" in rules-*.json, the builder derives checklist_by_template[template]: that template's items with kind: must_say (or, without kinds, a done_when must-say), with their applies, plus rate_pressure_handled. The bundle's checklist is the union by id. Without "derived", the hand list is used, as today.

  • Hero. src/engine/hero.ts reads checklist_by_template for the plan's current template (templateFor, including 113's initial template) when present, else checklist.

  • Hash ownership and validation.

    • src/policy/canonical.ts HASH_FIELDS.weights gains checklist_by_template.
    • The loader (src/policy/loader.ts) validates it: every key is a template id; every entry is a must-say of that template, or is rate_pressure_handled, the one scenario-wide entry the derivation adds to every template with its applicability (when_fact: rate_pressure_raised) and completion rules unchanged; and the union equals checklist.
    • deriveChecklist is exported for 110g.

  • Tests.

    • tests/unit/policy-build.test.ts uses a fixture clone with "derived": it yields per-template entries and their union, and bank_hash and playbook_hash are unchanged.
    • tests/unit/engine-hero.test.ts: the hero reads the current template's entries; an old bundle reads checklist.
    • tests/unit/policy-loader.test.ts and tests/unit/policy-canonical.test.ts: mutating checklist_by_template changes weights_hash; a bundle whose stored hash was not recomputed is refused (hash_mismatch); an entry that is not a must-say of its template (other than rate_pressure_handled), or a union that differs from checklist, is refused. A real derived bundle, built from a converted fixture clone with rate_pressure_handled, passes both the builder and the loader.

    npx vitest run tests/unit/policy-build.test.ts tests/unit/engine-hero.test.ts tests/unit/policy-loader.test.ts tests/unit/policy-canonical.test.ts → all passed; npm run typecheck exits 0.

  • SAFETY: policy/src unchanged.

  • INVARIANT: INV-COPILOT-001; INV-COPILOT-002.

• Dependencies: COPILOT-110a, COPILOT-110f

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-110c

• Title: Apply Stevan's approved 2026-09-27 wording to policy/src; drafts and homeless entries are skipped and reported [INTEGRATION-CRITICAL]

• Description: As the policy owner, I want the titles, hints, notes and new labels that Stevan approved as drafted (decision 2f; policy/proposals/2026-09-27.json) applied in one step, so that the guide reads in his words and no unapproved text enters a build.

• Acceptance Criteria:

  • The tool. scripts/apply-label-approvals.mjs <file> reads the proposals format: {source, decision, applies_to, texts[]}, where each text has text_id, text, status, approved_by and approved_at.

    • It first classifies every entry:
      • invalid: malformed, an approver not in policy/approvers.json, or an id with no known home. Any invalid entry makes it exit 1, write nothing, and name them.
      • draft: status other than approved. Reported as skipped (draft) and never applied.
      • deferred: approved, but its home is created by a later step. The known deferred homes are plan.fact.bank_country.template until 110b adds the slot, and situation.address_ties_me_to_tax_residency.* until its point is approved (decision 13). Reported as deferred; not an error.
      • applicable: everything else.
    • It then writes every applicable entry. A re-run is idempotent, and applies deferred entries whose home now exists.
    • --dry-run prints the classification and the diff.

  • Homes.

    • An existing title or hint id is reworded and stamped from the entry.
    • …<item>.known_note on a fact item becomes its known_note, under the same id (110a registers it).
    • On a must-say item it becomes the not_needed_reason, under the id the builder requires, plan.template.<purpose>.<item>.not_needed: an existing reason is reworded, and a missing one is created. The text, status, approved_by and approved_at are copied from the entry. The id mapping (known_note → not_needed) is printed, and recorded on policy/LABELS.md.
    • 110a allows a reason while applies is always.
    • plan.head.title, plan.head.subtitle, plan.known.{signup,call,demo}, plan.last_suggestion and plan.concern.raised_again join plan.view_labels in both plan files.
    • plan.fact.bank_country.template has no home until 110b adds the slot.
    • situation.address_ties_me_to_tax_residency.{headline,hint} has no home while the situation's point is a draft: assertSituations requires core_text_id among its points (src/policy/build.ts:587). Its draft .point is skipped [DECISION 13].

  • Test. tests/unit/label-approvals.test.ts builds files inline on a temporary copy of policy/src, and covers:

    • each home, including both known_note mappings (a fact's own id; a must-say's .not_needed id);
    • the real mix of approved and draft entries (the draft reported, never applied);
    • a deferred entry reported, then applied on a re-run once its home exists;
    • an unknown id → invalid → exit 1 with nothing written;
    • an approver outside the allowlist, which exits 1 and writes nothing.

  • Apply the real file. Run node scripts/apply-label-approvals.mjs policy/proposals/2026-09-27.json. It exits 0 and prints the [VERIFY] point as a draft, and the two situation texts and the bank-country template as deferred. Then run node scripts/labels-sheet.mjs and node scripts/redpen.mjs.

    • node scripts/labels-sheet.mjs --check exits 0, and grep -c "Known from sign-up" policy/LABELS.md counts the two applied fact notes. tests/unit/label-approvals.test.ts asserts that the regenerated sheet lists every applied known_note and view label.
    • grep -rn "address_ties_me_to_tax_residency" policy/src prints nothing.
    • Fixtures and stubs are regenerated.

    npx vitest run tests/unit/label-approvals.test.ts tests/unit/policy-approved.test.ts tests/unit/policy-drafts.test.ts tests/unit/rep-facing-text.test.ts tests/unit/policy-build.test.ts → all passed.

  • [INTEGRATION-CRITICAL] Candidate and gate --run m1b-wording-<yyyymmdd> (the weights and playbook hashes change): L1 ≥ 90 % for both, L4 PASS, L6 PASS, evaluated=true. Publish.

  • SAFETY: the story never edits policy/proposals/2026-09-27.json or policy/approvals/*, and never sets approved_by; every stamp comes from Stevan's file.

  • INVARIANT: INV-COPILOT-015; INV-COPILOT-003.

• Dependencies: COPILOT-110a, COPILOT-110g, COPILOT-118a

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration (retry budget: 1, gate)

• Notes: First in the policy chain; 118a's wall-clock pacing lands before any gate. The coordinator asked for everything but the [VERIFY] line to be applied. The situation's approved headline and hint cannot enter without a point, so they wait with it (§7 Q2).

• ID: COPILOT-110d

• Title: Typed templates: every item gets its kind and its rules (decisions 2c, 2d, 2e), and the checklist switches to derived [INTEGRATION-CRITICAL]

• Description: As the policy owner, I want every plan item typed as a fact, a must-say or a judgement call, with Stevan's rules, and the must-say checklist derived from the must-say items, so that the plan can be a guide and the two lists cannot drift. No wording changes here.

• Acceptance Criteria:

  • The ten first_call_after_signup items (policy/src/plan-onboarding.json; kinds from FEEDBACK §2d):

    Item	Kind	Rule
    open_with_agenda	judgement	surface_when {stage: opening}
    understand_the_transfer	fact	slots [transfer_purpose, amount, frequency]; surface_when any of {unknown_after_stage: discovery}, {source_conflict: transfer_purpose}, {source_conflict: amount}, {source_conflict: frequency}
    check_serviceability_first	fact	slots [residency], rule: served; surface_when any of {slot_outside_served: residency}, {unknown_after_stage: discovery}, {source_conflict: residency}
    confirm_funding_account	must_say	applies {slot_in: {funding_account: [third_party, company_account]}, or_unknown: true, unknown_unless: {transfer_purpose: [salary_or_pension]}} (decision 2d; §7 Q5); due {signal: client_ready_to_book}
    explain_who_holds_the_money	must_say	applies {signal: client_asked_about_safety}, due {signal: client_asked_about_safety}: never listed on a first call where safety is not raised (decision 2c)
    explain_settlement_and_cutoff	judgement	surface_when any of {slot_in: {timing: [this_week, this_month]}}, {signal: client_asked_about_timing}; no done_when
    explain_booking_is_binding	must_say	applies always, due {signal: client_ready_to_book}
    close_the_document_gap	must_say	applies unchanged
    minimum_transfer	must_say	applies {when_amount_below_gbp: 5000}, unchanged: per relationship, not per leg (decision 2e)
    agree_next_step	fact	facts [next_step_agreed]

    The not_needed_reason of the must-says comes from 110c's approved notes.

  • The same rules in every template.

    • confirm_funding_account carries decision 2d's rule wherever it appears. The walkthrough item's missing not_needed_reason comes through texts_from: first_call_after_signup, under 110a's identity rule.

    • first_transfer_walkthrough gains explain_who_holds_the_money (decision 2c): texts_from: first_call_after_signup, applies always, and due on client_asked_about_safety or client_ready_to_book.

    • explain_settlement_and_cutoff is judgement in every template.

    • Every other item, across both plan files, takes the kind its done_when implies:

      • a must_say gives must_say, with applies unchanged;
      • slots or facts only give fact, with satisfied_by derived from those conditions;
      • delivered only gives judgement with surface_when {always: true}. Its applies is kept (customer success add_user_access and explain_document_request stay conditional), and 111a requires both.

      The progress note lists every item with its kind and predicates.

  • Initial template. plan-onboarding.json gains initial_template: first_call_after_signup. It takes effect once 113's reader lands, and until then it is ignored (§3 convention 5).

  • The derived checklist. rules-onboarding.json and rules-customer-success.json switch to checklist: "derived" (110h).

    • The onboarding union becomes said_who_holds_funds, said_fund_from_own_account, said_booking_is_binding, said_minimum, said_docs_needed and rate_pressure_handled.
    • These leave it: said_rate_transparency, said_quote_lifetime, said_settlement_timing, said_payment_reason, said_rm_contact and said_recording_disclosure. Their questions stay in the bank.
    • The customer-success union is quoted.
    • tests/unit/policy-build.test.ts asserts that bank_hash and playbook_hash are unchanged.

  • Tests. Fixtures, stubs, policy/REDPEN.md and policy/LABELS.md are regenerated with 110g's generators.

    • tests/unit/engine-hero.test.ts:
      • who-holds is not applicable on a first call before the safety signal, and applicable on the walkthrough;
      • confirm_funding_account does not apply with a salary purpose and an unknown funding account, on both templates;
      • it applies with third_party;
      • minimum_transfer does not apply with NZD 25,000 and CAD 5,000 held.
    • tests/unit/policy-plan.test.ts: every mapped fact has a non-empty satisfied_by, and every mapped judgement keeps its source applies.

    npx vitest run tests/unit/policy-plan.test.ts tests/unit/policy-build.test.ts tests/unit/policy-src.test.ts tests/unit/policy-approved.test.ts tests/unit/engine-hero.test.ts tests/unit/eval-l4l6.test.ts → all passed; node scripts/redpen.mjs --check, npx vitest run tests/unit and npm run typecheck exit 0.

  • [INTEGRATION-CRITICAL] Candidate and gate --run m1b-kinds-<yyyymmdd>: L1 ≥ 90 % for both, L4: PASS with retired quoted, L6 PASS, evaluated=true. Publish.

  • SAFETY: no text changes; 110c applied the wording.

  • INVARIANT: INV-COPILOT-016; INV-COPILOT-013; INV-COPILOT-003.

• Dependencies: COPILOT-110c, COPILOT-110f, COPILOT-110g, COPILOT-110h

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration (retry budget: 1, gate)

• Notes: 110f's readers deploy before this data (§3 convention 5).

• ID: COPILOT-110b

• Title: The bank_country slot, its approved chip template, and the served-country list (a bank change) [INTEGRATION-CRITICAL]

• Description: As the engine, I want to know the country of the bank the client names, and which countries the partners serve, so that "Where they live and bank" is satisfied from the call and surfaced only when a country is off the served list.

• Acceptance Criteria:

  • Slot grammar (code):

    • src/policy/fact-slots.ts adds bank_country to the slot ids as an optional slot; a bundle without it is valid.
    • The builder accepts a country span slot with a template whose {country} param is a country id rendered through fact_lists.countries[].display (as situation points render {country}), instead of per-country labels.
    • Its candidate trigger is \b(bank|banks|banking)\b over the gazetteer.
    • parsePrecall (112) accepts bank_country as a country id when the policy has the slot.
    • web/src/render.ts templateText (:71) renders a chip template's {country} param through fact_lists.countries[].display, as its point branch does (:87). web/src/chips.ts (HOT, first) gives each chip data-slot.
    • docs/design/DESIGN.md §Client facts chips adds the slot ("Banks in Saudi Arabia", in the transfer group after residency).

  • Data.

    • policy/src/plan-onboarding.json fact_slots gains bank_country: source {kind: span, question: span_bank_country, over: countries}, with no known_fact, as residency has none.
    • policy/src/onboarding.json gains span_bank_country: "Which place is the country of the bank the client uses? …". It is Jev-facing, so it needs no red-pen.
    • fact_lists.served_countries: [] is added (under bank_hash, empty until supplied; §7 Q3).
    • check_serviceability_first.satisfied_by.served_check becomes [residency, bank_country], and its surface_when gains {slot_outside_served: bank_country}.
    • Re-run node scripts/apply-label-approvals.mjs policy/proposals/2026-09-27.json. The approved plan.fact.bank_country.template ("Banks in {country}") now finds its home, and the other entries are no-ops.

  • Tests.

    • tests/unit/policy-build.test.ts: an old bundle (no slot) builds and loads; the customer-success bundle is unaffected.
    • tests/unit/engine-plan.test.ts: an empty list, and ['GB'] with residency or bank country SA (the card surfaces).
    • tests/unit/engine-fact-values.test.ts: the slot, and its chip as a typed template.
    • tests/unit/web-chips.test.ts: the chip renders "Banks in Saudi Arabia".
    • tests/unit/precall.test.ts: a round trip with bank_country: 'SA'.

    npx vitest run tests/unit/policy-build.test.ts tests/unit/engine-plan.test.ts tests/unit/engine-fact-values.test.ts tests/unit/precall.test.ts tests/unit/web-chips.test.ts → all passed.

  • [UI] Design artifact: DESIGN.md §Client facts chips.

  • [INTEGRATION-CRITICAL] Candidate and gate. Deploy before the upload (§3 convention 4):

    1. node scripts/probe-questions.mjs --call 3339895706 --at 38 --planned (the draft bank) plans span_bank_country and answers the Saudi candidate at ≥ 0.6. Quote it.
    2. The gate run --run m1b-bank-country-<yyyymmdd>: L1 onboarding and cs ≥ 90 %. Publish.
    3. On the published policy, node scripts/design/shoot-dashboard.mjs docs/design/evidence '[["COPILOT-110b-light","?call=3339895706","light",1440,900],["COPILOT-110b-dark","?call=3339895706","dark",1440,900]]' --deployed --until '[data-slot="bank_country"]' exits 0.

  • INVARIANT: INV-COPILOT-015; INV-COPILOT-016; INV-COPILOT-020.

• Dependencies: COPILOT-102a, COPILOT-108b, COPILOT-110d, COPILOT-111a, COPILOT-112

• Priority: MEDIUM

• Executor: claude:opus

• Estimate: 1 otto iteration (retry budget: 1, gate)

• Notes: 111a implements the served rule that the tests exercise; 108b is the policy-chain order.

• ID: COPILOT-110e

• Title: L1 can check an engine fact value from a span question; the bank-country case [INTEGRATION-CRITICAL]

• Description: As the policy owner, I want an L1 case to pin a fact the engine derives from a span Choice, so that "Saudi National Bank" giving a bank country of SA is part of the gate.

• Acceptance Criteria:

  • The check. scripts/lib/eval-l1.ts gains the engine check fact_value: {slot, value}. It runs step() on the case's answers and compares the slot's value. When a case names a span slot, the L1 request includes that slot's span Choice, built from the case's window candidates as probe-questions --questions span_<slot> builds it. eval/schema.json and scripts/lib/eval-cases.ts accept the check. tests/unit/eval-l1.test.ts covers a pass and a fail.
  • The case. eval/labelled/onboarding.json gains ob_3339895706_i38_bank_country: context v1 lines 34-37 and latest line 38 ("Which is Saudi National Bank."), verbatim from the v1 fixture, checking fact_value {slot: bank_country, value: SA}. npx vitest run tests/unit/eval-l1.test.ts tests/unit/eval-cases.test.ts → all passed.
  • [INTEGRATION-CRITICAL] On the deployed Worker (health.version == HEAD), with the published version from 110b: node scripts/eval.mjs --scenario onboarding --layers l1 --run m1b-fact-value-<yyyymmdd> passes the new case (its answer quoted), with L1 onboarding ≥ 90 %.
  • INVARIANT: INV-COPILOT-004 (the case text passes the production redactor).

• Dependencies: COPILOT-110b

• Priority: MEDIUM

• Executor: claude:opus

• Estimate: 1 otto iteration (retry budget: 1, eval)

• ID: COPILOT-111a

• Title: Engine: fact and judgement semantics, silent facts, plan.known, chips with their source [INTEGRATION-CRITICAL]

• Description: As the engine, I want facts to tick silently from any source into a known list with their source, and judgement items to exist only while triggered, so that the live list holds only what helps right now.

• Acceptance Criteria:

  • src/engine/plan.ts (HOT, after 117), for items with a kind; others behave as in M1.

    • fact.
      • Satisfied when every satisfied_by.slots slot is known (a call value at ≥ fact_value_min_conf, or a seeded value at i=-1), every satisfied_by.facts fact is held, and, for rule: served, every known served_check slot is on the served list. An empty or absent list passes.
      • A satisfied fact item is not in items. It goes into plan.known: {id, source, at: {i, t} | null}[], where source comes from the slot that completed it and at is null at i=-1.
      • An unsatisfied fact item has no row.
      • A fact item is the current card only while a surface_when clause holds. While surfaced it leaves plan.known and is in items as current. When the clause stops holding, its satisfaction is evaluated again: it returns to known only if satisfied_by holds, else it has no row. The probe below therefore holds even for a surfaced fact.
        • unknown_after_stage: stage.current is known (non-null, and not none) and is neither opening nor the named stage, and a slot is still unknown;
        • slot_outside_served: a known slot is not on a non-empty served list;
        • source_conflict: the slot's FactValue.conflict is true (set and cleared by 113).
    • judgement. No row until both its applies and its surface_when hold. It then competes for the current card under the existing challenger rules. It is never done or not_needed, and it leaves when either stops holding.
    • One card. A surfaced fact or judgement is a candidate in the existing ranking, never current by fiat. The existing rules (a challenger leads for two decisions; at most one change of the current item per decision) keep exactly one current item. Among several surfaced candidates the earliest in template order ranks first; the others stay hidden until it resolves.
    • Neither kind counts in the hero.

  • factChips (src/engine/fact-values.ts:381) passes FactValue.source through (absent means call).

  • Tests. tests/unit/engine-plan.test.ts on the v1 fixture of 3339895706, with its stub answers and 110d's policy fixture:

    • open_with_agenda shows no row once the stage has left opening;
    • check_serviceability_first is in known (source call) from the decision where residency becomes known, and never in items unless surfaced;
    • explain_settlement_and_cutoff has no row until its trigger fires;
    • a synthetic state with conflict set surfaces check_serviceability_first, which is then not in known;
    • facts never change the hero's completeness;
    • in the initial state (stage.current null), and after a none stage answer, no fact surfaces on unknown_after_stage;
    • with understand_the_transfer and check_serviceability_first both surfaced, exactly one item is current on every decision;
    • customer success add_user_access (a judgement with applies on decision_maker) has no row while decision_maker is caller, and explain_document_request none while documents are complete;
    • an unsatisfied mapped fact (customer success review_upcoming_exposure, from 110d's derived satisfied_by) has no row and is not in known until its conditions hold;
    • a composite fact (understand_the_transfer) that surfaced on a conflict, and whose conflict then clears while frequency is still unknown, returns to no row, not to known.

    npx vitest run tests/unit/engine-plan.test.ts tests/unit/session-protocol.test.ts tests/unit/engine-purity.test.ts tests/unit/engine-recompute.test.ts → all passed; npm run typecheck exits 0.

  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD, with 110d's published kinds):

    1. node scripts/replay-ws.mjs --call 3339895706 --scenario onboarding --speed 20 --session m1b-111a-<yyyymmdd> → errors == 0.
    2. node scripts/ws-probe.mjs --call 3339895706 --session m1b-111a-<yyyymmdd> --resume --known shows no decision with a known id that is also in plan.items. Quote it.

  • INVARIANT: INV-COPILOT-016; INV-COPILOT-001.

• Dependencies: COPILOT-110d, COPILOT-117

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• Notes: 117 is the hot-file order for src/engine/plan.ts.

• ID: COPILOT-111b

• Title: Engine: must-say applies and due, no not-needed rows in the live plan, the must-say record for the review [INTEGRATION-CRITICAL]

• Description: As the engine, I want must-says listed only while they apply and surfaced when due, and the live plan free of not-needed rows, so that the live list is a guide and the review keeps the score.

• Acceptance Criteria:

  • src/engine/plan.ts:

    • A must_say item is in items only while its applies holds. It is later until its due fires (with no due, it is due once it applies), and it may then become current.
    • When due fired on a client signal, the item carries due_by: 'client', which 107's presenter inserts without the dwell.
    • The live decision.plan.items holds no not_needed item.
    • plan.must_says: {id, applies, why, applied_at, due_at, due_by, said_at}[] covers every must-say item of the plan's template, with {i, t} times. why is the rule kind: always, signal, slot_in, when_amount_below_gbp or when_slot. applies is the value at this decision.
    • due_at is null while the item's due has not fired. An applying must-say whose due never fires (for example booking-is-binding on a call with no client_ready_to_book) ends the call with due_at: null.

  • Tests. tests/unit/engine-plan.test.ts on the v1 fixture of 3339895706, with the stub answers and these overrides (listed in the test): said_docs_needed 0.9 at i=46, said_booking_is_binding 0.9 at i=89, client_asked_about_safety 0.9 at i=107 (08:50), and fact_transfer_purpose salary_or_pension at i=71.

    • At the last decision the live items has ≤ 4 open rows and no not_needed.
    • explain_who_holds_the_money first applies, and becomes due, at i=107 with due_by: 'client' (decision 2c).
    • confirm_funding_account does not apply at the end (decision 2d).
    • minimum_transfer does not apply (decision 2e).
    • must_says ends with 3 applying, 2 of them said.
    • On a synthetic call with no client_ready_to_book and nothing said, explain_booking_is_binding ends with applies: true, due_at: null.

    tests/unit/web-presenter.test.ts: the who-holds item opens without waiting out the dwell. npx vitest run tests/unit/engine-plan.test.ts tests/unit/engine-hero.test.ts tests/unit/web-presenter.test.ts tests/unit/session-protocol.test.ts → all passed; npm run typecheck exits 0.

  • [UI] Design artifact: DESIGN.md §Cadence rules rule 2 (drawn by 107) and §The current item.

  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD):

    1. node scripts/replay-ws.mjs --call 3339895706 --scenario onboarding --speed 20 --session m1b-111b-<yyyymmdd> → errors == 0.
    2. node scripts/with-cf-env.mjs npx wrangler d1 execute copilot --remote --command "SELECT COUNT(*) AS n FROM decisions d, json_each(json_extract(d.decision_json,'$.plan.items')) e WHERE d.session_id = '<session_id>' AND json_extract(e.value,'$.state') = 'not_needed'" → n: 0. Quote the last decision's plan.must_says.
    3. node scripts/design/shoot-dashboard.mjs docs/design/evidence '[["COPILOT-111b-light","?call=3339895706","light",1440,900],["COPILOT-111b-dark","?call=3339895706","dark",1440,900]]' --deployed --until '[data-id="explain_who_holds_the_money"][aria-current="step"]' exits 0.

    If the item never opened, the story quotes client_asked_about_safety at the parts around 08:50 and stays passes:false: decision 2c is then not met live.

  • INVARIANT: INV-COPILOT-016; INV-COPILOT-001.

• Dependencies: COPILOT-107, COPILOT-111a

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration (retry budget: 1, Jev-dependent probe)

• ID: COPILOT-111c

• Title: Amounts: a mid-call correction replaces the amount, a second currency leg is kept, and the minimum stays per relationship (decision 2e) [INTEGRATION-CRITICAL]

• Description: As the engine, I want "fifty thousand, actually fifteen hundred" read as one corrected amount, and a second currency leg read as a second amount, so that the minimum rule (per client relationship, not per leg) is neither cleared by a figure the client took back nor re-opened by a small second leg.

• Acceptance Criteria:

  • Amount history (src/engine/amount.ts, src/engine/types.ts; HOT). SessionState gains amount_history: {gbp, code, digits, i, superseded_by?}[] next to today's amounts: number[], which is kept and derived as the GBP of the non-superseded entries, so old checkpoints read as before.

    • recordAmounts (:362) appends each client amount (and each client-confirmed rep amount) with its currency.
    • An amount without a currency takes the currency of the amount it corrects.
    • A client amount in the same currency as the latest held one supersedes it when stated in the same client run, or in the next client run, with a correction marker ("actually", "I mean", "sorry", "no,", "rather", "correction"). A client run is the conversational unit: consecutive client turn parts, skipping backchannels and acks, as 105's isClientRunEnd defines it. It is never a single v2 part.
    • With a correction marker, a new client amount supersedes the latest held amount whatever its currency, in the same client run or the next one. "Fifty thousand euros, sorry, I meant fifteen hundred dollars" leaves USD 1,500 only.
    • Without a marker, a different currency is a second leg and is kept, and a same-currency amount in a later run is kept (a second transfer).
    • The rule is written at the top of src/engine/amount.ts: a marker means a correction; no marker means an addition.
    • A seeded entry (113, i=-1) is superseded by the first call amount in its currency, at any distance and without a marker: the call's own figure replaces sign-up's. Call-to-call supersession follows the correction rule above.

  • Reconcile with the fact. clientAmountsGbp (:385) reads the non-superseded history, plus the amount fact value only when it matches a non-superseded entry or no history exists. When the amount span question was dropped by the budget, the history still holds the text amounts.

  • Unchanged. when_amount_below_gbp (src/engine/hero.ts:40): any client amount at or above the threshold clears the minimum. There is no per-leg rule and no batching line.

  • Tests. tests/unit/engine-features.test.ts (the extractAmounts block) and tests/unit/engine-hero.test.ts:

    • "fifty thousand euros, actually fifteen hundred" holds EUR 1,500 only, so the minimum applies;
    • "fifty thousand euros, sorry, I meant fifteen hundred dollars" holds USD 1,500 only, so the minimum applies;
    • "fifty thousand euros and about five thousand Canadian a month" (no marker) holds both;
    • v1 i=13 (NZD 30,000) then i=33 ("about 5,000 Canadian every month") holds both, so the minimum is not needed;
    • a later same-currency amount without a marker is kept;
    • a seeded NZD 25,000, followed several turns later by the call's "about 2,000 NZD", supersedes the seed, so the minimum applies;
    • a dropped span answer is covered;
    • an old checkpoint with amounts but no amount_history migrates on first read: each legacy GBP value becomes an entry with code: null, kept and never superseded. Rehydrate it, append another transfer, and the minimum is still evaluated over both;
    • a correction spanning three v2 parts of one client run supersedes;
    • the 058d cases pass.

    npx vitest run tests/unit/engine-features.test.ts tests/unit/engine-hero.test.ts tests/unit/engine-fact-values.test.ts tests/unit/engine-state.test.ts → all passed.

  • [INTEGRATION-CRITICAL] Live probe on the deployed Worker (health.version == HEAD): node scripts/replay-ws.mjs --call 3339895706 --scenario onboarding --speed 20 --session m1b-111c-<yyyymmdd> → errors == 0. The last decision's plan.must_says entry for minimum_transfer reads applies: false after the 02:41 CAD leg. Quote it.

  • INVARIANT: INV-COPILOT-001; INV-COPILOT-002.

• Dependencies: COPILOT-111b

• Priority: MEDIUM

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-112

• Title: Pre-call facts: the 0004_precall.sql migration file, closed-vocabulary validation and the demo payload tool

• Description: As Stevan, I want the shape of pre-call facts fixed and validated in one place, so that every write path accepts only closed-list values with their source, and the demo seed is generated rather than hand-typed (decision 2a).

• Acceptance Criteria:

  • Migration file. migrations/0004_precall.sql (0001-0003 exist) is ALTER TABLE calls ADD COLUMN precall_json TEXT; ALTER TABLE sessions ADD COLUMN precall_json TEXT;. tests/workers/migrations.test.ts applies it in miniflare and lists both columns.

  • Validation. src/ingest/precall.ts parsePrecall(json, policy): Precall:

    • A key is accepted only when it is a fact slot of the pinned onboarding policy with a closed label list: client_type, residency, transfer_purpose, frequency, documents_status, current_provider, funding_account, timing, and bank_country as a country id from fact_lists.countries when the pinned policy has that slot (110b).
    • Its value must be one of that slot's label ids.
    • Also accepted: currency_pair as two ISO 4217 codes from fact_lists.currencies, and amount as {digits, code}.
    • source in {signup, crm, demo} is required.
    • Anything else raises invalid_precall naming the field. There is no free-text field.

  • Import payload. scripts/lib/import-payload.schema.json and src/ingest/import-payload.ts gain an optional precall, validated by parsePrecall.

  • Demo payload tool. scripts/precall-payload.mjs --call <id> --source demo prints the demo payload from a table keyed by call id, validated against policy/src. For 3339895706 it is {"source":"demo","client_type":"personal","residency":"SA","currency_pair":["SAR","NZD"],"transfer_purpose":"salary_or_pension","frequency":"monthly","documents_status":"proof_of_address_outstanding","amount":{"digits":"25000","code":"NZD"}}: the call's own values, with the amount at the low end of line 13's 25-30k NZD. Its pd_ct_id is NULL, hence demo.

  • Tests.

    • tests/unit/precall.test.ts: every key, and "transfer_purpose":"salary" → invalid_precall.
    • tests/unit/pseudonymised.test.ts: a name-shaped string in any field is rejected.

    npx vitest run tests/unit/precall.test.ts tests/unit/pseudonymised.test.ts and npx vitest run -c vitest.workers.config.ts tests/workers/migrations.test.ts → all passed; npm run typecheck exits 0.

  • INVARIANT: INV-COPILOT-020; INV-COPILOT-004.

• Dependencies: none

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-112b

• Title: Pre-call facts: the write paths (a service-token PUT and the import field), provenance on every path, preservation on replacement, the migration applied, the demo seed written [INTEGRATION-CRITICAL]

• Description: As Stevan, I want pre-call facts written only by trusted callers with an honest source, and kept when a transcript is replaced, so that the demo seed and the future sign-up join cannot be spoofed or silently lost.

• Acceptance Criteria:

  • PUT route. src/routes/precall.ts adds PUT /api/calls/:id/precall, registered by one dispatch line in src/index.ts (HOT). It takes the service token only (an email actor gets 403), accepts source demo or crm only (signup gets 422, reserved for the M2 join), and is audited call.precall_set.

  • Import path (src/routes/calls-import.ts; HOT, after 104b), same rules:

    • A payload precall is accepted only from the service token (an email actor gets 403), and only with source demo or crm.
    • A forced replacement without precall keeps the stored value (COALESCE); one with it replaces it.

  • Tests. tests/workers/precall.test.ts covers:

    • a PUT, then a forced transcript replacement without precall, leaving calls.precall_json unchanged;
    • signup refused on both paths;
    • an email actor refused on both paths;
    • "residency":"Narnia" → 400 naming residency;
    • the audit row.

    npx vitest run -c vitest.workers.config.ts tests/workers/precall.test.ts tests/workers/calls-import.test.ts → all passed.

  • [INTEGRATION-CRITICAL] Live probe:

    1. node scripts/with-cf-env.mjs npx wrangler d1 migrations apply copilot --remote applies 0004_precall.sql.
    2. Deploy (health.version == HEAD).
    3. In one shell, set -a; . ~/.config/jev/cloudflare.env; set +a, then curl -s -X PUT "$WORKER_URL/api/calls/3339895706/precall" -H "CF-Access-Client-Id: $CF_ACCESS_CLIENT_ID" -H "CF-Access-Client-Secret: $CF_ACCESS_CLIENT_SECRET" --data "$(node scripts/precall-payload.mjs --call 3339895706 --source demo)" → 200.
    4. The same with "residency":"Narnia" → 400, and with "source":"signup" → 422.
    5. Quote SELECT precall_json FROM calls WHERE call_id='3339895706' and the call.precall_set audit row.

  • INVARIANT: INV-COPILOT-020; INV-COPILOT-007; INV-COPILOT-004.

• Dependencies: COPILOT-104b, COPILOT-104e, COPILOT-112

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• Notes: It runs after 104e so the live seed is written to the v2 transcript's call row. This story owns the precall_json column's preservation, because 104b runs before the column exists.

• ID: COPILOT-113

• Title: Seeding from pre-call facts at evidence i=-1 (pure): conversion, initialState and recompute parameters, replacement provenance and an active conflict that resolves

• Description: As the engine, I want a pure conversion from the stored pre-call facts to engine state, and a record of when the call contradicts them, so that items satisfied before the call never nag and a contradicted fact surfaces once, not forever.

• Acceptance Criteria:

  • Converting the precall. src/ingest/precall.ts seedFromPrecall(precall, policy): Seed (pure) converts each value into the form the call path produces:

    • a slot label id as FactValue.value;
    • currency_pair as the string pairLegs reads (for example SAR/NZD);
    • amount as the string amountValue reads (for example 25000 NZD), plus a seeded amount_history entry (111c).

    Each value gets conf: 1, i: -1, t: 0, source, alongside client_type and persisted[known_fact] = {i: -1, value: 1} for slots that have a known_fact.

  • Initial template. templateFor (src/engine/plan.ts:72) returns plan.initial_template (110a) before a purpose locks, instead of other. When the field is absent, it returns other, as today. 110d sets plan.initial_template: first_call_after_signup for onboarding, and customer success leaves it absent. So the first decision's plan, before the purpose Choice locks (the greeting is low-confidence), already holds the first-call fact items.

  • Applying it. src/engine/state.ts initialState(pin, seed?) applies the seed. src/engine/recompute.ts recompute(…, seed?) takes it as a parameter and stays pure. A seeded chip's at is {i: -1, t: 0}, so FactChip.at stays non-null; 114b renders no link for i < 0.

  • Provenance and conflict.

    • A confident different call value replaces a seeded one: the chip reads "updated" and the source becomes call.
    • FactValue.replaced: {value, source} keeps the seeded value as history only.
    • An active FactValue.conflict: true is set at the same time. It clears on engine time: once the fact's item has been current continuously for at least thresholds.conflict_hold_s of call time (optional, 20 s, not less than LIVE_MIN_DWELL), and a client run has ended and a rep-turn decision has arrived since it became current.
    • Limitation: the hold is measured on engine time, so when the presenter defers the card (mid-run, or during the dwell), the time the rep actually sees it may be shorter than 20 s. §6 risk 21 records this.
    • A new confident value that agrees with the seed also clears it.
    • source_conflict (111a) reads conflict, not replaced, so a resolved fact stops resurfacing.

  • Tests.

    • tests/unit/precall.test.ts round-trips each slot through factChips and clientAmountsGbp.
    • tests/unit/engine-state.test.ts and tests/unit/engine-plan.test.ts, with 3339895706's demo payload:
      • at i=0 plan.known holds check_serviceability_first and understand_the_transfer (source demo);
      • plan.facts has 7 chips with source demo and at.i -1;
      • a later confident residency of GB sets replaced and conflict, and surfaces check_serviceability_first once;
      • over consecutive mid-run client decisions, conflict stays true;
      • after 20 s current, a client run end and a rep-turn decision, it clears;
      • once cleared, it does not surface again;
      • with a synthetic plan.initial_template and a low-confidence greeting, the first decision's plan.known holds both fact items; with the field absent, the template is other, as today.
    • tests/unit/engine-recompute.test.ts: zero drift with the same seed.

    npx vitest run tests/unit/engine-*.test.ts tests/unit/precall.test.ts → all passed; npm run typecheck exits 0.

  • INVARIANT: INV-COPILOT-020; INV-COPILOT-001; INV-COPILOT-016.

• Dependencies: COPILOT-111c, COPILOT-112

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-113c

• Title: Pre-call seed through every session path: the snapshot at load, seek, rehydrate and set_weights [INTEGRATION-CRITICAL]

• Description: As the Durable Object, I want every session to take its pre-call seed once and carry it through every path that rebuilds state, so that a replay, a seek, a rehydrate and a recompute all see the same start.

• Acceptance Criteria:

  • Snapshot at load. src/session/handlers/load.ts copies calls.precall_json and its seed (113) into sessions.precall_json ({precall, seed}) and into the DO meta, once, at session start. A later PUT never changes an existing session.

  • Every rebuild path passes meta.seed:

    • load.ts:131;
    • seek.ts:55;
    • src/session/checkpoint.ts:254 (the rehydrate with no checkpoint);
    • src/session/handlers/set_weights.ts:61 (into recompute).

  • Tests (tests/workers/session-load.test.ts, tests/workers/session-seek.test.ts, tests/workers/session-recompute.test.ts, tests/workers/session-checkpoint.test.ts):

    • the snapshot is copied once;
    • a later PUT leaves it unchanged;
    • a rehydrate after an eviction, a seek and a set_weights recompute all keep the seed (the first decision's 7 demo chips).

    npx vitest run -c vitest.workers.config.ts tests/workers/session-load.test.ts tests/workers/session-seek.test.ts tests/workers/session-recompute.test.ts tests/workers/session-checkpoint.test.ts → all passed; npm run typecheck exits 0.

  • [INTEGRATION-CRITICAL] Live probe, after 112b's PUT, on the deployed Worker (health.version == HEAD):

    1. node scripts/replay-ws.mjs --call 3339895706 --scenario onboarding --speed 20 --session m1b-113c-<yyyymmdd> → errors == 0.
    2. node scripts/ws-probe.mjs --call 3339895706 --session m1b-113c-<yyyymmdd> --resume --known: the first decision shows 7 chips sourced demo, and check_serviceability_first and understand_the_transfer known and not in plan.items. Quote it.

  • INVARIANT: INV-COPILOT-020; INV-COPILOT-009; INV-COPILOT-004.

• Dependencies: COPILOT-112b, COPILOT-113

• Priority: HIGH

• Executor: claude:opus

• Estimate: 1 otto iteration

• ID: COPILOT-113b

• Title: The served-list gate on the jurisdiction concern

• Description: As the engine, I want the jurisdiction concern to stay closed while the client's country is known and on the partners' served list, and never to be silenced by "known" alone, so that the "we can't serve you" exit is kept.

• Acceptance Criteria:

  • src/engine/concern.ts updateConcern (HOT, after 117): a raise typed jurisdiction is ignored while residency is known and in fact_lists.served_countries. The gate does nothing while the list is absent or empty, as it is today.

  • Tests (tests/unit/engine-concern.test.ts, with fixture banks):

    • served_countries: ['SA'] with residency SA: a jurisdiction raise opens nothing.
    • ['GB'] with residency SA: a raise at client_objecting 0.9 typed jurisdiction opens an episode.
    • An empty list: it opens.
    • Residency unknown with ['SA']: it opens.

    npx vitest run tests/unit/engine-concern.test.ts tests/unit/engine-purity.test.ts → all passed.

  • SAFETY: the gate is never keyed on "known" alone; served_countries in policy/src stays empty (§7 Q3).

  • INVARIANT: INV-COPILOT-001; INV-COPILOT-017.

• Dependencies: COPILOT-110b, COPILOT-117

• Priority: MEDIUM

• Executor: claude:opus

• Estimate: 1 otto iteration

• Notes: Inert on the live call until a served list exists, so it needs no live probe; 118's register records it as such.

• ID: COPILOT-114

• Title: Live view as a guide: Now, Coming up, collapsed Covered, no tallies, the approved head [INTEGRATION-CRITICAL]

• Description: As a rep, I want the plan to read as a guide (one card, up to three things coming up, and what I have covered in one line) so that it never looks like a score sheet (decision 2b).

• Acceptance Criteria:

  • web/src/plan.ts and web/src/shell.ts (HOT, after 107 and 117) lay the pane out in this order (decision 2b):

    1. Head. plan.head.title ("Guide for this call") and plan.head.subtitle ("Adapts as you talk. Use what fits.") from the pinned bundle's plan.view_labels when approved; otherwise "Plan for this call" and no subtitle. There is no tally.
    2. Chips. The chips row, where it is today.
    3. Now (data-section="now"): the current card, with 107's points.
    4. Coming up (data-section="coming-up"): at most 3 applying must-say rows in plan order (states next/later), grey, with no state word and no time.
    5. Covered (data-section="covered"): the done rows collapsed into one button line, "Covered: