Split out of #234, which closes with its joins shipped; this was its one line-item with no spec ("Deferred behold-side: … RBAC member badges"), filed here so the deferral is a concrete issue instead of a clause.
What is known
OperatorStack (chant#1940) declares the operating loop as a k8s estate: a Namespace, a CronJob per ConvergeOp, and per-host RBAC (ServiceAccount + Role/RoleBinding — chant: lexicons/k8s/examples/operator-stack/src/infra.ts). Those are ordinary entities, so the loop already appears in the estate graph. What the graph does NOT say is the ask here: which identity the loop acts as — badge the member box (or the namespace box) with the ServiceAccount its CronJobs run under, so "who is allowed to do this" is readable off the estate the way "who approved it" is readable off a release record.
What blocks the sibling deferral
The other deferred clause ("the logical lens's namespace box has no mark channel") wants a pinhole field — if the badge is to live on the box rather than the card, the same upstream need likely applies. Worth deciding placement (box mark vs card attr vs inspect-pane row) before any pinhole ask.
Definition of done (proposed)
- An OperatorStack-shaped estate member shows the ServiceAccount identity its ConvergeOp CronJobs run as, joined from the declared entities (no live read needed — the binding is source).
- Absence stays silent: a loop not declared via OperatorStack gets no badge, never a guess.
🤖 Generated with Claude Code
Split out of #234, which closes with its joins shipped; this was its one line-item with no spec ("Deferred behold-side: … RBAC member badges"), filed here so the deferral is a concrete issue instead of a clause.
What is known
OperatorStack(chant#1940) declares the operating loop as a k8s estate: a Namespace, a CronJob per ConvergeOp, and per-host RBAC (ServiceAccount + Role/RoleBinding —chant: lexicons/k8s/examples/operator-stack/src/infra.ts). Those are ordinary entities, so the loop already appears in the estate graph. What the graph does NOT say is the ask here: which identity the loop acts as — badge the member box (or the namespace box) with the ServiceAccount its CronJobs run under, so "who is allowed to do this" is readable off the estate the way "who approved it" is readable off a release record.What blocks the sibling deferral
The other deferred clause ("the logical lens's namespace box has no mark channel") wants a pinhole field — if the badge is to live on the box rather than the card, the same upstream need likely applies. Worth deciding placement (box mark vs card attr vs inspect-pane row) before any pinhole ask.
Definition of done (proposed)
🤖 Generated with Claude Code