Reading needed from hotcrm: do any of the 16 inline record_header ActionDefs carry page-level customization an id-resolved action cannot express? (gates objectui#6252) #12580

Filed unlabelled by the domain:ui execution seat @ objectui (session session_011SfZeFWrhGLHmfq61xbz4q). Routing, domain:*, type and grading are triage's to produce — this seat does not apply them. Suggested routing is at the bottom.

What is needed

One measurement, in objectstack-ai/hotcrm, and the answer is the whole deliverable — no code.

objectui#6252 implements the objectstack#11592 ruling (maintainer, 2026-08-25, verbatim 「全部同意」 on recommendation B). That card's own Step 1 is a gate, in its words:

Step 1 — the equivalence measurement, and it gates the rest: compare the exemplar's 16 inline ActionDef objects (hotcrm, 4 record pages, all locations: ['record_header', …]) against their object-level registered actions. If any inline def carries page-level customization an id-resolved action cannot express, ⛔ stop and report back to objectstack#11592 — that evidence reopens the ruling; do not silently absorb it with an override semantic.

So the question is precisely:

For each of the 16 inline ActionDef objects across hotcrm's 4 record pages that declare locations: ['record_header', …] — is every one of them expressible as a reference to the object's own registered action of the same id, with no page-level customization lost?

A yes unblocks objectui#6252 to implement. A no, with the specific def and the specific property that cannot survive id resolution, is evidence that reopens the objectstack#11592 ruling — which is a more valuable answer than a yes, and must go back to that issue rather than being worked around.

Why this seat cannot answer it

objectstack-ai/hotcrm is not reachable from this session. Measured rather than assumed: unauthenticated REST returns HTTP 403 for it, against a HTTP 200 control on objectstack-ai/objectui in the same call, and the session's repository listing returns no match for it. This seat is therefore recording the question instead of guessing at it — a repo it cannot read is not a repo it has read and found clean.

Ready-to-run commands for whoever holds hotcrm

Run these at that repo's root and paste the output back here; that is the entire ask.

grep -rln "record_header" --include=*.ts --include=*.tsx --include=*.json .

Then, for each record page that matches, the two halves to compare:

grep -n -A20 "locations" <each matching file>

and the object-level registered actions for the same objects, so each inline def can be lined up against the registered action carrying its id. What matters per def: whether label, variant, icon, order, visible, requiredPermissions or any handler/body differs from the registered action, or exists only inline.

Waiting state

objectui#6252 is being moved to pm:blocked with Blocked-by: pointing at this issue in the same write, so its queue label stops claiming it is dispatchable. It will return to the queue when this is answered.

Suggested routing (triage's call, not this seat's)

The hotcrm lane holds the repo. If a seam card is preferred because the target repo is unreachable from most seats, this issue is already in objectstack and needs only the repo:* routing plus a named reader.