docs(adr): ADR-0104 D2 note states what a D2 refusal is on main

The dated note under D2 item 1 now says a D2 refusal is one 400
VALIDATION_ERROR naming every offending param, with no fields[], at the
REST and MCP doors, and that item 1's "400 VALIDATION_FAILED per-field
envelope" names the ledger's record-level fields[] member instead. The
status-line entry carries the same correction. The original sentence stays
verbatim.

Claude-Session: https://claude.ai/code/session_019oFY6Hi35J7atvgVFnmoaK
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

docs/adr/0104-field-runtime-value-shape-contract.md

@@ -18,7 +18,10 @@
   declarative `operation: 'update'` action's empty or absent `params` list is
   an empty accept set, refused through D2's own path, and at the MCP
   `run_action` door a D2 refusal carries `code` + `status` (the ADR-0112
-  envelope), as at the REST door. See the note under D2 item 1.
+  envelope), as at the REST door. A D2 refusal is one `400 VALIDATION_ERROR`
+  naming every offending param, with no `fields[]`, at both doors, which
+  corrects item 1's "`400 VALIDATION_FAILED` per-field envelope". See the
+  note under D2 item 1.
 - **Date**: 2026-07-22
 - **Issue**: design follow-up generalizing #3405 / #3406 (inline lookup param
   silently stripped); relates #3407 (silently dropped writes), #1878 / #1891
@@ -215,8 +218,21 @@ free. Three changes:
    > (`packages/spec/src/ui/action-params.zod.ts#ACTION_PARAM_BUILTIN_KEYS`:
    > `recordId`, `objectName`, `_selectedIds`) is refused through this item's
    > path: the same 400 at the REST door and the same
-   > `OS_ALLOW_LAX_ACTION_PARAMS` escape hatch, with no switch of its own. An
-   > empty bag still writes the `patch`. The discriminator is `operation`
+   > `OS_ALLOW_LAX_ACTION_PARAMS` escape hatch, with no switch of its own.
+   > **What a D2 refusal is, at both doors and for every action:** one
+   > `400 VALIDATION_ERROR` whose message (`Invalid action params: …`) joins
+   > one issue per offending param, each naming it, with no `fields[]`. The
+   > REST door passes no code, so
+   > `packages/runtime/src/error-envelope.ts#buildApiError` derives it from
+   > the status through
+   > `packages/spec/src/api/errors.zod.ts#standardErrorCodeForHttpStatus`;
+   > the MCP throw below stamps that function's answer. So item 1's "the
+   > standard `400 VALIDATION_FAILED` per-field envelope" names the wrong
+   > code and the wrong shape: `VALIDATION_FAILED` is the ADR-0112 ledger's
+   > record-level validation member, which carries `fields[]`
+   > (`packages/types/src/validation-failure.ts`), and the D2 gate never
+   > builds it. An empty bag still writes the `patch`. The discriminator is
+   > `operation`
    > alone (`packages/runtime/src/action-execution.ts#isDeclarativeUpdateAction`),
    > so every other param-less action (a script handler, an inline `body`, a
    > `flow` target) keeps the pass-through. At the MCP `run_action` door,
@@ -227,9 +243,12 @@ free. Three changes:
    > (`packages/mcp/src/mcp-http-tools.ts#thrownRefusalEnvelope`), as at the
    > REST door. Pinned in `packages/runtime/src/action-params-enforcement.test.ts`
    > (the gate, the hatch), `packages/runtime/src/action-declarative-update.test.ts`
-   > (both doors, nothing written, and the handler control) and
+   > (both doors: `VALIDATION_ERROR` and 400 on a declared and a param-less
+   > action at REST and on the MCP throw, nothing written, and the handler
+   > control) and
    > `packages/mcp/src/mcp-coded-refusal.test.ts` (`run_action`'s rendering of
-   > a thrown code). No other part of D2 changes.
+   > a thrown code). No other decision in D2 changes: the code and shape
+   > above correct the record, they add no rule.
 
 2. **Typed handler surface.** `defineAction` today validates config only. It
    gains a typed companion so registered handlers stop being