fix(service-automation): get_record names id in the projection it hands the engine, so output.id is the row id whatever fields names

[objectstack-fleet]

Fixes #22344

Clause-②: no

A get_record node's single-row (findOne) branch answers output: { record, id, object }, and a later node reads that id as {read.id}. The node handed the author's fields to the engine unchanged, and the SQL drivers return exactly the columns a projection names, so a projection without id answered output.id undefined with no error. The branch now names id in the projection it hands the engine.

Measured first: the defect is real on main (H1)

Measured on origin/main 35afb1587 plus the red-first test commit 4abddae9a, through the real ObjectQL (ObjectKernel + ObjectQLPlugin) and the registered get_record executor, runAs: 'system', one row { title: 'alpha', status: 'open' }:

driver	fields	output.id	record keys
driver-sql (better-sqlite3 :memory:)	['title']	undefined	[title]
driver-sql	absent	the row id	all 10 columns, id included
driver-memory	['title']	the row id	[id, title]
driver-memory	absent	the row id	all 5 columns

The memory row is the contrast: its projectFields adds id to every projection itself, so the defect showed on the SQL drivers only. The flow-level shape the card names was red too: start → get_record(fields: ['title']) → update_record(filter: { id: '{read.id}' }) was refused with update_record: refusing to run — 1 filter condition(s) resolved to nothing and were dropped from the query: {read.id} (at id).

Where id is added (H2)

projectionNamingId(fields) in builtin/crud-nodes.ts returns the author's fields with id appended, and the findOne branch hands that to serveFamilyRead as the node's projection:

• a projection that already names id is handed over as written, so id is never doubled;
• fields absent or [] is returned unchanged, so a whole-row read stays a whole-row read and no projection is invented;
• the find branch (limit > 1) does not call it and is byte-unchanged.

Placement, measured: adding id before serveFamilyRead (shipped) and adding it inside the projection callback (fields: projectionNamingId(projection), a one-off mutation, not committed) give the same answers on both paths, 23/23 across the three get_record suites at f6e3ac4ba. On the stored-metadata path the family projection only adds and then drops type, and id survives either way. Before serveFamilyRead is the shipped form so that the family door sees the node's whole projection as the node's own, instead of a column it does not know about arriving after it decided.

record carries id when the author did not name it (H3)

The record the node serves, and binds to its outputVariable, carries the id the engine returned beside the named columns. The reasons:

• the engine returned it, and taking it back off would be a second projection layer over the engine's answer;
• {rec.id} through the outputVariable then agrees with {read.id}; stripping it would leave the same defect on the variable spelling, which an author is as likely to write;
• every other single-row read already carries it: an unprojected read on every driver, and every projected read on driver-memory (table above).

Two existing pins asserted the exact column set on the single-row branch, and each now expects the named columns plus id:

• get-record-stored-metadata-family.integration.test.ts: the body-without-type projection now serves [checksum, id, metadata, name], and type is still taken back off;
• get-record-formula-projection.integration.test.ts, which landed with PR fix(objectql): a find/findOne projection that names a formula field returns that projection, not every stored column #22337 while this branch was open (merged in from origin/main 54c3ce10c): the one branch cases now include id: 'line_1', and the list branch cases are unchanged. That PR's engine-level trimming is untouched. Its fields projection is now handed to the engine with id named, which the trim honours.

Pins (H4), get-record-id-projection.integration.test.ts

• control: the SQL driver returns exactly the named columns ({ title: 'alpha' });
• fields omitting id: output.id is the row id, record is { id, title }, and the engine was handed ['title', 'id'] (red on main);
• fields naming id: handed as written (['id', 'title']), so id appears once;
• control, no fields and fields: []: no projection is invented, and output equals { record: WHOLE_ROW, id, object } with the engine's own whole-row answer as WHOLE_ROW;
• flow level: update_record filtering on {read.id} after a narrowed get_record closes exactly that row, and rec is { id, title } (red on main).

Ablation, one-off, after the fix was committed (no permanent mutation file)

Each leg was run through scripts/ablation-replace.mjs in wrap mode. Each anchor hit once, the mutation was verified on disk (anchor count and blob hash), and the restore was proven: the blob equals HEAD (94641f32745d) and git diff HEAD is empty, with a belt trap on EXIT INT TERM. The subject is imported from source (./crud-nodes.js), so no dist/ leg applies. Final run at f6e3ac4ba over the three get_record suites:

leg	mutation	result
M1	return [...fields, 'id'] replaced by return fields (fix reverted)	7 red: omit-id, flow {read.id}, family projection, and the 4 formula one cases
M2	the fields.includes('id') guard dropped	1 red: id-named, handed ['id', 'title', 'id']
M3b	the fields.length === 0 guard dropped	1 red: empty control, handed ['id']
M4	absent fields answered ['id']	6 red: no-fields control plus 5 whole-row reads in the family suite
H2-alt	id added inside the callback instead	23/23 green (a placement measurement, not an ablation)

The first M3 attempt at d6ccba323 was a no-op. Its replacement text was a substring of its anchor, so ablation-replace refused it (replacement count 1 to 1) and never ran the tests. It was re-anchored as M3b and run.

Verification

• pnpm --filter @objectstack/service-automation exec vitest run --maxWorkers=2 at f6e3ac4ba: 178 files / 2177 tests passed. At d6ccba323, before the merge, it was 177 / 2169.
• pnpm --filter @objectstack/service-automation run typecheck at f6e3ac4ba: tsc --noEmit clean. check:test-typecheck OK, 0 files / 0 errors; tsconfig.test.json includes src/**/*, so the new test is compiled.
• f68b7d55c changes only the changeset's wording against f6e3ac4ba (git diff --stat: one file, .changeset/).
• Targeted eslint (--no-inline-config, --format json) on the 4 changed .ts files: 4 files, 0 errors, 0 warnings. All 4 fall under the packages/**/*.{ts,…} config objects (--print-config resolves each). The config enables no type-aware linting (no parserOptions.project, per eslint.config.mjs), so this diff cannot move a verdict on an untouched file. The repo-wide pnpm lint is CI's.
• Gate families: 64 families derived by node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (no paths) at f68b7d55c; all 64 run there and all 64 exited 0. --ran reconciliation: 64 derived famil(ies) accounted for — 64 run, 0 NOT-MEASURED (a DERIVED zero — all 64 recorded an exit code and none of them is 3). The first pass at d6ccba323 read check:dual-build-cjs-loads as PREREQUISITE NOT MET (no workspace dist/). After this package was built it passed: 106 published require entry point(s) across 66 package(s) load. CI's own jobs were not run locally: Test Core, Dogfood, Temporal, Build Core, the workspace type-check lanes, and the roster and wide-population families that dispatch-gates names outside its 64.

Acceptance notes

• GetRecordConfigSchema.fields (spec) and the descriptor's configSchema describe fields as "only these fields are read (default: all)". On the single-row branch the served record now also carries id. packages/spec is outside this card, and the descriptor carries the same sentence as the spec, so neither was edited. A wording follow-up would name id there. Owner: none; domain:services seat to decide.
• The find branch (limit > 1) declares no top-level id. Its rows still carry only the named columns on the SQL drivers when fields omits id. That is the author's projection, and this PR leaves it unchanged by the card's scope.
• driver-mongodb was not measured, because the package's tests do not depend on it.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/service-automation, touching 2 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/permissions/system-context.mdx (via registerCrudNodes (symbol, a top-level function))

What this run could not see

• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 6 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json b7e01fbbd2c3340ae95e54e2ec220314e9ae728e → packageMentionDocs.

Which tree this was computed on

This run read content/docs from bd00bfb3d8924ddb8eb41ec2db55281f583fc946 — the merge of head f68b7d55c5d8390c5dbd136014423cdcc85d2dd1 into base b7e01fbbd2c3340ae95e54e2ec220314e9ae728e, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin bd00bfb3d8924ddb8eb41ec2db55281f583fc946 && git checkout bd00bfb3d8924ddb8eb41ec2db55281f583fc946
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin b7e01fbbd2c3340ae95e54e2ec220314e9ae728e f68b7d55c5d8390c5dbd136014423cdcc85d2dd1 && git checkout -B drift-repro b7e01fbbd2c3340ae95e54e2ec220314e9ae728e && git merge --no-ff f68b7d55c5d8390c5dbd136014423cdcc85d2dd1

node scripts/docs-audit/affected-docs.mjs --json b7e01fbbd2c3340ae95e54e2ec220314e9ae728e

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs b7e01fbbd2c3340ae95e54e2ec220314e9ae728e → pass the list as
args.docs, on the commit named under Which tree this was computed on.