[finding] `objectName` on an object-embedded action is inert AND unvalidated — the third arm PR for #7397 deliberately left open

[os-zhuang]

Observation-class finding, surfaced and measured while implementing #7397 (the object-embedded modal/flow cross-reference arm). Filed unassigned per #4949 discipline — deliberately NOT fixed in that PR, because the fix requires a contract decision this seat should not take as a side effect.

What was measured

The registered action walk in packages/spec/src/stack.zod.ts applies three checks, not two: flow target, modal target, and objectName → declared object. #7397's PR mirrors the first two onto config.objects[].actions[]. The third is left as-is, and it splits the same way the target arms did:

embedded   { name: 'probe_on', type: 'script', target: 'doThing', objectName: 'probe_missing' }  ->  ACCEPTED
REGISTERED { name: 'probe_on', type: 'script', target: 'doThing', objectName: 'probe_missing' }  ->  REJECTED
   "Action 'probe_on' references object 'probe_missing' which is not defined in objects."

Same action object, two authoring positions, opposite verdicts — the b/f, c/g, d/i pattern from #7397's probe table, one key over. Measured on origin/main @ d13ce33 with both stacks built from the same helper and the same arguments.

Why it is observation-class rather than a live defect

Nothing consumes the key at that position today, so no user hits it at runtime:

• mergeActionsIntoObjects (stack.zod.ts) builds its objectName -> actions[] map only from config.actions — the top-level list. It never reads obj.actions[].objectName. The merge direction is top-level to object, never the reverse.
• The embedded position carries the full ActionSchema (data/object.zod.ts, actions: z.array(ActionSchema)), so the key is declared there purely because the shape is shared with the registered collection — not because anything reads it.

So it is a declared-but-unconsumed key at this position (Prime Directive #12, "declared = enforced") plus an unvalidated dangling reference — inert drift, not a live break. That is why it carries the finding label and no pm:queue.

The contract question that blocks a mechanical fix

Mirroring the registered check verbatim is not obviously right, which is exactly why #7397's PR did not do it. Two readings, different acceptance surfaces:

• A — existence check (verbatim mirror). objectName on an embedded action must name a declared object, same as registered. Cheapest, consistent with the other two arms. But it accepts objectName: 'other_object' on an action embedded under task — a contradiction the schema would then bless.
• B — consistency check. On an embedded action, objectName must equal the owning object's name (or be absent), because the action's owner is already unambiguous from its position. Stricter, and the only reading under which the key carries meaning at this position at all.
• C — retire the key at this position. If nothing reads it and B says it can only ever restate the position, the ADR-0049 enforce-or-remove route may be the honest answer rather than either check.

A/B/C differ in what they refuse, so this is an acceptance-surface decision (domain:spec by the standing red line), and under the startup-focus principle option C deserves real weight: there is no measured business pull for authoring objectName at a position that already names the object.

Anchors

• packages/spec/src/stack.zod.ts — registered objectName check (Validate action -> object references); the [observation] config.objects[].actions[] (object-embedded actions) may also bypass defineStack's cross-reference walk — unverified, same mechanism as #6889's row E #7397 embedded walk immediately above the inline one, whose comment records this exclusion in code.
• packages/spec/src/data/object.zod.ts — actions: z.array(ActionSchema), the shared shape.
• [observation] config.objects[].actions[] (object-embedded actions) may also bypass defineStack's cross-reference walk — unverified, same mechanism as #6889's row E #7397 / its PR — the modal/flow arms; Inline (page-element) actions bypass defineStack's action cross-reference validation entirely — a dangling type: 'modal' target builds clean #6889 / PR fix(spec): defineStack cross-reference validation reaches inline page-element actions (#6889) #7392 — the inline half. Neither covers this key: InlineActionSchema does not pick objectName at all, so the inline arm had nothing to decide.

Dedup

Open-issue search for objectName action cross-reference and embedded action objectName defineStack returns only #7397 itself. No open card covers this key.

[claude]

Findings triage: held (finding + domain:spec both stand — routing verified correct).

Premise — filed today against origin/main @ d13ce33 with a measured probe table (embedded objectName: 'probe_missing' ACCEPTED vs registered REJECTED); current main is 8a9c079 and #7397's PR (the first-two-arms mirror) has not merged, so the measured split is unchanged in kind. Not re-probed this round — the card is hours old and its filing seat measured it directly.

Why held rather than promoted or escalated — same disposition logic as #7390: the residue is decision-shaped. Mirroring the registered objectName check onto the embedded position is an acceptance-surface change (stacks that validate today would be rejected), and the card's filing seat explicitly declined to take that as a side effect; but the key is also inert at that position (mergeActionsIntoObjects reads only config.actions — never the reverse), so the alternative is retiring the key there, also an acceptance-surface change. Both directions are domain:spec calls with zero user impact today — nothing consumes the key, nobody hits it. Escalating now would put a no-urgency contract fork in an already-loaded decision box.

Promotion/escalation triggers recorded: ① #7397's PR merges (the natural moment — the third arm's fix would land in the same walk, and the claiming spec seat can carry the question to the maintainer with all three arms in view); ② any consumer of obj.actions[].objectName appears; ③ maintainer appetite for the embedded/registered parity question generally.

Dedup — #7397 (arms 1–2, in flight) is the parent; this is its deliberately-severed third arm, cross-linked by both bodies. No other card owns the key.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code