Record that author-written validation-rule messages are translatable again (`objects.OBJECT._validations.RULE.message`) — ADR status line or short ADR

[os-warren]

Governance follow-up promised on PR #14381 before it merged, filed so the trail is queued rather than remembered.

Why a record is owed

#14381 surface 2 gives an author-written validation rule's message a bundle key (objects.OBJECT._validations.RULE.message) and a reader on the write path (authoredRuleMessage in packages/objectql/src/validation/rule-validator.ts, over the existing ValidationMessageContext.translate hook from #3957).

17.0.0 retired the old validationMessages group (#4667, ADR-0049) with the recorded sentence "Validation messages are not translated through a translation group." #14381 makes that sentence false. Prime Directive #13 says reversing a recorded decision is itself a decision — and today the only place this one is recorded is a retired-key tombstone and a changeset, which is precisely the shape #13 warns is easy to miss.

The ruling to record (made on #14381, not reopened here)

This is ADR-0049 being enforced, not reversed:

• the policy is enforce-or-remove; validationMessages was removed because nothing read it;
• the new key ships with its reader in the same change — the other half of the same policy;
• it is not the same key: the old group was top-level-keyed and could not tell two objects' rules apart; the new one is object-scoped beside _views / _actions / _tabs;
• the ADR-0087 conversion that strips the old key from stored bundles is untouched.

What this card delivers

Whichever is the house shape for this — an amended status line on ADR-0049 (or the 17.0.0 retirement record), or a short standalone ADR — stating: author-written rule messages are translatable via the object-scoped key as of the version #14381 ships in; the 17.0.0 retirement stands; the two are not the same route. One governed-surface PR, human-merge; the code is independent and does not wait on it.

Not a request to hold #14381.

---

Triage (R+99) — graded, and the Blocked-by line removed

The body opened with **Blocked-by: #14381.** That one line was wrong three ways, so it is gone rather than corrected:

1. It pointed at a PR. The Blocked-by: canon points at an issue, never a pull request — an issue closes and clears the block; a PR number has no such lifecycle in the index.
2. It was already exhausted. PR i18n: give bulk-action defs, custom validation messages and dataset labels a bundle key #14381 merged at 2026-09-02T05:28:42Z (merged_by: os-warren, head 7b1c387bb). The thing this card was waiting for has happened — the key and its reader are on main.
3. It could not have parsed anyway. The marker is read line-anchored and undecorated; **Blocked-by: #14381.** is bolded, ends in a full stop, and sits inside a sentence. Even while i18n: give bulk-action defs, custom validation messages and dataset labels a bundle key #14381 was open, nothing mechanical would have seen this card as blocked.

⇒ pm:queue. This card is ready now. Its premise is not "wait for the code" — the code has landed, which is exactly what makes the missing governance record live rather than anticipatory. Prime Directive #13's concern is at its sharpest today: main contains a change that falsifies a recorded 17.0.0 sentence, and the only trace is a tombstone and a changeset.

Scope ruled

Exactly what the card asks and nothing more: one governed-surface PR recording that author-written rule messages are translatable via the object-scoped key as of the version #14381 shipped in, that the 17.0.0 retirement stands, and that the two are not the same route. The card's four-bullet "enforce, not reverse" reasoning is the content — it was settled on #14381 and ⛔ is not reopened here.

⚠️ docs/adr/** is a governed surface (Prime Directive #14): no agent seat marks this PR ready, queues it, or arms auto-merge. A human merges it. Say so in the PR body.

Choosing between an amended ADR-0049 status line and a short standalone ADR is the domain:spec seat's call by house convention — it is a form question, not a direction question, so it does not need the maintainer.

Routing

domain:spec — ADR-0049 is the enforce-or-remove policy governing packages/spec properties, and the record lands on that ADR or beside it. documentation. priority:p3: no code waits on it, nothing is broken, and the change it records has already shipped — it is owed as a trail, and the cost of it going missing is paid by whoever next reads the 17.0.0 retirement and believes it.

Generated by Claude Code

[huangyiirene]

Correction to my triage comment above — reason 3 was wrong.

I wrote that **Blocked-by: #14381.** "could not have parsed anyway" because the marker is read line-anchored and undecorated. That is not how the gate reads it.

scripts/pm/check-half-states.mjs:113-117 says the opposite, deliberately:

The line may be DECORATED in either channel — 「Blocked-by: #9612」 is the natural markdown for a line meant to be grepped, and reading it as absent left #10063 permanently blocked in silence (#10102).

So decoration is tolerated on purpose, and my reason 3 was the exact mistake #10102 exists to prevent. Withdrawn.

The other two reasons stand and are what removed the line:

1. it pointed at a PR, not an issue — and PR i18n: give bulk-action defs, custom validation messages and dataset labels a bundle key #14381 has no issue lifecycle for the unlock sweep to read;
2. it was exhausted — i18n: give bulk-action defs, custom validation messages and dataset labels a bundle key #14381 merged at 2026-09-02T05:28:42Z.

The grading is unchanged: pm:queue, ready now, scope as ruled above.

While checking this I also confirmed a second thing I have had wrong in my own notes: the Blocked-by: line is read in two channels, body and comments — check-half-states.mjs:106-112 records that 26 of 40 blocked cards were body-clean at the 2026-08-19 census, and that parking the line in a comment is a deliberate response to the MCP body-escaping hazard (#8813). A body-only read reports every one of those as having left the machine nothing. Noting it here because it changes where a future reader should look before concluding a card has no blocker line.

---

Generated by Claude Code