You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Reconcile the spec with the settled config and broker models #521
The document's own banner says it: the mechanism design below it "predates and conflicts with" the settled
config model and the broker model, and should be "treated as design history" until reconciled. Until that
lands, nobody can build from 6.1 without first working out which half is current.
Placed on #916 as lane 34, in PR C, after lane 33 (named roots, #597)
The owner, 2026-10-02: "So add the elevation design to your schedule. It's time to bite the bullet." Earlier the same day: "The elevation spec is a draft that requires deep research when we're ready to execute."
What brought it here: lane 7's VM run (#926) reached its System-scope adoption. Adopting a root-owned file under /etc needs root, nothing in writ elevates, and pkg/op/provider/elevator is a stub whose Elevate always answers not implemented. Running writ under sudo does not substitute. Measured on danoble-ud24-1: sudo's secure_path leaves writ off root's PATH, env_reset clears the XDG_* variables, and HOME is /root; and pkg/xdg resolves the home directory from the account by design, so root's writ uses root's home, configuration and store. Read from the code, not run: forcing the user's XDG_* directories onto it would write the lifetime and receipts root-owned and 0600 (cmd/internal/cli/lifetime.go writes 0o600) into the user's store, which the user's next unprivileged run could not read or replace.
So the design begins with deep research, then this feature's tasks (#522-#525) reconcile 6.1 with the settled configuration and broker models. Writ's System scope is one consumer the design must answer: one record, with the user's writ elevating only the operations that need root, as 6.1 frames it, or root running its own writ for System. It follows lane 33 because named roots decides what a root is, and elevation how a run reaches System's. Until then, tests against System are skipped: "For now: skip tests against system."
Activity
David-Noble-at-work commentedon Oct 2, 2026
Placed on #916 as lane 34, in PR C, after lane 33 (named roots, #597)
The owner, 2026-10-02: "So add the elevation design to your schedule. It's time to bite the bullet." Earlier the same day: "The elevation spec is a draft that requires deep research when we're ready to execute."
What brought it here: lane 7's VM run (#926) reached its System-scope adoption. Adopting a root-owned file under
/etcneeds root, nothing in writ elevates, andpkg/op/provider/elevatoris a stub whoseElevatealways answers not implemented. Running writ undersudodoes not substitute. Measured ondanoble-ud24-1: sudo'ssecure_pathleaveswritoff root'sPATH,env_resetclears theXDG_*variables, andHOMEis/root; andpkg/xdgresolves the home directory from the account by design, so root's writ uses root's home, configuration and store. Read from the code, not run: forcing the user'sXDG_*directories onto it would write the lifetime and receipts root-owned and 0600 (cmd/internal/cli/lifetime.gowrites 0o600) into the user's store, which the user's next unprivileged run could not read or replace.So the design begins with deep research, then this feature's tasks (#522-#525) reconcile 6.1 with the settled configuration and broker models. Writ's System scope is one consumer the design must answer: one record, with the user's writ elevating only the operations that need root, as 6.1 frames it, or root running its own writ for System. It follows lane 33 because named roots decides what a root is, and elevation how a run reaches System's. Until then, tests against System are skipped: "For now: skip tests against system."
docs(plan): lane 7 closes, its VM run recorded and its tests against …