Campaign: declared promotion and definitive suppression of stable identities #15
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Meta/Campaign
Meta/Epic
Meta/Session
Priority/Critical
Priority/High
Priority/Low
Priority/Medium
Reviewed/Confirmed
Reviewed/Curated
Reviewed/Duplicate
Reviewed/Invalid
Reviewed/Won't Fix
Scope/Campaign
Status/Abandoned
Status/Blocked
Status/Conflicted
Status/In Progress
Status/In Review
Status/Need Grooming
Status/Need More Info
Status/Ready
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Ting/Vedanta#15
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Proposal
Coordinate the council-declared lifecycle of permanent stable identities. Flake-ops carries the freeholder-and-council ruling; NixOps4 providers apply every declaratively expressible change; Vedanta may duplicate operations only as runtime workflow endpoints.
Design
Tasks
Promote stable identities and definitively suppress themto Campaign: declared promotion and definitive suppression of stable identitiesGrooming state: Refinement pass authorized; leaves not yet derived.
Owner ruling (2026-08-26): Run a full OpenSpec refinement before deriving leaves. A Deliverable carries one or two independently testable specification changes. An Epic holds one Deliverable directly when that is all it has; create a Session only for a coherent bundle of two or more Deliverables. An Epic with ten or more Deliverables uses at least two Sessions.
Consequence: the current six Session nodes are provisional coordination records, not a forced hierarchy. The OpenSpec pass must derive their actual leaves and retain, split, or dissolve each Session from that evidence; no fixed two-leaf template is approved.
Evidence: #16–#19, flake-ops#403/#404, and nixops4-providers#25/#26 are all currently
Status/Need Groomingand contain no leaf Deliverables or linked OpenSpec package.Structural clarification (2026-08-30): removed the redundant direct Campaign→Deliverable dependency #15→#8. #15 retains direct Epic children #16/#17; #8 remains transitively required through #16→#18→#8 and #17→#19→#8.
Owner ruling (2026-09-03) — the pass is authorized. The full OpenSpec refinement over this Campaign may proceed. It reads the selected OpenSpec root as engineering authority, then derives, splits, or dissolves #16–#19 from that evidence, filing and restructuring records as the evidence requires. The 2026-08-26 constraints bind it unchanged: no fixed two-leaf template, Sessions only for coherent bundles of two or more Deliverables, and the Epic/Session sizing thresholds above. Until the pass runs, #16–#19 hold
Status/Need Groomingand no leaf may be derived from their current bodies.OpenSpec refinement pass — 2026-09-03
Authorized by the ruling above. The pass ran and stopped where it must: the root it was told to read does not exist. What follows is the evidence and the frontier it produced.
Findings
F1 — there is no OpenSpec package for this Campaign. Vedanta's OpenSpec index lists exactly one package (OpenSpec 20, Session #20, contract 0.1.4, proposed). Ting/Ting's wiki holds OpenSpec 61 and nothing for promotion/suppression. Neither is this Campaign's root. The 2026-08-26 ruling directs a full OpenSpec refinement before deriving leaves, and grooming law makes the selected root the engineering authority — so the pass's first act is authoring the package, which is engineering authoring through the wiki Git path, not a grooming mutation. No leaf may be derived until it exists.
F2 — the six Session nodes are each one Deliverable, not a bundle. Every one carries two or three tasks, no Specification Delta, no delivery class, no OpenSpec link:
Under the 2026-08-26 thresholds — a Session only for a coherent bundle of two or more Deliverables, an Epic holding one Deliverable directly when that is all it has — the Session tier looks unearned across all six. This is the outcome that ruling anticipated when it called them provisional coordination records.
F3 — the Campaign is filed away from its own implementation. #15 lives in Vedanta, but its declarative authority is flake-ops and its mandatory implementation is nixops4-providers. #15, #16, and #17 each state that providers are the required declarative path and that Vedanta may duplicate only workflow-time runtime operations and "must not be the sole implementation of any declaratively expressible operation." A Campaign governed from the repository that holds its optional half is a placement question, not a detail.
F4 — #18/#19 sit on the boundary #11 surfaced. #11's grooming record establishes that current Vedanta law forbids principal deletion and assigns principal rotation, disabling, and retirement to Jostoph, leaving Vedanta only exact resource-credential token invalidation. Resolved 2026-09-03 — see Q4.
Frontier
Q1 — Campaign placement. Does #15 stay in Vedanta, or move to Ting/Ting as an estate-wide record projecting into per-repo Sessions?
➡️ Move it. Grooming law already provides for an estate-wide change living in the
ting-wikiStore and projecting into several repository Sessions, which is exactly this shape across three repos; and per F3 the Vedanta half is explicitly the optional one.Q2 — OpenSpec root shape. One package covering promotion and suppression together, or one per Epic?
➡️ One. The two share the whole identity spine — Kanidm UUID as the authority key, permanent mount binding, declarative-first ordering, providers before any runtime executor — and differ only in terminal outcome. Two packages would duplicate the spine and let it drift.
Q3 — the Session tier. Dissolve all six nodes to Epic direct leaves per F2, or keep the tier?
➡️ Dissolve, then re-form a Session only where the authored package's derived leaves actually show a coherent bundle of two or more. Deciding the hierarchy before the package exists is the forced template the 2026-08-26 ruling refused.
Q4 — #18/#19 against the Jostoph boundary. Resolved by the #11 Q1 ruling (Larandar, 2026-09-03). That ruling fixes the boundary these two were held against: creation of permanent identities is the provider's fief, principal disposition is Jostoph's, and Vedanta observes the whole identity plane while acting only on exact resource credentials. #18 mints a fresh workflow JWT and #19 invalidates workflow JWTs and API credentials — both are runtime resource-credential operations, not principal disposition, so both fall inside Vedanta's remaining scope and survive as work. Their tier is still Q3's to settle, and their shape is still the package's to derive; the hold is lifted, not the derivation.
Standing
Status/Need Grooming stands on #15 and on all six nodes: nothing can be derived until Q1–Q3 are answered and the package is authored. The pass created and dissolved nothing — under propose-then-create, the child graph is a proposal, and this frontier is what it must be approved against.
Superseded by Ting/Ting#85 — freeholder ruling Q1 (2026-09-04): this Campaign moves to the estate tracker.
The work spans three repositories, and Vedanta holds the optional half — providers are the required declarative path, and this repository "must not be the sole implementation of any declaratively expressible operation". A record governed from the repository that owns its optional half is governed from the wrong place, and its OpenSpec package would have lived in this wiki rather than the estate store.
The contract is now OpenSpec 85, authored today. The Session tier was dissolved by Q3: the six nodes become Deliverables under their Epics, each reviewed in the repository that builds it.
Nothing is lost by closing this. The grooming history here — including the 2026-08-26 sizing ruling that governs the decomposition — is cited from the superseding record. Vedanta keeps its own two Deliverables, #18 and #19, re-pointed at the new Epics.