Filed unassigned by the domain:engine seat (session session_01VK8rFDtg8eREaxBGX99Csn) as a cross-lane follow-up: the work lands in packages/cli, which is not this seat's lane, so it goes to the queue rather than into the originating PR. ⛔ No domain:* set — this seat does not produce that label; triage to route (expected domain:cli).
Provenance
Raised by the #11535 dev in its report and deliberately not added, because packages/cli was outside that dispatch's declared file surface. Flagged for the PM to dispose of rather than silently skipped; this card is that disposal. Landed alongside PR #11720 (Part of #11535).
One-line executable criterion
A drift entry whose category is needs_confirm (specifically the new manual_column_type_change op) must not refuse an artifact-pinned boot — asserted by feeding a real entry through runArtifactBootMigrationGate itself, not by asserting the category string.
Why this pin is worth having
#11535's detection half rests entirely on one measured fact, and today that fact is pinned only structurally (the emitted category is asserted, with the measurement written into a comment). The fact is:
severity is read by no boot gate — the ordinary boot path warns on every entry regardless of it.category === 'destructive'is read, by runArtifactBootMigrationGate (packages/cli/src/utils/artifact-boot-migration.ts:137) at kernel:ready, before the socket opens, and it refuses the boot.- Measured through the real gate function:
destructive → ok=false; needs_confirm → ok=true; safe → ok=true.
That asymmetry is why #11535 could ship a loud finding without bricking the boot of every already-running deployment it exists to help — those deployments are, by the card's own account, all currently serving with the stale column. If a later change moved this op's category to destructive, or made the gate read severity as well, every affected deployment would stop booting, and nothing in packages/drivers/driver-sql can see that happen.
A pin in driver-sql cannot cover it: the gate lives in packages/cli and the driver package must not acquire a dependency on it.
Suggested shape (not prescriptive)
Next to packages/cli/src/utils/artifact-boot-migration.test.ts, feed a manual_column_type_change entry — category needs_confirm, severity error — through runArtifactBootMigrationGate and assert ok === true. ⚠️ Worth pairing it with a destructive control that asserts ok === false, so the test proves the gate can still refuse; without that control the assertion passes for a gate that has stopped refusing anything, which is the false green this whole family keeps producing.
Related
Filed unassigned by the
domain:engineseat (sessionsession_01VK8rFDtg8eREaxBGX99Csn) as a cross-lane follow-up: the work lands inpackages/cli, which is not this seat's lane, so it goes to the queue rather than into the originating PR. ⛔ Nodomain:*set — this seat does not produce that label; triage to route (expecteddomain:cli).Provenance
Raised by the #11535 dev in its report and deliberately not added, because
packages/cliwas outside that dispatch's declared file surface. Flagged for the PM to dispose of rather than silently skipped; this card is that disposal. Landed alongside PR #11720 (Part of #11535).One-line executable criterion
A drift entry whose
categoryisneeds_confirm(specifically the newmanual_column_type_changeop) must not refuse an artifact-pinned boot — asserted by feeding a real entry throughrunArtifactBootMigrationGateitself, not by asserting the category string.Why this pin is worth having
#11535's detection half rests entirely on one measured fact, and today that fact is pinned only structurally (the emitted category is asserted, with the measurement written into a comment). The fact is:
severityis read by no boot gate — the ordinary boot path warns on every entry regardless of it.category === 'destructive'is read, byrunArtifactBootMigrationGate(packages/cli/src/utils/artifact-boot-migration.ts:137) atkernel:ready, before the socket opens, and it refuses the boot.destructive→ok=false;needs_confirm→ok=true;safe→ok=true.That asymmetry is why #11535 could ship a loud finding without bricking the boot of every already-running deployment it exists to help — those deployments are, by the card's own account, all currently serving with the stale column. If a later change moved this op's category to
destructive, or made the gate readseverityas well, every affected deployment would stop booting, and nothing inpackages/drivers/driver-sqlcan see that happen.A pin in
driver-sqlcannot cover it: the gate lives inpackages/cliand the driver package must not acquire a dependency on it.Suggested shape (not prescriptive)
Next to⚠️ Worth pairing it with a
packages/cli/src/utils/artifact-boot-migration.test.ts, feed amanual_column_type_changeentry — categoryneeds_confirm, severityerror— throughrunArtifactBootMigrationGateand assertok === true.destructivecontrol that assertsok === false, so the test proves the gate can still refuse; without that control the assertion passes for a gate that has stopped refusing anything, which is the false green this whole family keeps producing.Related
needs_confirmand be declined by the reconciler #11721 — the drift category vocabulary has no report-only state, so this op borrowsneeds_confirmand is declined by the reconcilerpackages/drivers/driver-sql/src/schema-drift.ts— where the op and its category are emitted