[habdelra]

Important

Merge order matters. #775 has merged, and this PR targets main.

1. Let a policy card report which of its grants are in force boxel#6416 and Warn when a policy grant hands over cards of a type no rule grants boxel#6415 merge to boxel main. #6416 adds PolicyValidation and the validate base, which Let a policy card show which of its grants are in force #775 already needs, and #6415 adds PolicyIssue.severity, which this PR reads. Until both have merged, this PR's Lint is red on purpose.
2. Then this PR merges.
3. Then Mark a reach warning beside the live grant it names on the policy card boxel#6437 re-pins its catalog test subset to this PR's merge commit on catalog main, and merges.

At runtime this is safe on a platform without #6415: a validate answer with no severity marks no warnings, and the card renders as #775 does.

Lint on this repo's main is also red right now, on two TS2307 errors for @cardstack/boxel-host/commands/screenshot-card (commands/listing-create.ts and screenshot-card-demo.gts), until #753 merges. Those two are not from this PR.

Part of the operation-permission policies work in cardstack/boxel. #775 marks each grant on a RealmPolicy card as live or inactive from the policy's validate answer, and lists every issue the compile recorded in an Issues section. Some issues leave their grant live. A reach warning (grant-reaches-ungranted-type, render-reaches-ungranted-type) says a read or query grant is in force and hands over cards of a type no rule grants. The card listed such a warning only in its Issues section, so an author reading the rules list saw a plain live grant.

This PR marks a warning beside the live grant it names. The isolated template matches each severity: 'warning' issue to its grant by the issue's rule and grant positions. A grant that is live and has warnings gets a "warning" pill ("2 warnings" when there are more), in a disclosure that opens to the warnings' messages. The disclosure keeps a long reach message out of the rules list until someone asks for it.

Closed, the mark sits beside the grant it names. Opened, it shows the warning's message:

Liveness is unchanged: it still comes from rules and admitsNothing, so a warning never makes a grant inactive. A warning on a grant that admits nothing isn't marked on that grant, because the grant hands nothing over. The warning stays in the Issues list, and the grant keeps its inactive mark. In the Issues list, a warning carries the same "warning" pill beside its rule and grant, and the hint says that a warning leaves its grant live.

cardstack/boxel#6437 (same branch name) pins this branch's head and tests the mark in Integration | realm policy.

Merges before: cardstack/boxel#6437

🤖 Generated with Claude Code

[github-actions]

Staging Submissions Preview

This PR's content is pushed to the staging submissions realm: https://realms-staging.stack.cards/submissions/

Changed folders:

• realm-policy/

Updated at 2026-10-01 13:17:55 UTC for commit 8e138d5. Shared realm: only this PR's changed files are pushed; files touched by multiple PRs reflect whichever pushed last, and deleted files are not removed.

[habdelra]

[Claude Code 🤖] This review covered how the warning mark matches issues to grants, how it is gated against the existing liveness logic, and its markup and CSS. It did not review the liveness logic itself.

No blocking issues. A warning is marked only on a grant grantStatus calls live. It is matched by the rule/grant positions the validate answer derives from each issue's path, and it never feeds into liveness.

1. The Issues list gives no cue which of its entries are warnings. Follow-up; see the comment on the Issues hint.
2. Pill puts a <div> inside <summary>. Nit, with a suggestion on the summary.

[habdelra]

[Claude Code 🤖] The Issues list doesn't mark which entries are warnings. To tell a warning apart from an issue that left its grant out, the reader has to check the rules list. That fails for a warning on a grant that admits nothing, which grantWarnings deliberately leaves unmarked. A snapshot-annotated read on a type with an ungranted link draws one. That warning shows up only here, next to entries that did make their grant inactive.

severity is already on each issue, so a warning pill in .issue-heading when issue.severity === 'warning' would fix it. Follow-up, non-blocking: this change only asks for the mark beside the grant.

[habdelra]

[Claude Code 🤖] Fixed in d7afd10, in this PR. Each warning in the Issues list now carries a "warning" pill in its heading. isWarning decides it, and grantWarnings uses the same check. The hint now says that a warning leaves its grant live. cardstack/boxel#6437 (32acd5e5a1) asserts the pill on the reach warning, and asserts that no issue gets one when every issue leaves its grant inactive.

[habdelra]

[Claude Code 🤖] Pill renders a <div> by default, but <summary> allows only phrasing content. @tag='span' keeps the markup valid, and the look is unchanged because .pill is inline-flex either way. Nit, non-blocking.

Suggested change

	<Pill
	<Pill
	@tag='span'

[habdelra]

[Claude Code 🤖] Fixed in d7afd10. The pill in <summary> renders a span now (@tag='span'), and so does the new pill in the Issues list.

[habdelra]

[Claude Code 🤖] Refreshed preview, after d7afd101. Two things changed since the description's images: a warning in the Issues list now carries its own "warning" pill beside its rule and grant, and the Issues hint now says that a warning leaves its grant live. The mark beside the grant is unchanged.

[richardhjtan]

[Claude Code 🤖] Warnings mark only live grants, and every warning still shows in the issues list with its own pill, so none is hidden; nothing blocks. Merge order as described (after #775, then the boxel re-pin).