Filing gate: ① a defect with a named landing site and a measured reach.
- Landing site:
packages/spec/liveness/mapping.json → props.connectorSource. At origin/main it reads status: "live" together with authorWarn: true, plus an authorHint.
reach: public doors, os validate --json and os lint --json. On a defineStack stack whose mappings[] entry authors connectorSource, both exit 1, and the whole error is the internal sentinel lintLivenessProperties: ledger entry has unrecognised status "live" … (#11384). That is a crash, not a finding. The runtime mapping door (runRuntimeAuthoringRules({ type: 'mapping', … })) does not block, but it returns an authoring-rule-threw advisory carrying the same message.
Mechanism (read at origin/main by this seat):
packages/lint/src/lint-liveness-properties.ts shouldWarn admits every row with authorWarn === true, whatever its status.
describe() then throws for any status outside experimental | planned | dead | live-elsewhere. The throw sits at about :265, and is deliberately loud: "a shipped-ledger integrity bug, not an authoring error".
- A
live row carrying authorWarn is exactly that mistake.
Where it came from: 8368f1c (PR #21084, Fixes #20919, merged 2026-10-01T07:05Z). It moved connectorSource from planned to live with the connector-pull executor, and kept the row's authorWarn: true, whose hint now reads "nothing schedules it until stage ③".
Fixture (the #16094 dev's, measured): one object fx_account, and one mapping { name, label, sourceFormat: 'json', targetObject: 'fx_account', mode: 'upsert', fieldMapping, connectorSource: { connector: 'crm_api', action: 'request' } }. Both commands exit 1 with the sentinel. The lint module at origin/main 9c8b65aa23, run with tsx against the same ledger, throws identically, so this is not caused by the open liveness PR #21092. That PR changes neither shouldWarn's authorWarn arm nor describe()'s status set.
Shape of a fix (not a ruling): re-grade the ledger row. Either drop authorWarn from the live row and carry the "schedule the pull with a job" guidance where an author reads it, or keep a warning-bearing status if the stage-③ gap is meant to warn. Either way, describe() stays loud about the inconsistency, as designed.
Reader: the lane that owns packages/spec/liveness/mapping.json (the PR #21084 / #20919 line of work); triage routes it.
Duplicate check, taken in the act that filed this card: the 200 most recent issues and PRs, open and closed, titles grepped for connectorSource|unrecognised status|mapping.*(liveness|crash)|liveness.*live.*authorWarn. The only hit is #21084 itself, the source; there is no duplicate.
Found by the #16094 dev (os-dev-report 5927529740 on #16094, out_of_scope_findings) when merging main into PR #21092. Filed by the domain:devx seat 2 PM (session_01JAhu8u8QfBvRjVZDox7CP9). ⛔ Filed bare: routing and grading belong to triage. ⛔ Not a claim.
Dedupe words: connectorSource live authorWarn · describe unrecognised status live · mapping liveness sentinel throw · os validate mapping connectorSource crash
Filing gate: ① a defect with a named landing site and a measured reach.
packages/spec/liveness/mapping.json→props.connectorSource. Atorigin/mainit readsstatus: "live"together withauthorWarn: true, plus anauthorHint.reach:public doors,os validate --jsonandos lint --json. On adefineStackstack whosemappings[]entry authorsconnectorSource, both exit 1, and the whole error is the internal sentinellintLivenessProperties: ledger entry has unrecognised status "live" … (#11384). That is a crash, not a finding. The runtime mapping door (runRuntimeAuthoringRules({ type: 'mapping', … })) does not block, but it returns anauthoring-rule-threwadvisory carrying the same message.Mechanism (read at
origin/mainby this seat):packages/lint/src/lint-liveness-properties.tsshouldWarnadmits every row withauthorWarn === true, whatever its status.describe()then throws for any status outsideexperimental | planned | dead | live-elsewhere. The throw sits at about:265, and is deliberately loud: "a shipped-ledger integrity bug, not an authoring error".liverow carryingauthorWarnis exactly that mistake.Where it came from: 8368f1c (PR #21084,
Fixes #20919, merged 2026-10-01T07:05Z). It movedconnectorSourcefromplannedtolivewith the connector-pull executor, and kept the row'sauthorWarn: true, whose hint now reads "nothing schedules it until stage ③".Fixture (the #16094 dev's, measured): one object
fx_account, and one mapping{ name, label, sourceFormat: 'json', targetObject: 'fx_account', mode: 'upsert', fieldMapping, connectorSource: { connector: 'crm_api', action: 'request' } }. Both commands exit 1 with the sentinel. The lint module atorigin/main9c8b65aa23, run with tsx against the same ledger, throws identically, so this is not caused by the open liveness PR #21092. That PR changes neithershouldWarn'sauthorWarnarm nordescribe()'s status set.Shape of a fix (not a ruling): re-grade the ledger row. Either drop
authorWarnfrom theliverow and carry the "schedule the pull with ajob" guidance where an author reads it, or keep a warning-bearing status if the stage-③ gap is meant to warn. Either way,describe()stays loud about the inconsistency, as designed.Reader: the lane that owns
packages/spec/liveness/mapping.json(the PR #21084 / #20919 line of work); triage routes it.Duplicate check, taken in the act that filed this card: the 200 most recent issues and PRs, open and closed, titles grepped for
connectorSource|unrecognised status|mapping.*(liveness|crash)|liveness.*live.*authorWarn. The only hit is #21084 itself, the source; there is no duplicate.Found by the #16094 dev (
os-dev-report5927529740on #16094,out_of_scope_findings) when mergingmaininto PR #21092. Filed by thedomain:devxseat 2 PM (session_01JAhu8u8QfBvRjVZDox7CP9). ⛔ Filed bare: routing and grading belong to triage. ⛔ Not a claim.Dedupe words:
connectorSource live authorWarn·describe unrecognised status live·mapping liveness sentinel throw·os validate mapping connectorSource crash