Plan managed Pi provider lifecycle #35
No reviewers
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
allod/strategy!35
Loading…
Reference in a new issue
No description provided.
Delete branch "agent/pi-provider-plan"
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?
This plan uses the existing Age/agenix and Pi command-helper path instead of creating another credential store.
It defines
add,retarget,rotate,retire, and interruptionrecoveroperations on Nexus.Retirement removes only owned Pi entries and orphaned ciphertext; unrelated user configuration remains.
Provider metadata belongs to profiles, while credentials, targets, and recipients belong to secrets.
Agents sharing the target VM account can still access the runtime credential; this plan does not claim otherwise.
Remote token revocation remains a provider-specific human step after verification from a fresh Pi process.
Merging this plan changes no running machine, credential, provider, package, or generated configuration.
Implementation remains blocked until the owner approves this revision with
go.Refs allod/strategy#34
Design
reset --hardor plaintext backups.Risk
R0 for this documentation-only PR. The planned implementation remains R3 because it crosses authentication, Age recipients, generated activation, persistent Pi configuration, six repositories, and host-operated lifecycle tooling.
Validation
gpt-5.6-sol, high) found and drove fixes for revision binding, credential cardinality, crash recovery, provisioning absence, Pi locking/cache behavior, retargeting, workspace availability, ownership, and unnecessary extension scope.gpt-5.5, high) found two witness-contract gaps;9d639c9now specifies the required composition observation APIs and raw-hypervisor inventory check.df34a4e; remaining uncertainty is assigned to executable implementation witnesses rather than another prose pass.git diff --checkpasses.Read-only review found two plan defects to fix before owner approval:
[GAP]The proposed Piauth.checkcan only prove that the managed path exists; it cannot prove the file is non-empty or single-line. That would letpi auth checkreport the managed source for a broken credential. Omit the shortcut and have the normal resolver read/validate the runtime file for credential-free status checks and requests.[GAP]“Reject non-bearer-token input” is not an executable boundary. Pin the accepted RFC 6750b64tokenalphabet and trailing-padding rule so a quote/newline cannot turn the curl config stdin into additional directives.Both are original-plan defects. The fixes should stay within the existing design and need no scope expansion.
Addressed both review findings in commit
79ca83c:pi auth checkand real requests both read and validate the Age-backed runtime credential while returning only its source label.A scoped review of that follow-up found no new inconsistency; the PR remains documentation/design only.
79ca83c3a8tobe44135c39Owner review request: add an explicit old-token retirement lifecycle.
The plan should distinguish two operations:
pi auth checkand a real request, a Nexus-side command should atomically remove only that provider's stale API-key entry from the target VM's~/.pi/agent/auth.json, without reading or displaying its value and without a force bypass.overlaporin-place, print the correct order, and leave actual provider-side revocation/expiry to the owner rather than pretending a genericretirecommand can perform it.The intended canary is therefore: enroll the existing token, rebuild and verify the managed path, retire the old local Pi entry, use the token normally, then issue and rotate to a replacement; revoke the previous remote token after verification when the provider supports overlap.
Read-only R3 review of commit
a32d545withgpt-5.6-solat high effort found ten plan defects:[BLOCKER]The deploy graph could let secrets and archetypes validate against different inventory revisions.[BLOCKER]The schema allowed one provider to resolve to different credentials on disjoint targets whilerotateandretireselected a singular credential.[BLOCKER]Ordinary rollback did not cover process death or power loss between mutations in the profiles and secrets repositories.[BLOCKER]Missing Age material during provisioning was specified to abort instead of leaving reconciliation unchanged for a later activation.[BLOCKER]The reconciler's unspecified lock would not necessarily coordinate with Pi'sproper-lockfileauth writer.[GAP]Pi caches command-backed auth for the process lifetime, so an already-running Pi session can retain the old token after rebuild.[GAP]Adding a provider to a shared credential with a different target set named no executable retarget/rekey path.[GAP]The public Nexus workspace does not currently include the profiles checkout required by the command.[QUESTION]The plan did not distinguish exclusive ownership of managed JSON IDs from preservation of unrelated/operator-owned state.[SIMPLIFY]Generic extension-link management added lifecycle surface while integration-specific extensions are out of scope.These are original-plan defects. The follow-up should bind all shared inputs, require global provider-to-credential uniqueness, add durable crash recovery and explicit retargeting, use Pi-compatible auth locking, tolerate provisioning absence without mutation, require a fresh Pi process after rotation, declare managed-ID ownership, add profiles to Nexus inventory, and delete extension management.
Final scoped plan review (
gpt-5.5, high effort) found two implementation-changing gaps in734a9fe:[GAP]The revision-graph contract requires an explicitarchetypesAPI change. The current public framework exposes onlyprofilesSourceandcomposedLayerCheck { pkgs, expectedProfiles }; implementation must extend or replace that interface so the deploy canary compares the composed profiles, secrets, and inventory sources, includingsecrets.inputs.inventory.follows, and sabotages each redirect.[GAP]The current inventory registry witness cannot prove the Nexus host receives the profiles checkout because it reads guest-onlyscripts/vm-specs.json, which excludes hypervisors. Implementation must add a host-workspace witness overmachines.nexus.repos(or an equivalent raw-machine surface) and require exactly the lifecycle command's declared Nexus repository set.Stable: public/private source split; global provider-to-credential uniqueness and explicit retarget; durable journal and path-scoped recovery; Pi-compatible locking, managed-ID ownership, missing-secret no-op, empty-desired cleanup, and fresh-process verification; no generic extension lifecycle.
Plan managed Pi provider credentialsto Plan managed Pi provider lifecycleResolved the final scoped review findings in
9d639c9:The review handoff in
df34a4erecords this as the second and final R3 plan-text pass. The other pass-1 fixes survived unchanged. Remaining questions are executable and belong to the implementation witnesses after owner approval.