Breakdown: Demo experience fixes — seeded timelines and canned-mode affordances

• scope-slug: demo-experience-fixes · source: Jamie's platform-audit notes (2026-08-17) + the known-limitation lists in the shipped demo runs' verify/release notes; no scope.md behind this batch. Notes quoted per stub.
• initiative: Refine the bridge / objective: Q2-2026 Objective 1 — Establish Product-Market Fit with Vendor Partners
• personas: Admin, Customer, CSM, SDM, Expert, Vendor

What I understood

Two demo-tenant defects that were known at their ship gates but never filed as intake. The demo seeder lost its per-lead activity logging in the merged storyline work, so 49 of 61 seeded leads open with empty activity timelines — the verify note said "belongs in intake against that run" and nobody filed it. And in canned agent mode, denying the BRD approval still plays the scripted success turn; Jamie's ruling is to hide the deny affordance in canned mode rather than script a deny path. This scope deliberately does not duplicate the pending demo-data-quality batch (reset cron, storyline coverage, SaaS storyline, customer surfaces) — those stubs already exist; these two close the unfiled gaps beside them.

Where it sits

Technical demo environment (docs: technical/demo-environment); touches packages/services/src/db/services/demo-data/ and the canned BRD chat surface in apps/web.

Build order

1. seeded-lead-activity-timelines — restore per-lead activity logging in the demo seeder — depends-on: none
2. canned-brd-deny-affordance — hide the deny control during canned BRD replay — depends-on: none

Out of scope (whole scope)

• Everything already stubbed in .icm/intake/demo-data-quality/ (reset audit + cron, storyline full coverage, SaaS vendor storyline, customer surface fixes).
• Onboarding replay reset — covered by onboarding-and-tenant-lifecycle/onboarding-reentry-and-progress.
• Removing the published demo credentials from the docs — docs-accuracy.

Stub: Hide the deny control during canned BRD replay

• feature-slug: canned-brd-deny-affordance
• scope: demo-experience-fixes
• personas: Admin, Customer
• initiative: Refine the bridge / objective: Q2-2026 Objective 1 — Establish Product-Market Fit with Vendor Partners
• depends-on: none
• sequence: 2 of 2

Problem

In canned agent mode the BRD replay derives its step from the assistant turn count and cannot branch — so denying the approval still plays the scripted success turn, and a presenter who clicks deny in front of a client shows an agent that ignores them. Accepted as a known limitation at the demo-canned-agents gate. Jamie's ruling: "denying the BRD approval in canned mode still plays the success path, hide the deny button in canned mode."

Proposed change

When the BRD chat is in canned replay on a demo tenant, don't render the deny affordance — approve (and the existing skip control) remain. The mode check must be the server-resolved agent mode (the same isDemo-first resolution the cookie preference sits under), never client state. Live mode on a demo tenant keeps the full approve/deny pair, which stays the documented way to demonstrate the deny path.

Acceptance criteria (rough)

• In canned mode, the BRD approval surface shows no deny control; approve and skip work as before.
• Switching the presenter toggle to live restores the deny control on the same lead.
• Non-demo tenants are entirely unaffected (control renders as today).
• The demo-environment docs page's known-limitations note is updated to describe the hidden control instead of the wrong-turn behaviour.

Out of scope (this feature)

• Scripting a real deny branch into the transcript format (turn-count stepping is the design; branching is a bigger change nobody asked for).
• Onboarding replay behaviour.

Notes for Define

Evidence: limitation recorded in demo-canned-agents/05_verify/output/verify.md ("step index derives from assistant turn count, can't distinguish approve from deny — acceptance criterion 2 not met as written, accepted"); mode resolution in packages/services/src/ai/canned/mode.ts + apps/web/lib/agent-mode.ts (server re-reads isDemo before the cookie); approval surface in the BRD chat components (apps/web/app/(app)/projects/brd/[id]/ + SkipCannedBrdButton pattern for canned-only rendering). Docs update follows docs-sync. touches: apps/web (BRD approval surface), apps/docs (demo-environment page).

Stub: Restore activity timelines on seeded demo leads

• feature-slug: seeded-lead-activity-timelines
• scope: demo-experience-fixes
• personas: Admin, CSM, SDM, Customer
• initiative: Refine the bridge / objective: Q2-2026 Objective 1 — Establish Product-Market Fit with Vendor Partners
• depends-on: none
• sequence: 1 of 2

Problem

The demo seeder's createLead dropped its logActivity("CREATE", …) call in the merged storyline work, so 49 of 61 seeded leads open with an empty activity timeline — a presenter clicking into most leads shows a dead feed. Known at the demo-canned-agents verify gate ("belongs in intake against that run"), never filed. Jamie's note: "49 of 61 seeded leads have empty activity timelines. it's a known issue, so fix it."

Proposed change

Restore activity logging in the demo seeder so every seeded lead carries a plausible timeline: at minimum its creation event, and for leads seeded mid-journey the status-history events the storyline already writes should have matching activity entries — backdated consistently with the lead's seeded dates and deterministic like the rest of the seeder (no wall-clock variation beyond the documented relative-date anchor).

Acceptance criteria (rough)

• After a fresh reset, every seeded lead's workspace activity section is non-empty; a mid-journey lead's timeline is consistent with its status history.
• Timelines are deterministic across two runs against an equivalent tenant (per the seeder's determinism contract).
• Seed run counts report activity entries created, so a regression like this is visible on the trigger screen next time.
• Non-demo seeding paths are untouched.

Out of scope (this feature)

• New storyline content or coverage (demo-data-quality stubs 9–10 own that).
• Activity backfill for real (non-demo) tenants.

Notes for Define

Evidence: demo-canned-agents/05_verify/output/verify.md (the finding, naming packages/services/src/db/services/demo-data/index.ts:1259 — createLead lost logActivity); determinism rules in demo-data/deterministic.ts (hashOf, monthsAgo); activity write path db/services/activity/. Coordinate with the pending demo-data-quality/storyline-full-coverage-generator stub — if that lands first its generator contract may absorb this; whichever runs second rebases. touches: packages/services/src/db/services/demo-data/.

Answers from Jamie — interrogation 2026-08-17

Recorded by the intake-easy-features session; these rulings bind Define.

• Ordering vs the storyline generator: the generator has already landed (demo-data-quality/_done) and saas-vendor-storyline is in flight (PR #818) — author the timelines against the generator's extended Storyline contract, running after the storyline work merges and rebasing on it.