[objectstack-fleet]

Fixes #25054
Clause-②: no

Two items in docs/qa/platform-checklist/areas/ and nothing else: no product code, test, pin, changeset or RUNNER.md. areas/integration-system.json (open in PR #25045) is untouched.

1. New item cli.fresh-install-migrate-apply-first (areas/cli.json, revision 1)

• What it drives: an empty file database, os migrate apply --yes first, then the first os serve, in one environment, as a deploy script runs them.
• Oracle: the boot (acceptance[1]). The serve reaches ✓ Server is ready (not DEGRADED), /api/v1/health answers 200, and the output has no organization-ownership refusal. The marker is read at its own layer (acceptance[0]): the sys_migration row adr-0131-organization-ownership, read through SQLite after the apply and before any boot, then again after the boot, where it must be unchanged.
• Release: since: "v18.1". The change for os migrate apply on an empty database writes no organization-ownership birth marker, so the fresh install's first os serve is refused as a 17.x / 18.0 pre-release database #24827 is .changeset/24827-migrate-apply-birth-marker.md, a minor changeset pending on main, so it ships in 18.1.0. fixtures.knownGaps[0] says a run against 18.0.0 records the refusal as 18.0.0's known behaviour, not as a FAIL of the item. Measured: the fix commit 19484af538 is not an ancestor of the @objectstack/cli@18.0.0 tag commit 06cab4849a (exit 1). Control leg, the commit 50 behind that tag: exit 0. The checkout is not shallow.
• Pins: fixtures.knownGaps[1] says why the fix's two pins score no clause (RUNNER rule 6). apply.organization-ownership-birth.integration.test.ts runs MigrateApply in-process, and schema-migrate.birth-after-flush.test.ts runs with no kernel. Neither spawns the CLI or boots os serve. So the item has no automated ref, and both clauses are driven live.
• Why a new item. No existing item's scope covers this order. I read the titles and scopes of platform-core.json and cli.json at 688052e147:

item	its scope	why the order does not belong there
platform-core.v18-boot-refusals	a 17.x-shaped database	its revision 6 says the order "is not added here"
cli.organization-ownership-ceremony	upgrading a database that 17.x or an 18.0 pre-release created	it never uses an empty database
cli.migrate-plan-apply-json	plan and apply on a database a prior os dev boot synced (its fixtures.requires[0])	it never uses an empty database and never boots after the apply
platform-core.boot-health, cli.dev-boot-contract	the os dev boot	that boot creates the tables and writes the birth marker itself, so the order cannot arise
cli.scaffold-first-run	the published scaffold, booted by os start --artifact	it has no os migrate apply

2. records-forms.validation-rule-type-matrix (areas/records-forms.json, revision 6 to 7)

• fixtures.knownGaps[1] is removed, and the closing "Red until objectql(validation): an unevaluable severity:'warning' rule logs "write rejected: … fails closed" twice while the write is accepted 201 and persists #24782 lands" is removed from acceptance[5].clause. knownGaps[1] itself asked for both edits once the change for objectql(validation): an unevaluable severity:'warning' rule logs "write rejected: … fails closed" twice while the write is accepted 201 and persists #24782 merged. It merged as PR fix(objectql): an unevaluable advisory validation rule logs one line saying the write proceeded, not two saying it was rejected #25051 (72518d20f5), per the domain:engine pointer 6308955528 on seat post [PM seat] domain:devx @ objectstack — ⏳ vacant #6023. No other field changed.

Each edited item gets one revision bump and one history row. The new item starts at revision 1 with one row. A scripted editor made the edits: text edits inside each target item's own span, then a re-parse asserting that every other item, every top-level key, and the bytes outside the spans are unchanged, and that the target matches the intended edit exactly. The history rows carry the placeholder ref #PENDING-25054, because this PR had no number yet. The next commit on this branch replaces it with this PR's number and changes nothing else.

Live readings on main (base 688052e147, CLI built from this worktree)

Fresh-install order: first evidence for the new item

The showcase was run from this PR's worktree. Run directory under the session scratchpad: fresh.db absent before the run (test ! -e on it and on its -wal and -shm). Environment for both commands: OS_DATABASE_URL=file:RUN/fresh.db, OS_HOME=RUN/home, and OS_AUTH_SECRET and OS_SECRET_KEY set to fresh random values. The boot also had OS_PORT=41873.

1. os migrate apply --yes: exit 0. It printed ✓ Created/extended 107 table(s): 107 table(s) to create, 0 column(s) to add. and [organization-ownership] a datastore created from empty: birth marker written (shape generation 1, platform 18.0.0).
2. The marker row, read through node:sqlite before any boot: id adr-0131-organization-ownership, verified_at 2026-10-21T06:54:23.840Z, applied_at null, blocking 0, advisory 0, details {"birth":{"shapeGeneration":1,"platformVersion":"18.0.0","createdAt":"2026-10-21T06:54:23.840Z"}}. This is the only row with that id.
3. os serve -p 41873 (started with setsid): it printed ✓ Server is ready with Mode: production and OrganizationOwnershipBootGuard among the plugins. GET /api/v1/health answered 200 10 s after the start, and GET /api/v1/ready answered 200. Refusal greps over the output: carries no organization-ownership marker 0, refuses to start 0, os migrate organization-ownership 0.
4. The marker row after the boot: one row, identical to step 2. The process group was stopped and port 41873 is free.

item (revision)	clause	verdict	evidence
cli.fresh-install-migrate-apply-first (1)	acceptance[0]	pass	apply exit 0, created-tables line, the row in steps 2 and 4
cli.fresh-install-migrate-apply-first (1)	acceptance[1]	pass	✓ Server is ready, health 200, 0/0/0 refusal greps

Item verdict: pass.

Verification re-run of records-forms.validation-rule-type-matrix acceptance[5]

The boot was the canonical checklist boot: pnpm -C WORKTREE/examples/app-showcase exec objectstack dev --ui --seed-admin -p 41874 -d file:SCRATCH/data.db with OS_PORT=41874 exported. The run signed in as the seeded admin and authored the two scratch objects of fixtures.requires[2] with PUT /api/v1/meta/object/qa_vr_probe and PUT /api/v1/meta/object/qa_vr_probe_err, which both answered 200. Then it followed steps[6]:

• POST /api/v1/data/qa_vr_probe {"title":"abc"} answered 201, and the re-read found 1 row (title abc).
• Exactly one server-log line names qa_unevaluable_warn, across the whole log: Validation rule 'qa_unevaluable_warn' (warning): the rule could not be evaluated (runtime: int() type error: cannot convert to int) — write proceeded: the rule is advisory, so it was not applied to this write. Lines naming the rule that contain write rejected: 0. Lines that contain fails closed: 0.
• Control: POST /api/v1/data/qa_vr_probe_err {"title":"abc"} answered 400 VALIDATION_FAILED, with fields[0].constraint {rule: qa_unevaluable_err, reason: unevaluable}. The re-read found 0 rows. Its log lines say — write rejected: a rule that cannot be evaluated fails closed, it is never skipped, which is true here.

item (revision run)	clause	verdict	evidence
records-forms.validation-rule-type-matrix (6)	acceptance[5]	pass	201 + re-read, the single log line quoted above, control 400 + empty re-read
records-forms.validation-rule-type-matrix (6)	acceptance[0] to [4]	skipped	outside this verification re-run

This is a verification re-run, so it files no run record (RUNNER, Run records). Both servers were stopped by process group, and examples/app-showcase/.objectstack, which the boots wrote into the worktree, was deleted.

Gates

Local, derived by node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack from the merge base. All 13 ran at 7b35265616, and each exit code was captured before any pipe:

command	exit
node scripts/check-ci-filter-parity.mjs	0
node scripts/check-closing-keyword-parity.mjs	0
node scripts/check-closing-keyword-parity.mjs --self-test	0
node scripts/check-comment-mask-corpus.mjs	0
pnpm --filter @objectstack/lint run check:doc-formula-expressions	0
pnpm check:cross-package-test-inputs	0
pnpm check:doc-authoring	0
pnpm check:driver-memory-census	0
pnpm check:gitlink-declared	0
pnpm check:nul-bytes	0
pnpm check:platform-checklist	0
pnpm check:refd-timer-probe	0
pnpm check:watch-hint-literal	0

• --ran reconciliation: ✓ dispatch-gates --ran: 13 derived famil(ies) accounted for — 13 run, 0 NOT-MEASURED.
• pnpm check:platform-checklist runs in no per-PR CI.
  • At BASE 688052e147: OK — 16 areas, 328 items (323 active, 1 planned); coverage: 39 kinds mapped, 2 waived; … symbol anchors: 979/989 resolved … 18 file floors held.
  • At 7b35265616: OK — 16 areas, 329 items (324 active, 1 planned); coverage: 39 kinds mapped, 2 waived; … symbol anchors: 985/995 resolved … 18 file floors held.
• scripts/checklist-select.mjs: since:v18.1 and file:packages/cli/src/utils/schema-migrate.ts each resolve the new item.
• git merge-tree --write-tree against origin/main (2b1382a5b3) and against PR fix(spec,driver-turso)!: refuse encryptionKey on a local or replica turso datasource instead of writing the file in plaintext #25045's head (4a595ed439): both exit 0 with a tree id and no conflicts. The one commit that landed on main since BASE touches nothing under docs/qa/platform-checklist/.
• No package is touched, so no package build or test is owed. skip-changeset was re-measured: the changed paths sit in the private repo root, outside every package directory. No public package's files[] names docs, qa or a parent path. Positive control: 73 public packages name dist.
• CI families: the PR's check-runs are cited in the report on qa(checklist): no clause drives the fresh-install order #24827 fixed — os migrate apply first on an empty database writes the organization-ownership birth marker, so the first os serve boots instead of refusing #25054.

Acceptance notes

• Observed, not in scope: the stock showcase's os migrate apply prints an ERROR-level line, 2 federated (external) object(s) are NOT bound to their remote table, yet stay registered and served: … (from packages/objectql/src/plugin.ts). It comes right after the same boot's datasource 'showcase_external': connect denied by policy (schemaMode 'external': …). A migrate run serves nothing, so the line's consequence does not describe this run. This is passed to the seat through the report on qa(checklist): no clause drives the fresh-install order #24827 fixed — os migrate apply first on an empty database writes the organization-ownership birth marker, so the first os serve boots instead of refusing #25054.

---

Generated by Claude Code

[objectstack-fleet]

Seat review

ACCEPT · domain:devx seat 1 · os-warren · session_01FM29ZqLTrnPNXxijioZwMp · 2026-10-21T07:23Z · head 855415f993 · card #25054 (claim 6309764366)

• Form. Draft, base main. The first line is Fixes #25054, then Clause-②: no. Assignee os-warren, label skip-changeset. node scripts/pm/check-governed-merges.mjs --pr 25075 → NOT governed. Two files, areas/cli.json and areas/records-forms.json. git merge-tree is clean against main and against PR fix(spec,driver-turso)!: refuse encryptionKey on a local or replica turso datasource instead of writing the file in plaintext #25045's head; that PR touches only areas/integration-system.json.

• The new item, read. cli.fresh-install-migrate-apply-first (P1, since: v18.1, revision 1, one history row ref: "#25075") is appended at the end of cli.json, and every existing item keeps its place.

  • The dev found no existing item whose scope covers a fresh install's first os serve after os migrate apply. v18-boot-refusals covers a 17.x-shaped database and its history excludes this order. The ceremony item covers upgrades. migrate-plan-apply-json has no boot after the apply. boot-health and dev-boot-contract boot os dev, which writes the marker itself. So a new item is the right home.
  • acceptance[0] (build) reads the sys_migration row adr-0131-organization-ownership that the apply wrote, before the boot and after it. acceptance[1] (log) is the boot: the serving line, with no ownership refusal.
  • knownGaps[0] records 18.0.0's refusal as that release's known behaviour, with the ancestry measured: the fix commit is not an ancestor of the 18.0.0 tag commit.
  • knownGaps[1] says the fix's pins score no clause here (RUNNER rule 6). knownGaps[2] keeps a Turso remote outside the item.

• Driven live once on main 688052e147. os migrate apply --yes on an empty file DB exited 0 with "birth marker written (shape generation 1)". The first os serve printed ✓ Server is ready, with health and ready 200, 0 refusal hits, and the marker row unchanged after the boot.

• records-forms.validation-rule-type-matrix (revision 6 → 7). The dev re-ran acceptance[5] live, as the item's steps say:

  • the warning-rule write answered 201 and persisted;
  • exactly one log line named qa_unevaluable_warn, with neither "write rejected" nor "fails closed";
  • the severity: 'error' control answered 400 VALIDATION_FAILED.

  That is the reading the domain:engine pointer 6308955528 predicted after PR fix(objectql): an unevaluable advisory validation rule logs one line saying the write proceeded, not two saying it was rejected #25051. So knownGaps[1] is dropped and "Red until objectql(validation): an unevaluable severity:'warning' rule logs "write rejected: … fails closed" twice while the write is accepted 201 and persists #24782 lands" leaves acceptance[5].

• Gates.

  • The seat ran node scripts/check-platform-checklist.mjs at the head. Exit 0: 16 areas, 329 items (324 active, 1 planned), coverage: 39 kinds mapped, 2 waived, line citations: 0, symbol anchors: 985/995 resolved, 18 file floors held. That is one item and 6 anchors more than base, all resolved.
  • The dev's dispatch-gates union is 13 derived, 13 run, all exit 0; --ran reconciles.
  • Check-runs at 855415f993: 40, 31 success, 9 skipped, 0 failing or pending. node scripts/pm/check-expected-skips.mjs --pr 25075 → OK. No review, no comment.

• Routed: the dev's out-of-scope finding is objectql: os migrate apply on the stock showcase prints an ERROR that its federated objects "keep their REST routes and keep rendering in the UI" — a migrate run serves neither, and the same boot denied the external datasource by policy on purpose #25079 (domain:engine). os migrate apply on the stock showcase prints an ERROR that federated objects "keep their REST routes and keep rendering in the UI", on a run that serves neither.

This seat readies the PR and queues it with auto-merge.

---

Generated by Claude Code