fix(seed): reconcile the Acme narrative, and flag a non-customer

[os-steve]

Closes #1646
Closes #1647

Description

Two corrections to src/data/sales.seed.ts, folded because they answer one
question: does a hand-written assertion in the seed book agree with the rows
sitting next to it.

#1646 — the Acme description. The card named one sentence. Verifying its
claim that every other sentence reconciles turned up two more, so all three
are corrected here (the card's own reasoning applies unchanged to each: it is
the longest piece of hand-written narrative in the seed book, and nothing
mechanical will ever find a false line in it).

#1647 — the flagged panel that could only render one row. Stark Medical
now carries health_score: 'at_risk', taking the route the grading ruling
picked: an at_risk partner satisfies the panel criterion and is
semantically sound, so the card's "invent bad data or soften the comment"
dilemma does not bind. The block's comment is true and is untouched.

Type of Change

• Bug fix (non-breaking change which fixes an issue)

Changes Made

1. "Renewal due in 45 days" (#1646, the named sentence)

No seeded record carries a 45-day renewal horizon. Measured on this branch:

claim	record	measured
renewal due in 45 days	Acme Annual Renewal 2025	closed_won, close_date = daysAgo(15)
contract horizon	Acme contract in revenue.seed.ts	end_date = daysFromNow(335), auto_renewal: true
the governance workshop	Acme Platform Upgrade (OPEN)	close_date = daysFromNow(30), next_step names the workshop

The sentence had folded the open upgrade into a renewal that was already won.
It now names the upgrade, its real horizon, and the workshop that gates
signature — the shape the ruling asked for.

2. "Slipped one opportunity ($75K add-on) ... due to slow procurement cycle"

Acme Add-on (Lost) is closed_lost with loss_reason: 'timing' and
loss_details naming a two-year HubSpot contract on Acme's marketing org.
Procurement appears nowhere on that deal, and the deal did not slip — it was
lost. The line now states the loss and the reason the record gives.

3. "Login issues ticket is approaching its SLA"

sla_due_date is derived from the priority x tier matrix
(src/objects/_case-sla.ts). That case is high on an enterprise account
and two days old, so it is due 8 hours after creation — its clock ran out
roughly 40 hours before the demo boots. It is past its SLA, not approaching
it; case_sla_monitor flags it on its first sweep. needs eyes today is kept
because it is still true.

Everything else in that description reconciles and is byte-identical: the
$220K ARR and 22% uplift match the closed renewal, the open $150K upgrade
matches the opportunity, and the open ticket and the billing dispute match
seeded cases.

4. Stark Medical is flagged at_risk (#1647)

csm_flagged_accounts groups by type to separate a flagged customer from a
flagged prospect or partner — the one thing the grid view
crm_account.at_risk_accounts cannot show. That is not a matter of comment:
the view's filter carries { field: 'type', operator: 'equals', value: 'customer' }
ahead of the health term, verified in the implementation.

at_risk rather than churning is the honest severity as well as the
matching one: Stark's pilot was won, its expansion died on no_budget 60
days ago, and the partnership contract is still in legal review — a partner
can be at risk, but was never a subscription that could churn.

FLAGGED grouping, computed with the panel's own criterion read off the report
metadata (is_active: true AND health_score $in ['at_risk','churning'],
rows: ['type']):

              before                          after
FLAGGED       Initech  (at_risk,  customer)   Initech  (at_risk,  customer)
              Wayne    (churning, customer)   Wayne    (churning, customer)
                                              Stark    (at_risk,  partner)

panel rows    customer: 2      -> 1 row       customer: 2, partner: 1  -> 2 rows

Stark's clock stays at today(), so like Wayne it is outside every windowed
panel: it reaches csm_flagged_accounts and no other block, and the
type == 'customer' grid view still cannot see it. That is the report-block
versus grid-view difference demonstrated on data for the first time.

5. The doctrine block records the third row and the blanks

Only five of nine accounts carried health_score before this PR, and the four
blanks are exactly the four non-customers. Judged not a stated convention:
this file writes its deliberate omissions down (billing_country / territory
"deliberately NOT authored here", Apex's other bucket "a stated
classification here, not a blank", Lattice's missing state), and no comment,
guard roster or field constraint mentions these. The health_score block now
says why Stark is filled and why the three prospects stay blank — a CSM
asserts something about a relationship, and nobody has been in the room with
an account that was never won.

No guard is added, on either card: free prose has no mechanical relation to the
rows it narrates, and pinning a seeded distribution here was ruled out twice.

Testing

pnpm verify fully green on the final commit — validate, typecheck,
lint, lint:i18n-gate, hygiene, hygiene:tokens, build, test:

✓ Validation passed (1369ms)
✓ i18n lint gate: 0 `i18n/missing-*` issues
✓ source hygiene clean
✓ source token ratchet clean      (src/data is outside the ratchet by ruling)
Artifact: dist/objectstack.json (2039.9 KB)

Test Files  161 passed (161)
     Tests  3400 passed | 1 skipped (3401)

Specifically re-verified after the change:

• No seeded account carries a billing_address, so both territory sharing rules match zero records on the demo dataset #638 territory partition intact — 6 NA (5 US + 1 CA) / 2 EMEA (DE, UK) /
  1 other (SG), identical before and after. No address was touched.

• Demo seeds for the activity model: crm_event / crm_event_attendee rows + a last_activity_date distribution (follow-up to #592) #671 activity bands intact — 104 / 72 / 41 days plus six accounts inside
  30, identical before and after. No activity clock was touched.

• test/churn-health-score-block.test.ts's header comment still holds. Its
  three claims are about the criterion, about rows being non-zero, and about
  Initech overlapping at_risk_accounts while a churning account worked
  daily lands nowhere else. Adding an at_risk partner with a live clock
  touches none of them: Initech's overlap is unchanged, the synthetic
  churning row is unchanged, and the block still returns rows. The suite
  passes unchanged.

• Unit tests pass

• Linting passes

• Build succeeds

• I have added a changeset

Out of scope — found while measuring, not fixed here

Three record-to-record contradictions turned up around Acme that are not
in either card's description. None is touched by this PR; they need their own
cards (the dedup search could not run — see the report).

1. The governance workshop has three different schedules. The opportunity's
   next_step says "the week of close_date - 14d" (= daysFromNow(16)); the
   seeded event is planned for daysFromNow(6) with invitations already out;
   and the task asking someone to schedule it is not_started, due
   daysFromNow(7) — a day after the workshop it plans.
2. An activated contract for a deal still in proposal. The Acme contract
   is status: 'activated', signed_date: daysAgo(32), contract_value: 150000,
   and it links crm_opportunity: 'Acme Platform Upgrade' — an opportunity that
   closes in 30 days at 60%.
3. The generated demo cases couple account to status perfectly. In
   service.seed.ts the 30-case generator indexes both a 5-element account list
   and a 5-element status list by i % 5, so every Acme demo case is new,
   every Globex one in_progress, every Wayne one resolved, every Initech one
   closed and every Stark one escalated. No account shows a status mix.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
hotcrm	Ignored		Sep 6, 2026 5:05am UTC