You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Acme Add-on (Lost) prose says "Revisit in Q3" — a hand-typed quarter on a deal seeded daysAgo(25), and today it names the quarter the deal was lost in #1712
Found by the difference-set sweep #1692's dispatch order asked for (Zone 2 item 4: re-check the claim that the Acme ARR line is the repo's only hand-typed calendar period, searching by behaviour rather than one literal token). It is not the only one — this is the difference.
Not fixed in #1692's PR: that card's scope is fenced to one sentence in the Acme Corporation account description, and this is a different record.
Dedup done against the full open set (78 open issues, repo-scoped REST list + local grep over titles and bodies; the control term matched #1692, so the read is live). No same-topic card. Adjacent but different: #1692 (the account description's ARR line), #1293 (seed records vs date predicates).
The measurement
src/data/sales.seed.ts, the Acme Add-on (Lost) opportunity:
description: `Tried to bolt on the Marketing Cloud module via cold outbound. Lost
because Acme's marketing org is already on a 2-year HubSpot contract. Revisit in
Q3 when that contract is up for renewal.`
Resolved on the day this was measured (2026-09-06), daysAgo(25) is 2026-08-12 — which is in Q3 2026. So the sentence tells a reader to revisit the deal in the quarter it was already lost in.
Two things are wrong, and they fail in opposite directions
It contradicts the record's own loss_reason narrative. The same record's loss_details reads: "Marketing is locked into a 2-year HubSpot contract; the buying window opens when that renews." A two-year lock and a revisit this quarter cannot both be true. The account description states the same fact without a date — "the buying window opens when that contract renews" — and that version does not drift.
Why it is worth a card rather than a shrug
Acme Add-on (Lost) is one of two Acme opportunities an evaluator reaches from the hero account, and loss_reason / loss_details are exactly what the loss-analysis reports are seeded to demonstrate. A follow-up instruction that is self-contradicting on the day it is read is the sort of detail that is noticed before the feature.
Not judged here
Which repair to make. The two routes #1692's triage named apply unchanged — derive the period, or write a sentence that is true whenever it renders — and the second is what the sibling record already does: the next_step on Acme Platform Upgrade carries a standing in-file ruling (#1660) that no date goes back into this prose, absolute or relative, because a second copy is a second thing to drift. Whether "Q3" was meant as a fiscal quarter is the same open question #1692 raised and answered by measurement: this app configures no fiscal-period mechanism (fiscal occurs twice in src/, both times inside free-text loss prose), so the only period vocabulary available is the calendar one.
Found by the difference-set sweep #1692's dispatch order asked for (Zone 2 item 4: re-check the claim that the Acme ARR line is the repo's only hand-typed calendar period, searching by behaviour rather than one literal token). It is not the only one — this is the difference.
Not fixed in #1692's PR: that card's scope is fenced to one sentence in the
Acme Corporationaccount description, and this is a different record.Dedup done against the full open set (78 open issues, repo-scoped REST list + local grep over titles and bodies; the control term matched #1692, so the read is live). No same-topic card. Adjacent but different: #1692 (the account description's ARR line), #1293 (seed records vs date predicates).
The measurement
src/data/sales.seed.ts, theAcme Add-on (Lost)opportunity:That record is seeded relatively:
Resolved on the day this was measured (2026-09-06),
daysAgo(25)is 2026-08-12 — which is in Q3 2026. So the sentence tells a reader to revisit the deal in the quarter it was already lost in.Two things are wrong, and they fail in opposite directions
It is a fixed period on a moving record, the same defect class as Acme's account description dates the signed renewal to "Q1 2025", but the renewal record closes
daysAgo(15)— an absolute label on a relative-date seed #1692:Q3is authored once and the record's date is recomputed on every seed load, so the two only agree by accident. It carries no year, which does not make it safer — it makes it ambiguous as well as drifting.It contradicts the record's own
loss_reasonnarrative. The same record'sloss_detailsreads: "Marketing is locked into a 2-year HubSpot contract; the buying window opens when that renews." A two-year lock and a revisit this quarter cannot both be true. The account description states the same fact without a date — "the buying window opens when that contract renews" — and that version does not drift.Why it is worth a card rather than a shrug
Acme Add-on (Lost)is one of two Acme opportunities an evaluator reaches from the hero account, andloss_reason/loss_detailsare exactly what the loss-analysis reports are seeded to demonstrate. A follow-up instruction that is self-contradicting on the day it is read is the sort of detail that is noticed before the feature.Not judged here
Which repair to make. The two routes #1692's triage named apply unchanged — derive the period, or write a sentence that is true whenever it renders — and the second is what the sibling record already does: the
next_steponAcme Platform Upgradecarries a standing in-file ruling (#1660) that no date goes back into this prose, absolute or relative, because a second copy is a second thing to drift. Whether "Q3" was meant as a fiscal quarter is the same open question #1692 raised and answered by measurement: this app configures no fiscal-period mechanism (fiscaloccurs twice insrc/, both times inside free-text loss prose), so the only period vocabulary available is the calendar one.Nothing is red and no user is blocked.