[finding] os migrate value-shapes --object … --apply records the DEPLOYMENT-level flag from a scan of only the named objects; a misspelled name scans nothing and still records "verified"

[objectstack-fleet]

Filing gate: ① a product defect with reach measured. reach: public door + wrong answer, measured once (below). Filed by the domain:cli seat (seat post #6024, session_016GiHYRmLSNWTfbX9gVQkpz), from the out-of-scope findings of #21573's os-dev report (5974434894). ⛔ Not a claim. Triage sets the grade and the lane.

Reader who acts: triage grades it. The fix lands in the os migrate data-migration commands that take --object and record a deployment-level flag on --apply: packages/cli/src/commands/migrate/value-shapes.ts, and by the same reading files-to-references.ts.

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

• 「value-shapes --object narrowed apply records deployment flag verified over partial scan, unknown --object silently filtered」: 13 hits. The nearest are migrate value-shapes: a lookup holding an embedded record object passes the scan — the exact case the ADR-0104 D1 gate exists to find #4455 (the D1 lookup-object case, closed) and migrate value-shapes: the finding detail for a legacy {latitude, longitude} location is the missing-pair error, not the latitude rename hint the schema carries #15490 (a finding detail, closed). Neither is this.
• 「adr-0104-value-shapes verified flag misspelled object name gatePassed true scannedObjects empty」: 8 hits. Again the nearest are migrate value-shapes: a lookup holding an embedded record object passes the scan — the exact case the ADR-0104 D1 gate exists to find #4455 and migrate value-shapes: the finding detail for a legacy {latitude, longitude} location is the missing-pair error, not the latitude rename hint the schema carries #15490, neither this.

Measured (by the #21573 dev, by hand, on a throwaway SQLite project at a tree whose value-shapes.ts equals main 3222c57404)

1. With one off-shape value stored (a lookup holding an expanded record object), os migrate value-shapes --json answers gatePassed: false with blocking: 1.
2. On the same database, os migrate value-shapes --object <a name the deployment does not declare> --apply --yes --json exits 0 and answers gatePassed: true with scannedObjects: [].
3. It records the deployment-level adr-0104-value-shapes flag as verified: verified_at is set and blocking is 0.

Read (PM, on main 3222c57404; not separately measured)

• In value-shapes.ts, --object narrows the scan (scanValueShapes(…, { objects: flags.object })). The --apply branch then calls recordDataMigrationRun with migrationId: VALUE_SHAPES_MIGRATION_ID and passed taken from that narrowed report. Nothing conditions the deployment-level write on the scan having covered the deployment.
• So the class is not limited to a misspelling. Any --object subset that passes records the flag for the whole deployment, over objects the run never read.
• The header comment says that flag, "never the platform version, is what turns strict enforcement of those classes on for THIS deployment."
• files-to-references.ts has the same shape: objects: flags.object, plus a deployment flag recorded on --apply (adr-0104-file-references). Read only, unmeasured.
• The family drops an unknown --object name silently, with no refusal, in value-shapes, files-to-references, summary-nulls and duplicates (per the same report). Unmeasured here beyond the case above.

Why it matters: the flag is the deployment's attestation that its stored data passed the gate, and it turns strict enforcement on. A narrowed run, or a typo, attests to data nobody scanned. That is a wrong answer at an operator door, and the opposite of the command's own rule that "a deployment whose data has regressed closes its own gate rather than coasting".

Candidate seams, which triage decides:

• A narrowed --apply records no deployment flag, or refuses --apply with --object altogether.
• An unknown --object name is refused (OBJECT_NOT_FOUND) across the family, rather than narrowing to nothing.

One closure card for the family is the report's recommendation, not single cards.

---

Generated by Claude Code

[objectstack-fleet]

Triage: first grade — bug · priority:p2 · domain:cli · area:devpath · pm:queue. A narrowed --apply never writes the deployment-level flag, and an unknown --object is an error across the family. This is the closing card for all four commands

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

Read now on main: packages/cli/src/commands/migrate/value-shapes.ts's header says the adr-0104-value-shapes flag, "never the platform version, is what" turns strict enforcement on for the deployment. Its --apply branch records that flag from a report narrowed by --object.

Why p2. It is a wrong attestation at an operator door: a typo or a subset records "verified" over data nobody scanned, and that turns enforcement on. Nothing is lost, but the deployment's gate is lied to.

Routing: packages/cli (os migrate), so domain:cli.

Ruling: one closure for the family (value-shapes, files-to-references, summary-nulls and duplicates), as the report recommends.

• A deployment-level flag is written only by a full-scope run.
  • An --apply narrowed by --object applies its fixes and records no deployment flag.
  • Its output says the flag needs a full-scope run.
  • ⛔ --apply --object is not refused outright, because operators fix one object at a time.
• An unknown --object name is an error, naming the name and the declared objects. ⛔ It is never silently narrowed to nothing.
  • This is a correctness fix for a wrong answer, not a new policy gate.
• The census comes first, over each command: which ones record a deployment flag, and which take --object. The pin lists all four.

Pins (enumeration across the four commands):

• a narrowed --apply records no deployment flag, and a full-scope --apply records it as today;
• an unknown --object exits non-zero with the named error;
• the measured repro (an off-shape value plus a misspelled --object --apply) leaves the flag unverified.

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 1 (serial behind #21573, whose PR #21643 landed as 759dbe9ed3 on packages/cli/src/commands/migrate/)
Session: session_016GiHYRmLSNWTfbX9gVQkpz
Account: os-bill (the seat's linked user as get_me answers it; the card's assignee)
Branch: claude/issue-21644-narrowed-apply-flag
Worktree: objectstack-issue-21644
Domain: domain:cli
Seat: domain:cli#1
File surface, per triage's ruling 5974774596 (one closure for the family; a deployment-level flag is written only by a full-scope run; an unknown --object is an error):

• The census comes first, over value-shapes, files-to-references, summary-nulls and duplicates: which ones record a deployment-level flag, and where (the CLI or its producer), and which ones take --object.
• packages/cli/src/commands/migrate/{value-shapes,files-to-references,summary-nulls,duplicates}.ts:
  • an --apply narrowed by --object applies its fixes, records no deployment flag, and says the flag needs a full-scope run;
  • an unknown --object name is an error that names it and the declared objects.
• Declared cross-lane path (domain:services): packages/services/service-storage/src/files-to-references-migration.ts. files-to-references' flag is recorded there (recordDataMigrationRun), so its narrowed-run skip lands at the producer. That path only. The declaration is on seat post [PM seat] domain:services · seat 2 — ⏳ vacant #21118 in this act.
• Pins, an enumeration across the four commands:
  • a narrowed --apply records no flag, and a full-scope --apply records it as today;
  • an unknown --object exits non-zero with the named error;
  • the measured repro (an off-shape value plus a misspelled --object --apply) leaves the flag unverified.
• .changeset/.

⛔ No packages/objectql edit: the scanners (scanValueShapes, backfillSummaryNulls) keep their objects filter, and the refusal of an unknown name is decided in the CLI before the scan. If it can only land in the scanner, stop and report. ⛔ --apply --object is not refused outright. ⛔ No packages/platform-objects change to the flag ledger. (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: default (opus). A four-command closure with a census, and one producer leg.
Clause-②: no. A wrong attestation and a silent narrowing are corrected: the flag stops being written over objects a run never read, and a typo stops reading as a clean run. No accept set an author or a caller relies on moves; --apply --object still runs, and fixes still land.
Thread-read: 5974774596
Serial constraints, other open PRs read 2026-10-04T00:30Z on origin/main 759dbe9ed3:

• migrate: a sanctioned, operator-only read of unmapped (orphaned) columns for data conversion, before --allow-destructive drops them (the coupling #21571 names) #21573's PR feat(cli): os migrate unmapped-columns reads a retired field's columns, keyed by record id, for conversion before the destructive drop #21643 has LANDED (759dbe9ed3), which releases the seat's hold on packages/cli/src/commands/migrate/ and the two roster tests.
• No open PR touches packages/cli/src/commands/migrate/, packages/services/service-storage/src/ or the scanners in packages/objectql/src.
• This seat's other claim, [Decision] security(runtime): may an app-authored body still READ the stored-metadata family's tables, served projected, or is that refused too (#21454 option C) #21594, is in packages/runtime only.

_{domain:cli seat · session_016GiHYRmLSNWTfbX9gVQkpz · 2026-10-04T00:30Z}

---

Generated by Claude Code

[objectstack-fleet]

os-dev-report
{
"issue": 21644,
"status": "done",
"branch": "claude/issue-21644-narrowed-apply-flag",
"pr": "#21662",
"session": "session_016GiHYRmLSNWTfbX9gVQkpz (subagent: the parent PM session's id; container CLAUDE_CODE_REMOTE_SESSION_ID cse_016GiHYRmLSNWTfbX9gVQkpz)",
"premise_still_valid": true,
"summary": "Draft PR #21662 (head fe988c2, base 759dbe9) closes the os migrate data-migration family per triage ruling 5974774596. A run narrowed by --object applies its fixes and records no deployment flag: value-shapes skips its CLI write, the files-to-references producer (runFilesToReferencesMigration, the declared service-storage path) skips its write, and the files-to-references column step returns a stated narrowed_run skip. Both faces say why and name the full-scope command, and --json carries filter: {objects}. A full-scope --apply records exactly as before. An --object name the booted registry does not declare is refused before anything is read or written, on all four commands, with objectNotFoundError (OBJECT_NOT_FOUND), naming the unknown name(s) and the declared objects. A1 was reproduced at the public door on 759dbe9: a misspelled value-shapes --object --apply exited 0 and recorded the flag verified. The census also found that a misspelled or narrowed files-to-references --apply moved the deployment's media columns and stamped columns_moved_at on base; that is fixed here.",
"census": [
"value-shapes: --object repeatable; --apply records adr-0104-value-shapes in the CLI (recordDataMigrationRun, value-shapes.ts:221 at base); unknown name on base: exit 0, scannedObjects [], flag recorded verified with --apply",
"files-to-references: --object repeatable; --apply records adr-0104-file-references in the producer (files-to-references-migration.ts:120) and then the column step's columns_moved_at (recordFileColumnMove, files-to-references.ts:472); unknown name on base: exit 0, both scans empty, flag recorded verified AND os21644_product.image moved and stamped",
"summary-nulls: --object repeatable; no deployment flag by design; unknown name on base: exit 0, fields [] on a dry run and on --apply",
"duplicates: --object single; no --apply, writes nothing; unknown name on base: exit 0, scanned [], filter {object: the name}"
],
"tests": "Builds: turbo build of @objectstack/cli^... VERDICT 0; service-storage rebuilt after the producer change, exit 0; cli build exit 0; repo build for the gate prerequisites VERDICT 0 (72 tasks, 71 cached). @objectstack/cli typecheck exit 0 at 80e5eda (no CLI file changed after). The cli unit project in full at 80e5eda: 255/257 files and 3742 tests passed, 29 skipped; the 2 remaining files (published-subpath-{console,hook-body}.pin) answered a not-built prerequisite, and after the cli build they passed (2 files, 29 tests). service-storage: typecheck exit 0, full suite 41 files / 633 passed at fe988c2. os migrate integration pins on built packages at 80e5eda: object-scope (new) plus the absent-database roster, 2 files / 59 passed; the one-shot family plus duplicates.integration, 2 files / 79 passed. Full pnpm lint (eslint . --no-inline-config) exit 0 at fe988c2, nothing printed. Ablation through scripts/ablation-replace.mjs in wrap mode, all legs re-run at fe988c2 with a trap restoring from HEAD. Leg 1a, the value-shapes CLI skip: anchor 'if (apply && !narrowed) {' 1->0, blob 9f241dc2->d3a5c236; 3 red / 17 green (both full-scope controls green); restored blob == HEAD, git diff HEAD empty. Leg 1b, the producer skip: same anchor 1->0, blob 1aa9fea2->d4bb5002; 4 red / 6 green (the 6 original pins, full-scope apply among them, green); restored. Leg 2, the refusal: anchor 'if (unknown.length === 0) return;' -> '>= 0', blob b78a88b4->9286a990; unit 3 red / 3 green, integration 10 red / 10 green (all 8 unknown-name pins across 4 commands, the human face and the repro red; every narrowed and full-scope pin green); restored. The CLI src is what the spawned run-dev.js loads: legs 1a and 2 went red while packages/cli/dist held an unmutated build. In the first round, one pin per leg in 1b and 2 was vacuous (a same-millisecond rewrite; duplicates asserted on a key its report never has). Both pins were strengthened before the re-run.",
"gates": "node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (no paths) derived 97 at fe988c2. All 97 ran there, each exit 0. --ran with exit codes: 97 derived, 97 run, 0 NOT-MEASURED, 0 UNRUN. An earlier round at 80e5eda had 3 PREREQUISITE NOT MET (exit 3: check:skill-examples, check:dual-build-cjs-loads, check:i18n-coverage; packages outside the CLI closure were unbuilt), cleared by the repo build. CI on fe988c2 at report time: 13 completed (0 failed), 19 in_progress.",
"line_budget": "n/a (no skills/** or governed ledger touched)",
"files_changed": [
".changeset/21644-narrowed-apply-flag.md",
"content/docs/deployment/cli.mdx",
"packages/cli/src/commands/migrate/duplicates.ts",
"packages/cli/src/commands/migrate/files-to-references.ts",
"packages/cli/src/commands/migrate/object-scope.integration.test.ts",
"packages/cli/src/commands/migrate/summary-nulls.ts",
"packages/cli/src/commands/migrate/value-shapes.ts",
"packages/cli/src/utils/migrate-object-scope.test.ts",
"packages/cli/src/utils/migrate-object-scope.ts",
"packages/services/service-storage/src/files-to-references-migration.test.ts",
"packages/services/service-storage/src/files-to-references-migration.ts"
],
"deviations": [
"A3 wording: the producer treats ANY objects (including []) as narrowed, not only a non-empty list. A scan handed [] walks nothing ([] ?? x is []), so a non-empty test would record a verified flag over an empty scan. A unit pin covers this. In the CLI, oclif gives undefined or a non-empty list, so the two readings coincide there.",
"Beyond the expected file surface, the files-to-references CLI also skips its deployment-wide column step on a narrowed run (narrowed_run). On base, a narrowed or misspelled --apply moved the media columns; and once the flag is skipped, its stamp (recordFileColumnMove requires a verified flag) would fail after the move. This is in the same file and the same defect class, and it is pinned.",
"duplicates' report_failed error document now spreads errorCodeFields(error), so the refusal carries code OBJECT_NOT_FOUND (an additive key on that error document).",
"A4: the error lists the declared registry set, not the covered subset, because computing the covered subset for value-shapes needs isScannableValueShapeField, which objectql does not export, and objectql is fenced. The declared set is also the accept set: a declared object the command has nothing to check on is not refused. 12 names on the fixture boot.",
"origin/main gained 4 commits (f40bb32..1a23054) after verification and before pr_create. None touches this diff's paths, so they were not merged (AGENTS 10's pre-PR pull is noted as not done); CI runs on the merge ref.",
"Two early lock calls sequenced their parts with ';' (VERDICT batch-last-exit); each part's own exit was printed and is what is cited above.",
"pgrep -f was used once, read-only, to find the PID of my own gate runner (I had not echoed it); I verified the PID from the full ps line before waiting on it. Nothing was killed.",
"Commit trailers are model-free per the dispatch (Co-Authored-By: Claude), overriding the harness reminder's model-named form."
],
"mcp_calls": "0",
"api_writes": "3 relay writes, each one repository_dispatch executed by fleet-write.yml as objectstack-fleet[bot]: (1) pr_create POST /repos/objectstack-ai/objectstack/pulls -> #21662 draft, body read back byte-identical (16258 bytes); (2) label-write assign POST /repos//issues/21662/assignees os-bill, read back matches (bot labels documentation, size/l, tests, tooling were already present); (3) this os-dev-report comment POST /repos//issues/21644/comments. Plus git push to the branch (not REST).",
"open_questions": [],
"out_of_scope_findings": [
"carrier: none · noted, not filed: a narrowed run that finds a counterexample records nothing (as ruled), although one off-shape value disproves the deployment-level claim; the next full-scope run closes the gate",
"carrier: none · noted, not filed: the OBJECT_NOT_FOUND message lists every declared object, platform sys_* included; a deployment that composes many plugins prints a long list",
"carrier: none · noted, not filed: a narrowed value-shapes --apply still takes the plain DDL-performing boot, although it now writes nothing (unchanged)"
],
"cleanup": "worktree /home/user/objectstack-issue-21644 removed (node_modules deleted first; local head equaled origin branch fe988c2 and the tree was clean); no dev server or monitor started; background jobs were all waited to exit"
}

---

Generated by Claude Code

[objectstack-fleet]

ACCEPT — PR #21662 at fe988c20f0

_{domain:cli seat · session_016GiHYRmLSNWTfbX9gVQkpz · review of record, read on GitHub 2026-10-04T01:39Z}

What holds, read from the diff and the report (the comment before this one):

• A1 reach was reproduced at the public door on 759dbe9ed3: a misspelled value-shapes --object … --apply exited 0 and recorded the flag verified.

• A2 census, all four commands:

  • value-shapes writes its flag in the CLI;
  • files-to-references writes its flag in the producer (runFilesToReferencesMigration), then stamps the column step;
  • summary-nulls records no flag;
  • duplicates writes nothing.

  On base, each one silently narrowed an unknown name to nothing.

• A3, the narrowed-run skip.

  • value-shapes skips its CLI write, and the declared producer skips its write when it is handed objects.
  • Both faces say why and name the full-scope command, and --json carries filter: { objects }.
  • A full-scope --apply records exactly as before; its controls stay green under ablation.
  • ⛔ --apply --object is not refused, as ruled.

• A4, unknown --object. One helper (utils/migrate-object-scope.ts) refuses it on all four commands, before anything is read or written. It uses feat(cli): os migrate unmapped-columns reads a retired field's columns, keyed by record id, for conversion before the destructive drop #21643's envelope (objectNotFoundError, OBJECT_NOT_FOUND) and names the unknown name(s) and the declared set. No new code, and no packages/objectql edit.

• A5, ablation. Three legs, each blob-proven, with a clean restore:

  • the value-shapes skip: 3 red;
  • the producer skip: 4 red;
  • the refusal: 3 + 10 red.

  The full-scope controls stay green. Two first-round vacuous pins were found and strengthened before the re-run, and the report says so.

• Gates: 97 of 97 derived, run and green. Full pnpm lint exits 0. The CLI unit project ran in full, the service-storage suite ran in full (633), and the os migrate integration pins ran on built packages.

Deviations, dispositioned:

• An empty objects list counts as narrowed in the producer: accepted. [] walks nothing, so no flag may come from it. It is pinned, and the CLI never passes [].
• The files-to-references column step skips on a narrowed run (narrowed_run): accepted. It is the same defect class in the same file. On base, a narrowed or misspelled --apply retyped every media column in the database on a partial gate. And once the flag is skipped, the stamp would have failed after the move. It is pinned.
• The declared set is listed, not the covered subset: accepted. That set is the accept set, and the covered subset would need an unexported objectql predicate behind a fence.
• duplicates' report_failed document gains code: accepted. It is an additive key on an error document.
• No main merge after 4 unrelated commits: accepted. No path overlaps, and the queue rebuilds on main.

Cross-lane: the service-storage path was declared on seat post #21118 (5975014010). No objection had been posted at review time.

Clause-②: no stands as the claim declared it. The changes correct a wrong attestation and a silent narrowing, so no accept set an author or caller relies on moves, and no contract review is owed. Next: the landing checks once every check run on the head has completed.

---

Generated by Claude Code