08 — Pinning, Labeling, Auto-Grouping Thresholds

Status: DESIGN-CLEAR; not blocking the layer engine (next phase)

Pin (registry_pin) — propose-only, NOT yet live

• Storage: NEW PG table registry_pin (id + birth + meta_catalog + pivot — itself a governed Atom, else it is an orphan). Not born yet → the contract view emits pin_state='PIN_REGISTRY_MISSING' (honest).
• Ordering effect: pinned nodes sort first within their layer (a pin_rank column), then display_order.
• Scope: user-private pin = Class 0 (non-governed); global/shared pin = governed (M-DEF-1).
• Counted: pins are themselves counted by a pivot (PIV-32x, PIVOT_MISSING until the table exists).

Label / auto-grouping registry

• Trigger: when a layer's child count > threshold, grouping is required (else the list is too long).
• Default threshold = 50 per species (the Điều-24 / addendum ceiling), overridable per species in PG, never in Nuxt.
• Labels live in PG (taxonomy/label_rules/entity_labels — entity_labels ≈ 718,744 rows, currently uncounted → PIV-31x label-by-facet PIVOT_MISSING).
• Labels are themselves counted/registered (a label is an Atom; an unregistered label is an orphan).

What can be done now

Item	State
pin_state surfaced as PIN_REGISTRY_MISSING	LIVE (in node contract)
registry_pin table	design-only (next phase)
threshold=50 rule	design-only; render-time gate from PG config
label-by-facet pivot (PIV-31x)	PIVOT_MISSING (doc 05)

Decision

Pin/label/auto-grouping is next-phase, explicitly does not block the core layer engine. The contract view already exposes the honest placeholders (pin_state, child_layer_kind, requires_auto_label derivable from count_value > threshold) so no ambiguity remains about how very large lists avoid becoming too long: count>threshold ⇒ backend emits a grouping layer; until the label registry is born, that layer is PIVOT_MISSING, surfaced not hidden.