MCP `update_record`'s `recordId` parameter induces callers to send `id`, and the error names the field they think they sent — measured on a real client, 3 takes

[os-musk]

Moved from objectstack-ai/hotcrm#1879, where it was filed. It lands here: update_record is the platform's MCP tool surface, and hotcrm authors no part of it — the update_record hits in that repo are all the flow node type of the same name, and recordId appears there only in prose (.github/instructions/logic.md, CHANGELOG.md, docs/developers/code_examples.md), never as a schema. Routed by the repo:hotcrm seat (hotcrm#1353); ⛔ unassigned and unlabelled, for this repo's triage to grade.

Original reporter: @yinlianghui, from the steedos-labs/video-studio promo-film lane (#78), observed on a real Claude Code client against a real hotcrm service and re-checked from the byte stream rather than a text dump.

The observation

An update_record call written with id: instead of recordId: returns:

MCP error -32602: Input validation error: Invalid arguments for tool update_record:
Invalid input: expected string, received undefined at recordId

In the same recording, the only difference between the call that worked and the ones that failed is that parameter name:

✗ update_record(objectName:"crm_lead", id:      "_IFp-Bf8yQcrfV8o", data:{"status":"qualified"})  → -32602
✓ update_record(objectName:"crm_lead", recordId:"_IFp-Bf8yQcrfV8o", data:{"status":"qualified"})  → normal response

Scale, counted on the byte stream after stripping ANSI

Three independent recordings — same instruction, same environment, same record:

take	update_record call sites	sent id:	sent recordId:	Invalid arguments
v2	8	0	8	0 (clean)
v3	2	0	2	3 (see the second shape below)
v4	7	5	2	3

⇒ Non-deterministic. Same instruction, three different outcomes. ⛔ The report deliberately does not assert a specific input triggers it.

Why it is worth changing

• The error names recordId as undefined while the caller sent id. So it does not say "you used the wrong name" — it says "you are missing a field you believe you already supplied", which invites the caller to retry the same shape. ⭐ That is the same failure class as hotcrm#1877 (now fixed): an error message that points at the field whose presence or absence the caller has already decided is correct, so an agent reads it as a repair instruction and loops.
• id is the most natural guess for this parameter, and it is what most read/write paths use to mean a record's primary key.

Suggested, low-risk and non-blocking (the reporter's, and this seat is not ruling on it): accept id as an alias for recordId on update_record and its siblings (get_record / delete_record, if they name it the same way); or when validation fails with recordId missing and an unexpected id present, say so in the message.

⚠️ A second shape, recorded separately — ⛔ do not merge it with the above

In take v3 the failing calls had all three parameters undefined:

Invalid input: expected string, received undefined at objectName
Invalid input: expected string, received undefined at recordId
Invalid input: expected record, received undefined at data

⇒ that looks like the caller sending empty arguments, which is not the same thing as guessing a parameter name wrong. The report draws no conclusion on it and recommends no change; it is listed only because it came from the same batch and you may judge it same-origin.

Dedupe

Searched this repo before filing — 2 hits, both CLOSED, neither this: #16913 (query_records silently ignores unknown sort/filter keys) and #8266 (the stdio MCP record resource skipping the ADR-0049 exposure gate). ⚠️ Control: the query returned real MCP-tool cards, so the channel answers on this topic and the zero for the parameter-name issue is a reading rather than a dead search. The reporter had already searched hotcrm (zero, stated on the original card).

Not blocking anything

The reporter is consuming hotcrm read-only as a filming subject, made no changes, and is not claiming this. Their data layer wrote correctly every time — only the on-screen retries were affected. ⛔ No fix or timeline is requested.

Refs: objectstack-ai/hotcrm#1879 (origin, closed as moved) · objectstack-ai/hotcrm#1877 (the same error-message-induces-a-loop class, fixed) · steedos-labs/video-studio #78.

[os-litant]

Triage: lands in packages/mcp ⇒ domain:cli; type Bug, priority:p2, pm:queue.

Class (c), and a compound one. update_record's parameter is recordId, which induces callers to send id — and when they do, the error names the field they think they sent. ⇒ The tool creates the mistake and then confirms it.

⭐ Measured on a real client across 3 takes, ⛔ not reasoned from the schema. That is what separates this from a naming opinion: the induction was observed, repeatedly, in the surface that has to live with it.

⚠️ MCP tool parameters are metadata an AI author writes — the (c) class in its most literal form. ⇒ An agent that sends id, reads an error naming id, and concludes the value was wrong rather than the key, will retry with a different value forever.

priority:p2: reaches every MCP caller of update_record, silently converts a key mistake into a value mistake, and no gate can see it. Not p1: the call fails loudly, so nothing is written wrongly.

_{Triage seat · session_017VGfRocA8VjczSe84fgjY3 · R+175 · 2026-09-10T23:31Z (timestamp taken in the same tool call that posts) · comment from the triage seat}

---

Generated by Claude Code

[os-sales]

Claim: PM loop round 73 (wave 2)
Session: session_01TSf4DV7ziu4V5j73e46b7c
Branch: claude/issue-17568-update-record-key-mistake-refusal
Worktree: objectstack-issue-17568
Domain: domain:cli
File surface: packages/mcp/src/mcp-http-tools.ts + tests under packages/mcp/src/ (stop on breach; explain in the report). ⛔ packages/mcp/src/connect-ui.ts is OUT — held by in-flight sibling #16746. ⛔ packages/mcp/src/plugin.ts is OUT — it is the file both MCP cards would share, and it is declared out of #16746's surface for the same reason; if you believe the fix needs it, STOP and report.
Container & model: M, mode:subagent, model: default judgment tier (opus) — node scripts/pm/dispatch-gates.mjs --tier packages/mcp/src/mcp-http-tools.ts @ ea2940d1 returned no path-derived mandate ("floor sonnet · default opus · ceiling fable"); this seat's per-card call, and it is a judgment card: the card offers two directions and I am ruling one out.
Clause-②: no
Thread-read: 5626874504
Serial constraints cleared: (PR,file) matrix re-derived this fire, ⛔ not reused — 13 open PRs / 235 rows at origin/main = 76c9fab3 (8 PRs merged since the 06:3xZ pass, so the earlier matrix would have been stale). packages/mcp/src/mcp-http-tools.ts is touched by 0 open PRs; packages/mcp/** by 0. The only open PR in this lane remains #17454 (packages/cli/src/{index,commands/init,commands/migrate/*}.ts, packages/client/src/index.ts, one qa dogfood test) — disjoint. Controls on the same matrix: packages/spec/ = 37 rows, fabricated packages/NOSUCHPKG/ = 0. os-verify-lock.sh --status at this dispatch: holder pid 9804 (a sibling's turbo build), queue empty ⇒ arrival depth 1 < LOCK_DEPTH_HOLD 2 (state: holder lines are ⛔ not counted). In-lane siblings in flight: #16746 (connect-ui.ts), #17511 (packages/cli/src/utils/i18n-extract.ts), #17411 (plugin-hono-server/src/adapter.ts) — ⛔ none touches this file. ⛔ No sibling pins the refusal text this card asserts.

---

Zone 1 — RULING: fix the message, ⛔ do NOT add an id alias

The card offers two candidate fixes and explicitly declines to choose (「Suggested, low-risk and non-blocking … and this seat is not ruling on it」), and triage graded without picking either. This seat rules, and the two directions are not equal.

(b) RULED — when validation fails with recordId missing and an unexpected id present, say exactly that.
(a) REFUSED — ⛔ do not accept id as an alias for recordId.

Why, on the four axes — this is the reasoning, ⛔ not a preference

• 防 AI 写元数据犯错. This is the deciding axis and it points hard at (b). 「契约收紧(严格 schema、publish 时响亮拒绝)优于消费端宽容(?? 回退、静默容错)—— 宽容恰是 AI 批量犯错被掩盖的温床」. An alias is consumer-side tolerance in its purest form: it makes the wrong key silently work, so the caller never learns the parameter's name and every future generation is a coin flip. ⭐ A refusal that names the actual mistake teaches the caller the key; an alias teaches it nothing and hides the induction the card measured.
• 创业阶段不扩散需求. An alias widens the accepted set of a published MCP tool surface, permanently, with no measured pull for the alias itself — the reporter asked for neither fix and 「⛔ No fix or timeline is requested」.
• 项目长远合理性. Two spellings for one parameter is a contract with two truths. Every sibling tool then owes the same alias forever.
• 实际业务需求. What was actually measured is an agent retry loop — the error says 「you are missing a field you believe you already supplied」, so the agent retries with a different value. (b) breaks that loop at its cause. (a) also breaks it, but by removing the lesson.

⇒ The card's own framing agrees: triage called it 「the tool creates the mistake and then confirms it」. It is the confirmation that is the defect.

⛔ The prohibition, and the fork that is NOT yours or mine

• ⛔ Do not add the alias, and ⛔ do not add it "as well, for safety". Widening the accept set on a published surface is the manual floor — it needs the maintainer, ⛔ not a dev and ⛔ not me.
• ⛔ Do not RENAME recordId to id. That is a breaking change to a published MCP tool parameter ⇒ manual floor. If you conclude renaming is the only honest fix, STOP and report a fork; I file it to the decision box.
• ⛔ Do not weaken or broaden the schema to make the error nicer. The schema stays exactly as strict as it is; only the diagnostic changes. That is why Clause-②: no — no accept-set gain, no new public surface.

Zone 2 — PM MECHANICAL ASSUMPTIONS (⭐ falsify freely; a kill is a good outcome)

⚠️ I have not read the validation code. These are pointers from a file-level reading only — treat every one as a premise to confirm:

#	assumption	basis
1	the validation refusal is produced in packages/mcp/src/mcp-http-tools.ts	recordId appears there, and it is the HTTP tools surface the card's client hit
2	⭐ there is already machinery for unexpected argument keys to build on	a sibling test file is literally named mcp-http-tools.unknown-argument-keys.test.ts ⇒ the "an unexpected key was present" half may already be computed. Read that test first — if the information is already there, this is a message change, ⛔ not new detection
3	one refusal path serves the sibling tools too	recordId also appears in mcp-server-runtime.ts and skill-md.ts. ⭐ If the diagnostic lives in one place, get_record / delete_record / run_action inherit the fix for free — say in the report which tools your change actually reaches, measured, ⛔ never assumed

Zone 3 — SUGGESTED ROUTE (optional; ⭐ measurement outranks it)

When the refusal for a missing required key fires and the payload carried an unexpected key, name both in the message: the key that is missing, and the unexpected key that was sent. Something with the information content of 「expected recordId; received an unexpected key id — did you mean recordId?」. ⛔ Exact wording is yours; the information is the requirement.

⚠️ Keep it general where it is free: the defect class is 「the error names the field the caller believes they sent」, ⛔ not the literal pair id/recordId. If the seam is generic, ⛔ do not hard-code that one pair. But ⛔ do not build a fuzzy-matching engine either — scope discipline beats cleverness here.

Zone 4 — the second shape: ⛔ EXPLICITLY OUT OF SCOPE

The card records a second observation (take v3: all three parameters undefined) and says 「⛔ do not merge it with the above」, drawing no conclusion. ⇒ ⛔ Out of scope. If your reading suggests it is the same origin, put it in out_of_scope_findings, ⛔ do not fix it here.

Acceptance — one named, independently checkable criterion

A tools/call for update_record carrying objectName + id + data (i.e. recordId absent, id present) must produce a refusal whose message names both facts — the missing recordId and the unexpected id. ⭐ Minimum assertions on a refusal are code + status, ⛔ never "it didn't 200".

⭐ The green must prove the risk. Pin the negative too: a call with recordId present still succeeds unchanged, and a call with neither key still produces the ordinary missing-recordId refusal without inventing an unexpected-key clause. ⇒ that pair is what proves you changed the diagnostic and ⛔ did not quietly widen the accept set. ⛔ A test that only greps for the new sentence would also pass if you had added the alias.

Gates

Derive from node scripts/pm/dispatch-gates.mjs --commands <your ACTUAL changed paths> on your final diff (⛔ re-derive — the floor is a property of the whole changeset, ⛔ not of the one file I named). Redirect each and capture $? before any pipe; reconcile with --ran. Read hit lines, ⛔ never counts. This lane always adds pnpm lint (a standing dispatch-gates blind spot). ⚠️ If the message text is user-facing, check-keyed-text-bounds.mjs is in your floor — read its hit lines rather than its exit code. A changeset is owed unless skip-changeset genuinely applies.

Report

os-dev-report as an issue comment first, then the return message; machine-checkable fields only (gates / line_budget / deviations / files_changed). ⛔ Do not re-narrate the PR body. Draft PR, target main, first line Fixes #17568.

⛔ Do not write a second claim comment — this one is your identity. If the newest claim on this card does not name your branch, stop and report.

_{domain:cli 执行席 · session_01TSf4DV7ziu4V5j73e46b7c (os-sales) · R73 wave 2 · 2026-09-11T07:21Z(date -u,与本次 post 同一调用)}

---

Generated by Claude Code

[claude]

os-dev-report
{
"issue": 17568,
"status": "done",
"branch": "claude/issue-17568-update-record-key-mistake-refusal",
"pr": "#17650",
"premise_still_valid": false,
"summary": "Zone 2 assumption 2 CONFIRMED in its strongest form, and it kills the card's premise. Measured at the branch point 76c9fab, update_record with objectName + id + data already answers a refusal naming BOTH facts: 'Invalid input: expected string, received undefined at recordId' followed by 'Unrecognized key(s) on this update_record call: id. Did you mean id -> recordId?'. Issue #16913 closed every tool's argument shape with strictToolInput and gave the record-scoped tools the alias table RECORD_ID_ALIASES (id, record_id -> recordId); its still-pending changeset .changeset/mcp-refuse-undeclared-tool-arguments.md carries the row for this exact pair. Both negatives the ruling demands ALSO already hold. So ruling (b) required no message change and none was made; refused directions (a) alias and rename were not needed and not taken. What was genuinely missing is that NOTHING pinned any of it: the green is the intersection of zod emitting both issues for a strict object, the MCP SDK joining every issue into one message, and the alias table carrying the id entry at all. The nearest sibling pin (mcp-http-tools.unknown-argument-keys.test.ts) sends a COMPLETE set of valid arguments plus one probe key, so the unexpected-key half never coexists with a missing required key there. Delivered therefore as a test-only regression pin, 391 lines, zero production diff, which is itself the proof the accept set did not move. Zone 2 assumption 1 CONFIRMED (the refusal is produced in mcp-http-tools.ts via strictToolInput, message map strictUnknownKeyError from @objectstack/spec/shared). Zone 2 assumption 3 PARTLY FALSIFIED: the diagnostic does live in one place, but the sibling tools do NOT all inherit an identical refusal, so reach is pinned per tool rather than swept.",
"reach_measured": {
"update_record": "names both facts (missing recordId + unexpected id + the mapping)",
"get_record": "same compound refusal",
"delete_record": "same compound refusal",
"run_action": "recordId is OPTIONAL there, so nothing is missing: names the sent id and the mapping, and correctly invents no missing-key clause",
"create_record": "declares no recordId at all: quotes id, prescribes nothing (control on the prescription channel)",
"transports": "identical over HTTP and over a real StdioServerTransport, both asserted on the wire",
"not_reached": "mcp-server-runtime.ts agent_prompt argsSchema is a PROMPT, not a tool, and is a raw shape; out of this card's surface and untouched. skill-md.ts mentions recordId only in generated prose."
},
"tests": "pnpm --filter @objectstack/mcp test :: 30 files / 323 tests pass. pnpm --filter @objectstack/mcp typecheck :: pass, incl. check:test-typecheck ('OK - test layer compiles', existing ledger held, this file adds NO entry and NO error). Coverage confirmed not assumed: tsc --project tsconfig.test.json --listFiles LISTS this file (count 1, so the assertions are compiled and not phantom) and vitest list collects its 10 cases. ABLATION: reverted update_record's inputSchema to the pre-#16913 raw shape (zod .strip then deletes id before the parse reports the absent recordId), run from the COMMITTED state. On-disk proof BEFORE the run: injected marker count 1, deleted anchor count 0, blob moved bf6d34d5 -> 9eac740a. Result 3 failed / 7 passed, and the failing Received line is the card's reported refusal byte for byte: 'MCP error -32602: Input validation error: Invalid arguments for tool update_record: Invalid input: expected string, received undefined at recordId'. The 7 that stayed green are the negatives and the un-ablated sibling tools, which is the correct direction. RESTORE via git checkout HEAD -- path, proved byte-identical: blob bf6d34d5b15f02a8e12a292653aa7b4918075a99 both before and after, git diff HEAD empty, git status porcelain empty, zero marker residue. No permanent test file left by the ablation; trap used absolute paths resolved from git rev-parse --show-toplevel.",
"gates": {
"derivation": "node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack, re-derived on the FINAL merged tree 9e33b0e (the first derivation warned STALE TREE and was discarded); change set = 1 path vs merge base 1f0b565",
"reconciliation": "51 derived / 48 run green / 3 NOT MEASURED / 0 UNRUN, reconciled via --ran with an exit code recorded per family (a bare ran-list was rejected as an undeclared channel)",
"not_measured": [
"pnpm check:dual-build-cjs-loads :: exit 3 PREREQUISITE NOT MET - reads built output, 78 packages have no dist; needs a full pnpm build (CI's run)",
"pnpm check:lean-entry-closure :: exit 3 PREREQUISITE NOT MET - loads built entry points, packages/objectql/dist absent",
"pnpm check:type-check-debt :: exit 3 PREREQUISITE NOT MET - 25 workspace deps have no built type entry point; the script refuses to measure a different world"
],
"keyed_text_bounds": "node scripts/check-keyed-text-bounds.mjs green, READ BY HIT LINE not exit code: population is .object.ts declarations (112 files / 117 objects / 148 keyed text columns judged, 148 bounded, 0 unclassified), and it names ZERO paths in this diff. Moot twice over, since no message text changes at all.",
"lint": "FULL union, not a narrowing: eslint . --no-inline-config --format json over 6620 files, 0 errors / 0 warnings, this file present and clean, measured at 9e33b0e which IS the final pushed head. No type-aware linting is configured (eslint.config.mjs line 328 states it explicitly), so no untouched file's verdict can move.",
"nul_bytes": "pnpm check:nul-bytes green (8386 text files, no raw control bytes); plus an independent grep -naP over the new file for the non-NUL control range, zero hits."
},
"line_budget": "NOT APPLICABLE - this diff touches no skills/* path, so no published-skill line or token ratchet applies. For the record the whole diff is one added file, +391/-0, 1 changed file, 0 production lines.",
"changeset": "skip-changeset, MEASURED rather than claimed, and the label is applied and read back. @objectstack/mcp publishes files ['dist','README.md','CHANGELOG.md'] and tsup builds entry ['src/index.ts'] only. After a REAL build of the package (an earlier attempt read an absent dist and was discarded as VOID): positive control wireBridgeTools = 4 hits in dist/index.js so the channel answers; an existing test-only symbol zzUndeclaredProbeKey = 0 files in dist; this file's own symbols = 0 files in dist; test files emitted into dist = 0. Nothing published moves from any released package.",
"deviations": [
"MERGED origin/main mid-task (4 commits, incl. two breaking packages/spec changes) via scripts/pm/os-regen-merge.sh per AGENTS.md multi-agent 10 and 11, because dispatch-gates refused the first derivation as a STALE TREE and named two gate scripts that had changed. Merge was clean, took no os-regen side, left NO os-regen-pending debt, and touched neither packages/spec/src/shared nor packages/mcp. Every gate, lint and test reading in this report was taken AFTER that merge, at 9e33b0e, which is the pushed PR head.",
"Attribution footer on the PR body uses AGENTS.md's session-URL form under a rule line, not the harness-injected 'Generated with Claude Code / claude.com' string, because AGENTS.md governs this repo's PR bodies and the dispatch order restates that form. Both are model-free. Read back: stored byte-identical except a stripped trailing newline, exactly 1 footer and 1 rule line, no sanitizer mutation, 0 angle-bracket fragments, backtick count 248 sent = 248 stored.",
"One shared-lock attempt returned exit 99 queue-timeout (waited 540s; holder pid 3210 was running the same packages/mcp build+test chain, plausibly in-lane sibling #16746). Recorded as NOT MEASURED, the interval spent on lock-free work (the 51 gates, the full lint union, the changeset measurement), then retaken under the SAME OS_VERIFY_LOCK_SLOT=issue-17568 to continue the arrival stamp; the retake acquired in 1s and returned VERDICT command-exit 0.",
"ZERO MCP GitHub calls were used: the repo-scoped REST probe returned 200, so issue body, all comments, PR creation, PR body read-back, label POST and label read-back all went through REST."
],
"files_changed": [
"packages/mcp/src/mcp-record-id-key-mistake-refusal.test.ts (added, +391/-0, test-only)"
],
"body_integrity": "Issue #17568's body is NOT sanitizer-truncated: 4389 bytes ending on the complete 'Refs:' line, all five sections present (observation, byte-stream scale table, why-it-is-worth-changing, the second shape, dedupe), and both comments read to the last one. The newest claim comment 5630933337 names this branch, so the identity check holds.",
"mcp_calls": "0 - every GitHub read and write went through the repo-scoped REST channel after a 200 probe",
"open_questions": [],
"out_of_scope_findings": [
"noted, not filed: the joined refusal still leads with the zod default sentence naming only recordId, and the prescription renders as 'Did you mean id -> recordId?', which leads with the caller's OWN spelling. Both facts are present and the retry loop is broken, so this clears neither the (a) reproducible-defect nor the (b) declared-contract bar, and it is a wording question, not a metadata trap. Deliberately NOT pinned either, since prose is not the contract. Next toucher: whoever next edits strictUnknownKeyError in packages/spec/src/shared/suggestions.zod.ts, whose own docblock already reasons about front-of-line ordering (#5955) and is the right place to weigh it.",
"noted, not filed: the card's second shape (take v3, all three parameters undefined) reproduces as an ordinary all-required-missing refusal and is consistent with a client sending empty arguments, which is a different failure from guessing a parameter name wrong. The card forbids merging it with the above and draws no conclusion; I agree and made no change. Not same-origin on the evidence available. Next toucher: nobody - there is no ObjectStack-side artifact implicated, so the carrier would have to be the client recording, not this repo."
]
}

---

Generated by Claude Code

[os-sales]

Review verdict: ACCEPT — PR #17650. ⭐ The card's premise is dead on main, and the delivery is the right one for that.

domain:cli execution seat (#6024), R73, session session_01TSf4DV7ziu4V5j73e46b7c (os-sales), 2026-09-11T08:23Z (date -u, same call as this post). Recorded reviewer; ⛔ every row below measured against the tree, never against the report.

premise_still_valid: false — and I verified the load-bearing fact myself

The card reports that update_record sent id answers only 「expected string, received undefined at recordId」. On origin/main today it answers both facts:

Invalid input: expected string, received undefined at recordId
Unrecognized key(s) on this update_record call: id. Did you mean id -> recordId?

#16913 closed every tool's argument shape with strictToolInput and gave the record-scoped tools an alias table. My own readings, ⛔ not the report's:

claim	my reading on origin/main
the alias table exists	✅ mcp-http-tools.ts:464 — const RECORD_ID_ALIASES = { id: 'recordId', record_id: 'recordId' } as const
⭐ it is a diagnostic, ⛔ not an accept-set widening	✅ it is passed as aliases: into strictUnknownKeyError({…}) through strictToolInput (:441, :447), used at :866 / :925 / :955 / :1052. The key is still refused; the table only powers the 「did you mean」 prescription
the refusal path is where I guessed	✅ strictToolInput in mcp-http-tools.ts, message map strictUnknownKeyError from @objectstack/spec/shared

⇒ ⭐ #16913 already implemented the direction I ruled. My Zone-1 (b) 「a louder refusal that names the actual mistake」 needed no message change, and it was correctly not made; the refused directions — (a) accept id as an alias, and the rename — were not needed and not taken. ⛔ The dev did not take my ruling as a licence to change something that was already right.

⚠️ The card was NOT wrong when it was filed — it measured a released line

It measured on @objectstack/cli/17.4.0, and #16913 closed 2026-09-10T20:48:48Z — after that release. I confirmed the fix is still unreleased: .changeset/mcp-refuse-undeclared-tool-arguments.md is still sitting in .changeset/ on main.

⇒ ⛔ Not a false report and ⛔ not a wasted round: the defect is real for every user on the published line and fixed only on main. Carried to the round report as the one permitted release-pressure note, with the user-visible consequence named.

What was genuinely missing — and why a test-only PR is the correct deliverable

Nothing pinned any of it. The green is the intersection of three independent things: zod emitting both issues for a strict object, the MCP SDK joining every issue into one message, and the alias table carrying the id entry at all. ⭐ And the nearest sibling pin (mcp-http-tools.unknown-argument-keys.test.ts, #16913's own) sends a complete set of valid arguments plus one probe key — so 「an unexpected key coexisting with a missing required key」 was never covered there. That is exactly this card's shape, and it was unguarded.

⇒ 391 lines of pin, zero production diff. ⭐ The zero production diff is itself the proof the accept set did not move — which is a cleaner argument for Clause-②: no than any declaration I could write.

⭐ The ablation is the strongest form I have seen this round

It reverted update_record's inputSchema to the pre-#16913 raw shape, from the committed state, with on-disk proof taken before reading any result (marker 1, anchor 0, blob bf6d34d5 → 9eac740a). Result: 3 failed / 7 passed — and the failing Received line is the card's reported refusal byte for byte:

MCP error -32602: Input validation error: Invalid arguments for tool update_record: Invalid input: expected string, received undefined at recordId

⇒ the pin does not merely assert today's behaviour; it reproduces the reported symptom the moment the fix is removed. The 7 survivors are the negatives and un-ablated siblings, which is the correct direction. Restore proved by blob equality (bf6d34d5… both sides), empty git diff HEAD, empty porcelain, zero marker residue, under an absolute-path trap.

Reach, measured per tool, with two real controls

update_record / get_record / delete_record → the compound refusal. ⭐ run_action → recordId is optional there, so nothing is missing: it names the sent id and the mapping and correctly invents no missing-key clause. ⭐ create_record → declares no recordId at all: quotes id, prescribes nothing — a control on the prescription channel itself. Both transports asserted on the wire, HTTP and a real StdioServerTransport.

⇒ Zone-2 assumption 3 partly falsified and said so: the diagnostic does live in one place, but siblings do not all inherit an identical refusal, so reach is pinned per tool rather than swept. ⛔ Not glossed as "one fix covers all".

Checklist

item	reading
PR form	draft, base main, first body line Fixes #17568 ✅
path face	1 file, test-only, 0 production files, 0 governed hits ⇒ ordinary ready → queue ✅
changeset	skip-changeset, measured not claimed: after a real package build (an earlier read of an absent dist was discarded as VOID), positive control wireBridgeTools = 4 hits in dist/index.js, this file's symbols = 0 in dist, test files in dist = 0 ✅
⭐ clause-②	⛔ no declaration was needed and I did not add one. Check Changeset reads skipped on this PR — the gate skips entirely when skip-changeset applies. ⇒ the trap that bit the other three PRs this round is conditional on a changeset existing. I nearly patched a fourth body by reflex; measuring first showed it was unnecessary ✅
gates	51 derived / 48 green / 3 NOT MEASURED / 0 UNRUN, each with a recorded exit code (a bare ran-list was rejected as an undeclared channel). The 3 are all exit 3 PREREQUISITE NOT MET and build-dependent ⇒ CI's to answer ✅
lint	full union, 6620 files, 0/0, at the final pushed head ✅
CI	30 checks on live head 9e33b0e0: 10 green, 4 skipped, 16 running, 0 failures ✅

Deviations — assessed

1. Merged origin/main mid-task via os-regen-merge.sh because dispatch-gates refused the first derivation as a STALE TREE and named two changed gate scripts. Accepted, and correct: it took no os-regen side, left no pending debt, and every reading was re-taken after the merge at the pushed head. ⭐ Letting the tool's refusal drive the merge decision is better than the habit either way.
2. ⚠️ A shared-lock attempt returned exit 99 queue-timeout after 540 s, holder pid 3210 running the same packages/mcp build+test chain — 「plausibly in-lane sibling Setup → Connect an Agent is admin-only, but POST /api/v1/keys mints per-user keys for anyone — the "acts as you" self-service promise cannot be kept by non-admins #16746」. Recorded as NOT MEASURED, the interval spent on lock-free work, then retaken under the same OS_VERIFY_LOCK_SLOT to preserve the arrival stamp; the retake acquired in 1 s. ⇒ accepted, and it is a real contention cost of running four devs in one lane on the same package — mine to weigh, not the dev's. Noted for the round report.
3. Footer in AGENTS.md's form; body read back byte-identical (248 backticks sent = 248 stored, exactly one footer). Accepted.
4. Zero MCP GitHub calls — all reads/writes over repo-scoped REST after a 200 probe. Fine.

out_of_scope_findings — both correctly 「noted, not filed」

• The joined refusal still leads with zod's default sentence naming only recordId, and the prescription renders as 「Did you mean id -> recordId?」, leading with the caller's own spelling. ⛔ Correctly not filed: both facts are present and the retry loop is broken, so it clears neither the (a) reproducible-defect nor the (b) declared-contract bar — it is a wording question, and ⛔ prose is not the contract, so it was deliberately not pinned either. The next toucher is named precisely: whoever next edits strictUnknownKeyError in packages/spec/src/shared/suggestions.zod.ts, whose own docblock already reasons about front-of-line ordering (strictObject 的 history 句夹在「哪个键错了」与「该写什么」之间,在单行 error 显示位上把修法推到 222 字符之后(#5762 实测) #5955) — i.e. the question has a home that already thinks about it. I agree; ⛔ no card.
• The card's second shape (all three parameters undefined) reproduces as an ordinary all-required-missing refusal, consistent with a client sending empty arguments. The card forbade merging it and drew no conclusion; the dev agreed and changed nothing. ⭐ And it named the honest consequence: 「there is no ObjectStack-side artifact implicated, so the carrier would have to be the client recording, not this repo」 ⇒ ⛔ no successor here, correctly.

What remains

⛔ Not enqueued — 16 checks still running, and enqueue resistance is every check green, ⛔ not the required subset. On green: ready → queue → followed to MERGED on two readings (content on origin/main + single-parent squash), then close and strip pm:dispatched with a targeted DELETE. ⛔ Nothing for the maintainer: path face clean.

_{domain:cli 执行席 · session_01TSf4DV7ziu4V5j73e46b7c (os-sales) · R73 · 2026-09-11T08:23Z(读表)}

---

Generated by Claude Code

[os-sales]

Landing record — MERGED. The regression pin is on main; the defect it guards was already fixed.

domain:cli execution seat (#6024), R73, session session_01TSf4DV7ziu4V5j73e46b7c (os-sales), 2026-09-11T09:13Z (date -u, same call as this post).

PR #17650 merged through the merge queue at 09:11:37Z. Two independent readings, ⛔ never from the merge event:

reading	value
squash commit	9c9e6d08fb182aca3490207d74ca910192a234fc
single-parent squash	git rev-list --parents -n 1 returns 2 fields (9c9e6d08 + parent f19dbcf4, which is #17646's squash) ⇒ squash, ⛔ not a merge commit
content on origin/main	packages/mcp/src/mcp-record-id-key-mistake-refusal.test.ts present, 392 lines; recordId ×26, update_record ×8, StdioServerTransport ×3 (both transports asserted, as reported)
control	fabricated ZZZNOSUCH = 0 in the same file

⚠️ I read the file into a matcher rather than through a shell-quoted grep, deliberately: verifying #16746's landing an hour ago, bash quoting inside $( ) ate the single quotes in my pattern and produced a self-contradictory zero. ⛔ Same class as the pattern error I published on #17180.

⭐ One number I had to chase, and the answer is better than the report's wording

My content read returned Did you mean = 0 — while the report (and my ACCEPT) described the refusal as carrying 「Unrecognized key(s) … Did you mean id -> recordId?」. That looked like a gap, so I read the assertions rather than assume.

The pin deliberately asserts the FACTS, ⛔ not the prose. Every toContain argument (23 of them): INVALID_PARAMS, 'recordId', '`id`', '`recordId`', '`record_id`', 'received undefined'. ⇒ it pins that the refusal names the missing key and names the key the caller actually sent, and the error code — without freezing the sentence that carries them.

⇒ That is consistent with its own out-of-scope finding, which declined to pin the wording precisely because 「prose is not the contract」. ⛔ My ACCEPT's phrasing 「names both facts」 was right; the mechanism is sharper than a string match.

⭐ And it dodges a real substring trap, visibly. The file carries the reasoning inline — a naive toContain('id') is satisfied by the id inside Invalid (as in Invalid input), so every key assertion uses the backticked form `id` / `recordId`. ⇒ a lazier pin would have passed vacuously on the very message it was meant to judge. Worth carrying: ⛔ never assert a short identifier as a bare substring of an error message.

Card closed, residue stripped

Auto-closed completed by Fixes #17568; pm:dispatched removed with a targeted single-label DELETE. Read-back: bug · priority:p2 · domain:cli, ⛔ no pm:* state remaining.

What this card leaves behind

The premise was dead on main and the delivery was a pin, not a fix — #16913 had already implemented the ruled direction (a louder refusal that names the mistake, via strictToolInput + the diagnostic RECORD_ID_ALIASES table, which ⛔ does not widen the accept set: the key is still refused). What was missing is that nothing pinned the intersection of zod emitting both issues, the MCP SDK joining them, and the alias table carrying id — and the nearest sibling pin sends complete arguments plus a probe key, so 「unexpected key coexisting with a missing required key」 was unguarded. That hole is now closed, and ⭐ zero production lines shipped, which is itself the proof the accept set did not move.

⚠️ Still true for users, and carried to the round report

#16913's fix is merged and UNRELEASED — .changeset/mcp-refuse-undeclared-tool-arguments.md still sits in .changeset/. ⇒ every user on the published 17.4.0 line (the version this card measured on, against a real Claude Code client across three takes) still gets the refusal that names only the missing recordId, which is what sends an agent into retrying different values for a key mistake. ⛔ main is fixed; the release is not, and this card closing does not change that.

_{domain:cli 执行席 · session_01TSf4DV7ziu4V5j73e46b7c (os-sales) · R73 · 2026-09-11T09:13Z(读表)}

---

Generated by Claude Code