The group_entity_type Cedar configuration field is currently documented on main, but it's an internal knob that we previously decided not to surface in user-facing docs. It was re-added by the automated upstream-release-docs run in #912 (toolhive v0.28.3) and should be removed again.
Background
This content was originally added in #842 (toolhive v0.26.1) from toolhive #5121, then removed before merge after a review note from @jhrozek: the field is an internal knob we'd prefer not to document. The removal was a direct push to that PR branch, so it never landed on main, which is why it doesn't show up in git log history on the current files.
@blkt's stacklok/toolhive#5290 (toolhive) leans on the field for the ClaimGroup in PlatformRole transitive-policy pattern, so the release run reasonably inferred it was worth documenting. Nothing in the upstream source signals otherwise. This isn't a knock on that run or its reviewers; the original "don't document" decision simply had no durable record for the skill or a reviewer to find.
What to remove
Re-added in #912:
docs/toolhive/concepts/cedar-policies.mdx - the group_entity_type configuration-fields bullet and the "Customizing the group entity type" section.docs/toolhive/reference/authz-policy-reference.mdx - the "Customizing the group entity type" section.
The auto-synced CRD schema files under static/api-specs/crds/ should be left alone (they're generated from upstream and not hand-edited).
Preventing recurrence
The deeper gap: a deliberate "do-not-document" decision lived only in a PR review thread (unresolved, now outdated) with no persistent representation. Worth considering a repo-level exclusions list (e.g. a do-not-document registry keyed by field name with a reason + PR link) that the upstream-release-docs skill consults during its audit phase, so suppressed fields don't get silently re-introduced on a later release. Tracking that separately is fine if we'd rather keep this issue scoped to the removal.
The
group_entity_typeCedar configuration field is currently documented onmain, but it's an internal knob that we previously decided not to surface in user-facing docs. It was re-added by the automated upstream-release-docs run in #912 (toolhive v0.28.3) and should be removed again.Background
This content was originally added in #842 (toolhive v0.26.1) from toolhive #5121, then removed before merge after a review note from @jhrozek: the field is an internal knob we'd prefer not to document. The removal was a direct push to that PR branch, so it never landed on
main, which is why it doesn't show up ingit loghistory on the current files.@blkt's stacklok/toolhive#5290 (toolhive) leans on the field for the
ClaimGroup in PlatformRoletransitive-policy pattern, so the release run reasonably inferred it was worth documenting. Nothing in the upstream source signals otherwise. This isn't a knock on that run or its reviewers; the original "don't document" decision simply had no durable record for the skill or a reviewer to find.What to remove
Re-added in #912:
docs/toolhive/concepts/cedar-policies.mdx- thegroup_entity_typeconfiguration-fields bullet and the "Customizing the group entity type" section.docs/toolhive/reference/authz-policy-reference.mdx- the "Customizing the group entity type" section.The auto-synced CRD schema files under
static/api-specs/crds/should be left alone (they're generated from upstream and not hand-edited).Preventing recurrence
The deeper gap: a deliberate "do-not-document" decision lived only in a PR review thread (unresolved, now outdated) with no persistent representation. Worth considering a repo-level exclusions list (e.g. a
do-not-documentregistry keyed by field name with a reason + PR link) that the upstream-release-docs skill consults during its audit phase, so suppressed fields don't get silently re-introduced on a later release. Tracking that separately is fine if we'd rather keep this issue scoped to the removal.