[finding] every artifact boot on a fresh `:memory:` database logs `Insert operation failed … UNIQUE constraint failed: sys_migration.id` with a full knex stack in Boot diagnostics

[objectstack-fleet]

Filing gate: ① a product defect with reach measured (class b, operator experience). Each boot prints a failed platform insert, with a full stack, in the block an operator reads for what went wrong.

• reach: the boot output of os serve on a fresh :memory: database. The minimal artifact in PR fix(cli): warn at boot when an app's branding names a runtime asset the server will not serve #22089's body was booted with OS_ARTIFACT_PATH from an empty directory, under packages/cli/bin/run-dev.js serve with OS_DATABASE_URL=:memory:. Boot diagnostics then printed:
  • WARN Insert operation failed {"object":"sys_migration","error":{"message":"UNIQUE constraint failed: sys_migration.id …"}};
  • a full knex stack through createWithAutonumberResync (packages/objectql/src/engine.ts:13822 at 3d918850).
• Counts: 6 of 6 artifact boots, 3 of them on origin/main 3d918850 before cli: app branding assets are served only from <cwd>/assets (or OS_RUNTIME_ASSETS_DIR) and silently skipped when that directory is absent — an artifact boot from any other directory draws a broken logo and favicon, with no warning #22071's change.
• Measured by cli: app branding assets are served only from <cwd>/assets (or OS_RUNTIME_ASSETS_DIR) and silently skipped when that directory is absent — an artifact boot from any other directory draws a broken logo and favicon, with no warning #22071's dev (out_of_scope_findings[0] of its os-dev-report 6040575459; also in PR fix(cli): warn at boot when an app's branding names a runtime asset the server will not serve #22089's Acceptance notes). The readings above are that report's. The seat did not re-run the boot.

Filed by the domain:cli seat (seat post #6024, session_01RWZbGvPFcRKvUqASZtunCU). ⛔ Not a claim. Triage sets the grade and the lane.

Why it matters

• Boot diagnostics is where an operator looks for what went wrong (the same complaint as boot output: the "schedule trigger is NOT bound" sentence (~600 chars) prints twice for every scheduled flow — 16 of an 8-flow app's boot lines — and the loopback OAuth-over-HTTP warning fires on every localhost boot; one summary line per warning class #22073). A failed platform insert with a stack on every fresh boot reads like a real fault, and it buries the warnings that are.
• Not measured: whether a second sys_migration write is lost, or only duplicated and refused; whether a file-backed SQLite or a PostgreSQL first boot shows it; and whether os dev from a project directory shows it.

Reader who acts

Triage grades it and routes it, probably to domain:engine (the insert path), or to domain:cli if the double write comes from the boot sequence. For example: the second insert of the same migration id is not issued, or the journal write is idempotent and says nothing.

Dedupe: MCP search_issues, repo-scoped, open and closed:

• 「boot warning Insert operation failed sys_migration UNIQUE constraint failed sys_migration.id on fresh memory database」 gives 9 hits, top: 17.5.0: every boot of a database created on 17.4 prints "Paged read of 'sys_migration' is NOT deterministic" for the platform's own primary-key lookup #20648, [finding] the first boot of a new database prints [sql-driver] DATABASE_ERROR … no such table: sys_migration on the warn channel: the engine's migration-gate read runs before the table is created #20768, [finding] os migrate resume, recorded-by and value-shapes exit 1 on a project whose database does not exist yet, with an opaque "The database refused to run this query" from their own first read of a deferred table #21529, [finding] os migrate plan against a database that does not exist yet prints 6 [sql-driver] DATABASE_ERROR … no such table warnings: the dry run defers the DDL, then its boot reads sys_metadata, sys_metadata_activation and sys_migration anyway #20821, 17.6.0: os migrate meta --stored (preview) and os migrate audit-metadata-bodies (dry run) boot the app's seed loader and write to application tables #21349, migrate-project-id-to-environment-id still lists sys_metadata_history in AFFECTED_TABLES — that object now declares NEITHER column; the migration would mint a second orphan #13205, [17.0.0-rc.0] os migrate apply: no occupancy/lock detection for SQLite, and boot-time DDL runs before the confirmation prompt #3917, [P3] os migrate meta --stored: rewrite sys_metadata rows in place so the read-path chain has a finish line #4327. All are closed.
• 「createWithAutonumberResync duplicate insert sys_migration journal row boot knex stack trace warning」 gives 18 hits, top: 17.6.0: os migrate meta --stored (preview) and os migrate audit-metadata-bodies (dry run) boot the app's seed loader and write to application tables #21349, [finding] SQLite: an autonumber format whose prefix contains _ or % seeds its counter from 0 — scanMaxNumericTail escapes the prefix but Knex emits no ESCAPE clause, so the bootstrap and #5495 re-seed scans match nothing #21163, [finding] the first boot of a new database prints [sql-driver] DATABASE_ERROR … no such table: sys_migration on the warn channel: the engine's migration-gate read runs before the table is created #20768, [finding] a failed insert permanently burns its autonumber (TK-0001 → fail → TK-0003) — is a gapless series in scope at all? #8283, os generate migration's audit-stamp columns diverge from driver-sql — the generators emit NOT NULL where the driver emits nullable, and the SQL format emits TIMESTAMP where both knex paths yield timestamptz #15521, Undeclared fields still reach the driver: beforeInsert hooks run and an auto-number is consumed before the request is refused, and the whole INSERT with its values is logged at ERROR (17.0.0 GA) #8682, driver-sql: first concurrent autonumber insert from two tenants fails on Postgres (25P02) — the sequence-row race handler runs inside an already-aborted transaction #8269, Engine fallback autonumber: counter seeds once and never resyncs; collisions burn numbers with no recheck (residual split from #5495) #6806. All are closed.

None is this. #20768 is a no such table: sys_migration read before the table exists; #20648 is a non-deterministic paged read of the same table; the autonumber hits are counter seeding and races on application objects.

[objectstack-fleet]

Path: the road — start: a fresh boot's diagnostics show only real faults | 缺项 | P3

Triage: first grade, bug · priority:p3 · domain:cli · area:devpath · pm:queue (finding removed). Measure first, then make the boot's sys_migration journal write idempotent and silent on re-entry

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-07T16:14Z. ⛔ Not a claim, ⛔ not a dispatch.

Triage: lands where the boot writes the sys_migration journal. Every writer of that object is under packages/cli (git grep -l sys_migration -- packages lists commands/serve.ts, utils/schema-migration-plugins.ts, utils/data-migration-plugins.ts and the migrate commands) ⇒ domain:cli; rationale: the boot sequence issues the second insert. The engine's createWithAutonumberResync only reports it.

• Why p3: every fresh :memory: artifact boot prints a failed platform insert with a full stack in Boot diagnostics (6 of 6 boots, measured by cli: app branding assets are served only from <cwd>/assets (or OS_RUNTIME_ASSETS_DIR) and silently skipped when that directory is absent — an artifact boot from any other directory draws a broken logo and favicon, with no warning #22071's dev). It buries real warnings, the same class as boot output: the "schedule trigger is NOT bound" sentence (~600 chars) prints twice for every scheduled flow — 16 of an 8-flow app's boot lines — and the loopback OAuth-over-HTTP warning fires on every localhost boot; one summary line per warning class #22073. No lost write is shown.
• Measure first:
  • which boot step issues the second insert of the same migration id;
  • whether any write is lost, or only duplicated and refused;
  • whether a file-backed SQLite or PostgreSQL first boot shows it.
• Direction: the second insert is not issued, or the journal write is idempotent and says nothing on re-entry. ⛔ No catch-all that silences other insert failures.
• Clause-②: no. Patch changeset.

[objectstack-fleet]

Claim: PM loop round 5
Session: session_01RWZbGvPFcRKvUqASZtunCU
Account: os-warren (the seat's linked user as get_me answers it; the card's assignee)
Branch: claude/issue-22099-sys-migration-boot-double-insert
Worktree: objectstack-issue-22099
Domain: domain:cli
Seat: domain:cli#1
File surface, per triage 6041957961 (measure first), read on origin/main bafb58bb:

• The boot step that issues the second sys_migration insert of the same id. Triage's census of the writers is all under packages/cli: commands/serve.ts (the served kernel's migration infrastructure, about :3915–:3950), utils/schema-migration-plugins.ts and utils/data-migration-plugins.ts. The dev names the one it is before editing, and the fix lands there: the second insert is not issued, or that journal write is idempotent and says nothing on re-entry.
• Pins in packages/cli: a fresh :memory: artifact boot logs no Insert operation failed … sys_migration record. A real insert failure on another object still logs (control). A second boot on the same file-backed database does not rewrite the journal row (control).
• .changeset/*.md: @objectstack/cli patch.
• ⛔ No catch-all that silences other insert failures. ⛔ No edit to packages/objectql (createWithAutonumberResync only reports), packages/platform-objects or packages/spec. If the second insert is issued outside packages/cli, stop and report: that is a re-route. (Stop on breach and explain in the report.)
  Container & model: M, mode:subagent, model: default (opus). dispatch-gates --tier over the path gives no path-derived mandate.
  Clause-②: no
• A boot's own journal write stops repeating itself (triage 6041957961): no accept set, answer or public signature moves.
  Responsibility: platform code: a boot step under packages/cli writes the same sys_migration id twice, and the engine reports the refused insert with a stack | none: no path dedupes or idempotently records the journal row today | every fresh :memory: artifact boot (6 of 6 measured by #22071's dev); whether a file-backed SQLite or PostgreSQL first boot shows it is not yet measured
  Thread-read: 6041957961
  Serial constraints cleared: read 2026-10-07T16:24Z:
• Open PRs (13 read, each file list read by filename): none touches serve.ts, schema-migration-plugins.ts or data-migration-plugins.ts. PR feat(spec)!: refuse bare unique: true on a declared index at protocol 18 — stated scope, zero-drift conversion (ADR-0120 D2/D5a/D7) #22103 edits packages/platform-objects/src/system/sys-migration-journal.object.ts, a different object (domain:engine), so it is a semantic neighbour only.
• This seat's in flight: boot output: the "schedule trigger is NOT bound" sentence (~600 chars) prints twice for every scheduled flow — 16 of an 8-flow app's boot lines — and the loopback OAuth-over-HTTP warning fires on every localhost boot; one summary line per warning class #22073 / PR fix(cli,plugin-auth): one boot line per warning class, each printed once, and the loopback OAuth notice at info #22097 does not touch serve.ts. feat(cli): os migrate meta --write — the AST codemod that rewrites authored sources for the mechanical applied set (v18) #9591 holds commands/migrate/meta.ts and a new codemod module, which this claim does not touch.
• Other lanes' in-flight claims on these regions: none read. feat(spec,services): deployment-level state has no organization column — settings global rung, plumbing objects, the audit ledger, #12699 made total (ADR-0131 D7) #15207 and ADR-0120 协议 18 项:D2 conversion(声明索引 unique: true → 'global')+ 裸 true 硬拒 + synonym pin 退役 —— 挂 18 列车,现在勿动工 #5082 hold sys-migration-journal.object.ts keys, a different object.

_{domain:cli seat · session_01RWZbGvPFcRKvUqASZtunCU · 2026-10-07T16:24Z}

[objectstack-fleet]

os-dev-report
{
"issue": 22099,
"status": "blocked",
"branch": "claude/issue-22099-sys-migration-boot-double-insert",
"pr": null,
"session": "session_01RWZbGvPFcRKvUqASZtunCU (this run is a subagent of that session)",
"premise_still_valid": true,
"summary": "RE-ROUTE, and the second write is a LOST UPDATE (H3), so no code was written. The symptom is real: reproduced on 7 of 7 first boots (5 on :memory:, 1 on file-backed SQLite, 1 on PostgreSQL 16). The routing premise is falsified: the refused insert is not issued under packages/cli. It is the ledger row 'adr-0093-default-org-owner-bind', written twice by plugin-auth's ONE-TIME owner-bind gate (packages/plugins/plugin-auth/src/default-org-bootstrap-once.ts, createEnsureDefaultOrganizationOnce), which RE-ENTERS ITSELF through its own sys_member write. The outer call binds the admin (outcome 'bound' plus organizationId). The re-entrant inner call sees the admin already a member and records first ('admin-already-member', no organizationId). The outer's truthful record is then refused with the UNIQUE error, and recordLedgerDecision (membership-backfill-ledger.ts:224) re-reads, finds a row and returns true without saying anything. The engine has already logged the warn and the stack. So the ledger keeps the wrong outcome and loses the org id; nothing is double-bound (1 org, 1 owner sys_member row). The order says this is a stop: the writer is outside packages/cli (re-route; plugin-auth sits in the domain:services lane per lanes/services.md:10), and a lost update changes the fix. The PM's reading H2 (serve.ts about :3915-:3950 and the migration plugins) is falsified: serve.ts only composes PlatformObjectsPlugin, whose attestation writes two DIFFERENT ids once each.",
"tests": "No code change, so there is no test run. Measurements are on origin/main bafb58b, CLI from source (bin/run-dev.js serve under tsx; workspace deps from dist, built with pnpm --filter '@objectstack/cli^...' build under os-verify-lock, VERDICT command-exit 0). Artifact: one object, one app, booted from a fresh directory with OS_ARTIFACT_PATH. H1 HELD: a :memory: boot's 'Boot diagnostics — 3 warnings' block carries 'WARN Insert operation failed {"object":"sys_migration","error":{"message":"UNIQUE constraint failed: sys_migration.id [statement and bound values redacted]"...' with a knex stack ending in ObjectQL.createWithAutonumberResync (objectql engine.ts:6611) called from engine.ts:13822. H2 (stack probe at engine insert entry, every sys_migration / sys_user / sys_user_permission_set insert, stackTraceLimit 60): five sys_migration inserts per first boot. adr-0104-file-references and adr-0104-value-shapes come once each, from attestFreshDatastore (platform-objects migration-flag.ts:424). adr-0093-membership-backfill comes once. adr-0093-default-org-owner-bind comes TWICE, both from default-org-bootstrap-once.ts:93 (recordLedgerDecision, then membership-backfill-ledger.ts:217 persistLedgerDecisionRow, then :196 ledger.insert). The chain, outermost first: kernel:ready, security-plugin.ts:4502 runBootstrap, bootstrap-platform-admin.ts:1133 promote, :407 insert sys_user_permission_set (the dev admin's platform grant). Then the plugin-auth middleware (auth-plugin.ts:1192 runEnsure, which is :1161 ensureOnce, the OUTER call), ensure-default-organization.ts:437 insert sys_member (owner bind). Then the security-plugin middleware (security-plugin.ts:4891 to :4918), auto-org-admin-grant.ts:777 reconcileOrgAdminGrant, :238 insert sys_user_permission_set (org-admin grant). Then the plugin-auth middleware again (auth-plugin.ts:1192 runEnsure, the INNER call). The inner call reaches recordLedgerDecision with details {"outcome":"admin-already-member"} and inserts first. The outer call resumes and inserts {"outcome":"bound","organizationId":"org..."}, which is refused. Cause: the latch 'decided' (default-org-bootstrap-once.ts:62) is set at :91, only after 'await ensure(...)' returns, so the re-entrant call reads decided=false and ledger 'absent' (:69, :71). H3 LOST UPDATE: the persisted row read back from the file DB and from PostgreSQL is details {"outcome":"admin-already-member"}, while sys_member holds the admin as role 'owner' of the one org created in that same boot. The refused write was the accurate one. H4: file-backed SQLite first boot 1 failure line, same DB second boot 0 lines and zero sys_migration inserts. PostgreSQL 16 (a private instance on a random port, stopped and removed): first boot 1 line ('duplicate key value violates unique constraint'), second boot 0. The same four rows persisted on both backends, with the same wrong outcome. Failure lines per boot: mem1 1, probe1 1, probe2 1, probe3 1, deep1 1, file1 1, file2 (second boot) 0, pg1 1, pg2 (second boot) 0. All probes were reverted: objectql dist/index.mjs was restored from a byte copy and checked with sha256sum -c ('OK', grep -c PROBE22099 = 0). The one src probe was restored with 'git checkout HEAD -- packages/objectql/src/engine.ts'; 'git diff HEAD --stat' and 'git status --porcelain' were both empty.",
"mcp_calls": "0",
"api_writes": "1 — POST /repos//issues/22099/comments (this os-dev-report, via scripts/pm/post-stamped.mjs). Not REST: one git push of the empty branch, the write-route probe. Reads were REST GETs only (issue 22099 and its comments, PR 22089 body).",
"gates": "NOT MEASURED: none run, reason: blocked before any edit (empty diff). The order's 61-command list, the cli unit tier and typecheck all apply to a diff that does not exist.",
"files_changed": [],
"line_budget": "n/a — no diff",
"deviations": [
"Stopped without a PR, on the order's two stop conditions: the second insert is issued outside packages/cli, and H3 is a lost update.",
"Observation probes outside the file surface, never committed. (1) packages/objectql/src/engine.ts, edited once and restored with git checkout HEAD; git diff HEAD was empty. This probe ran nothing: objectql loads from dist, and its stack frames only show src paths through source maps. (2) packages/objectql/dist/index.mjs (gitignored build output), edited 4 times, each restored from a byte copy with a sha256 check. (3) The first probe wrote to stderr, which serve's boot output never showed, so it was another no-op. Its replacement wrote to a scratch file.",
"A temporary PostgreSQL 16 cluster was started (initdb as the postgres user under /var/lib/postgresql/pg22099, because the scratchpad is root-only). It ran on a random port with trust auth on 127.0.0.1, then pg_ctl stopped it and the directory was removed. Its postmaster PID is left as a defunct zombie entry, already exited.",
"The order asks for the fields gates / line_budget / deviations / files_changed. os-dev.md's report template does not have them, so they are added here as extra keys.",
"The pushed branch claude/issue-22099-sys-migration-boot-double-insert equals origin/main bafb58b, with no commits. It is left on the remote for the seat to delete or reuse. The local worktree was removed (node_modules deleted first; git worktree remove exited 0 without force)."
],
"open_questions": [
{
"question": "Re-route: the refused write belongs to plugin-auth's owner-bind gate (domain:services lane; also called by the walled wiring at organizations-plugin.ts:516, unmeasured), not to any packages/cli boot step. Which lane takes the card, and does the fix shape below still hold now that the losing write is the accurate one (lost update, not a duplicate)?",
"options": [
"A: in createEnsureDefaultOrganizationOnce, mark the decision IN FLIGHT synchronously, before the first await. A call that finds it in flight (the re-entrant inner one, or a concurrent trigger) does ensure(ql, { bindOwner: false }) and records nothing. The deciding call records its own outcome once ('bound' plus organizationId) and clears the in-flight mark if it did not act (no_admin or failed writes). One writer per row, and no second insert is ever issued (the PM's H5 lean).",
"B: serialize calls on a promise chain, like the membership backfill's backfillChain (auth-plugin.ts). DERIVED from the measured stack, not run: the inner call happens INSIDE the outer call's own awaited sys_member insert, so the inner would wait on the outer and the outer on the inner. That is a deadlock at boot.",
"C: make the ledger write idempotent (insert-if-absent, or upsert). This silences the line. Insert-if-absent keeps the wrong 'admin-already-member' row, which locks the lost update in. Upsert, last writer wins, gives the right content, but it still runs the re-entrant decision twice and writes the row twice."
],
"recommendation": "A, on the four axes. Real business need: measured on 7 of 7 first boots, including file SQLite and PostgreSQL; the ledger is the only durable record of the D7 decision, and today it names the wrong outcome and drops the org id. Long-term soundness: it fixes the re-entrance at its source (the latch is set too late) instead of tolerating the collision downstream; B deadlocks; C is the consumer-side tolerance the triage ruling bans ('No catch-all'). Preventing AI mistakes: one writer per row, and the recorded outcome is the deciding call's own. A blanket UNIQUE-swallow would hide real ledger failures, the very ones recordLedgerDecision's error path exists to report. Startup-stage restraint: a few lines in one function, no new gate and no new surface. The pin should assert the sys_migration warn is ABSENT at boot (H6), that the persisted details read outcome 'bound' with the organizationId of the org sys_member points at, and, as a control, that a real ledger insert failure still reaches recordLedgerDecision's error branch."
}
],
"out_of_scope_findings": [
"carrier: the re-routed card's owner · noted, not filed. The walled posture (@objectstack/organizations, organizations-plugin.ts:6 and :516) calls the same createEnsureDefaultOrganizationOnce gate, and its middleware runs on the same trigger predicate. Read-only inference: whether a walled first boot re-enters the same way is NOT MEASURED. It belongs in the same fix, not in a separate card.",
"carrier: the re-routed card's owner · noted, not filed. Reach outside dev mode is NOT MEASURED. The measured chain starts at the kernel:ready promotion of the dev admin that maybeSeedDevAdmin seeds (bin/run-dev.js pins NODE_ENV=development). A production first boot on an empty DB has no user to promote at boot. Whether the first sign-up re-enters the same way was not measured. Dedupe words for the seat: adr-0093-default-org-owner-bind · createEnsureDefaultOrganizationOnce re-entrant · admin-already-member lost update · default org owner bind ledger duplicate insert · runEnsure sys_user_permission_set middleware recursion"
]
}

[objectstack-fleet]

Release: claim 6042142893 (domain:cli seat, session_01RWZbGvPFcRKvUqASZtunCU). Nothing landed. The premise is falsified: the writer is outside packages/cli, and the second write is a LOST UPDATE, not a duplicate. Card → pm:queue + pm:retriage for a re-route; assignee cleared; ⛔ domain:* left for triage.

_{domain:cli seat · 2026-10-07T16:51Z}

What the dev measured (os-dev-report 6042611356, on origin/main bafb58bb, with no code change). The seat re-read the two code facts on main.

• Reach: reproduced on 7 of 7 first boots: 5 on :memory:, 1 on file-backed SQLite and 1 on PostgreSQL 16. A second boot of the same database prints 0.
• Not a packages/cli writer. Five sys_migration inserts happen per first boot. adr-0104-file-references, adr-0104-value-shapes (from attestFreshDatastore) and adr-0093-membership-backfill come once each. adr-0093-default-org-owner-bind comes TWICE. Both come from packages/plugins/plugin-auth/src/default-org-bootstrap-once.ts (createEnsureDefaultOrganizationOnce), through recordLedgerDecision → persistLedgerDecisionRow. serve.ts and the CLI migration plugins write each of their ids once. The seat's H2 reading is falsified.
• Why twice: the gate re-enters itself. Read on main: decided is set only after await ensure(...) returns. Measured chain, outermost first:
  • the outer owner-bind call writes sys_member;
  • the security plugin's middleware grants org-admin (sys_user_permission_set);
  • plugin-auth's middleware runs runEnsure again;
  • the inner call reads decided=false and ledger absent, and records first.
• Lost update:
  • The inner call records { outcome: 'admin-already-member' }.
  • The outer call's accurate record, { outcome: 'bound', organizationId }, is refused with UNIQUE. recordLedgerDecision's catch re-reads, finds a row and returns true silently (membership-backfill-ledger.ts, the catch branch).
  • The persisted row (read back on file SQLite and PostgreSQL) names the wrong outcome and has no org id. sys_member holds the admin as owner of the one org created that boot; nothing is double-bound.

Where it belongs: packages/plugins/plugin-auth, a domain:services package. The order's stop condition held: "If the second insert is issued outside packages/cli, stop and report: that is a re-route."

The dev's recommended fix (A), for the receiving lane to rule on. ⛔ Not a ruling.

• In createEnsureDefaultOrganizationOnce, mark the decision in flight synchronously, before the first await. A call that finds it in flight (the re-entrant inner one, or a concurrent trigger) runs ensure(ql, { bindOwner: false }) and records nothing. The deciding call records its own outcome once, and clears the mark if it did not act.
• Rejected: B, a promise chain like the backfill's, which would deadlock (the inner call runs inside the outer call's awaited insert). C, an idempotent or insert-if-absent ledger write, which keeps the wrong row or is the catch-all triage banned.
• Pins it names:
  • no sys_migration warn at boot;
  • the persisted details read bound with the organizationId that sys_member points at;
  • a real ledger insert failure still reaches recordLedgerDecision's error branch (control).

Not measured, carried to the receiving lane:

• The walled posture calls the same gate (@objectstack/organizations, organizations-plugin.ts:516).
• Reach outside dev mode: the measured chain starts from the dev admin maybeSeedDevAdmin seeds, and a production first sign-up was not measured.

Housekeeping: the pushed branch claude/issue-22099-sys-migration-boot-double-insert carries no commits (it equals bafb58bb), and no PR exists.