Readmit a returning Queen under a new grant #14
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#14
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
Define the explicit return path for a Queen whose mount went dormant. Recovery is initiated by the returning Queen—normally after a human restarts it—not by a human acting as the Queen. It is distinct from #13’s monitor-claim death-to-dormancy path.
A return does not resume the dead workflow. Per the owner ruling below, the returning Queen is admitted under a new immutable grant and a new authorization generation; the dormant workflow stays dormant and terminal. What this record specifies is therefore the authenticated readmission path, not a resurrection.
Design
Owner ruling (2026-09-03), Q3 — continuity. After abnormal Queen death, a return may not resume the same workflow or grant. It must follow OpenSpec 61 v0.1.4's immutable-grant model: a new AssignmentGrant and a new authorization generation. Same-workflow resumption becomes available only if a bounded, non-stale continuity proof is separately ratified — and that proof must be non-stale by construction, since the failure this rules out is precisely an ABA match against a later occupant.
Consequences carried into this record:
Q4 fell away with the ruling. It asked which ratified authority survives dormancy to authenticate a same-workflow resumption; with resumption refused, nothing needs to survive dormancy, and the fresh-JWT-as-own-bootstrap hazard it guarded against cannot arise.
Tasks
Specification Delta
Requirement: a return is readmission under a new grant, not resumption
Requirement: a three-field match cannot admit a return
Requirement: returning does not clear dormancy
Grooming state: Q3 ratified and the body rewritten against it; the probe and the attestation split remain.
Evidence: OpenSpec 61 v0.1.4 and the current private-command contract bind authority to assignment, holder, tenure grant ID/version/digest, authorization generation, operations, actor/account mode, and resource scope. Identity + node + mount path can ABA-match a later occupant. No deployed returning-Queen authentication or full-manifest surface was found.
Frontier
Q3 — continuity. Ratified (Larandar, 2026-09-03): a return may not resume the same workflow or grant; it takes a new AssignmentGrant plus authorization generation, unless a bounded non-stale continuity proof is separately ratified.
This reversed the record, and the body was rewritten rather than annotated: the earlier design preserved the original workflow UUID and made the three-field identity/node/mount-path match the initial recovery path. Both are gone. Proposal, Design, Tasks, and all three Specification Delta requirements now describe authenticated readmission under a new grant, with the ABA case as an explicit negative test.
Q4 — fell away. It asked which ratified authority survives dormancy to authenticate same-workflow resumption. With resumption refused, nothing needs to survive dormancy and the fresh-JWT-as-own-bootstrap hazard cannot arise. Closed by dependency, not by a separate ruling.
Investigation
Q1 — probe, not an owner question. Inventory deployed auth/tenure proofs usable for readmission authentication under the ratified join.
Q2 — separate probe. Full-environment attestation is now an independent research result, explicitly not the ratified continuity proof and not a readmission prerequisite.
Standing
The title still says "Recover dormant Swarm mounts with a fresh workflow JWT", which reads as the resumption shape the ruling refused. The retitle was not among the ratified implications, so it stands until the freeholder rules on it. Status/Need More Info lifted — no owner question remains. Status/Need Grooming stands for the attestation split and the Q1 probe.
Recover dormant Swarm mounts with a fresh workflow JWTto Readmit a returning Queen under a new grantQ1 probe result — 2026-09-04
Source:
swarm/vordrat000b1bb, static read of the tree. No running system inspected.The inventory is empty, and it is empty on purpose
Q1 asked which deployed auth or tenure proofs could survive dormancy and authenticate a returning Queen. None can, and vordr's design is why.
Two rules in the runtime, both deliberate:
Credentials are never in the environment.
harness.AgentConfig.Envsays it outright — "Not for secrets. A process environment is readable by anything that can see the process, so a credential put here cannot be rotated without killing the drone. Credentials are fetched live over the channel instead."Credentials are fetched live, and are role-scoped.
channelstates it: "Credentials are scoped to the role, not to the fleet: a queen may hold a deploy key while its drones hold a comment-only forge token", and they are "fetched live over the channel, never planted in the environment … Live also means revocable and rotatable without killing a drone mid-task."So nothing durable is held anywhere. A queen's authority exists only while it is connected and holding it, and dies with the process — which, per #13's probe, is the frontend rather than a queen process of its own.
What that does to this record
It confirms the ratified Q3 ruling from the other direction. Q3 already ruled that a return takes a new AssignmentGrant and generation rather than resuming. At the time that was a judgement about ABA-matching a later occupant. It is now also the only mechanically possible answer: there is no surviving proof to authenticate a resumption with, so same-workflow resumption was never available, and refusing it costs nothing that existed.
Q4 was right to fall away, and for a sharper reason than recorded. It asked which ratified authority survives dormancy to authenticate a return without using the fresh credential as its own bootstrap proof. The answer is that none does — so the bootstrap problem it guarded against is not a hazard to design around but the entire problem. A returning Queen has nothing to present.
Result columns
What this leaves
Readmission cannot be authenticated by anything vordr holds today. Whatever admits a returning Queen has to come from outside the runtime — the channel it reconnects to, or an operator act — and choosing between those is a design question for the runtime owner rather than a probe result.
➡️ Hold this record for that decision, or fold it into #13. Both now turn on the same missing thing: a queen has no identity of its own, so neither its death nor its return can be attested. They are two questions about one absent boundary, and answering them apart will produce two designs for it.
The body's rewrite from Q3 stands and needs no revision — it already describes readmission under a new grant, which is what this confirms.
Correction to the probe above — 2026-09-04
Freeholder correction: vordr is a spike. Its current shape is not the final state.
The observations stand: credentials are live-fetched over the channel, never planted in the environment, and role-scoped. What does not stand is the weight I put on them.
The error. I wrote that the inventory is "empty on purpose" and that readmission "cannot be authenticated by anything vordr holds today" — then treated that as settling the question. Two things were wrong with it.
First, "on purpose" over-reads a spike. The no-secrets-in-
Envrule is a real and durable piece of reasoning, and it will very likely survive; but "the spike holds no durable credential" is not the same as "the architecture will hold none", and I ran the two together.Second, and worse: I said the finding "confirms the ratified Q3 ruling from the other direction" — that resumption was never mechanically available. A spike cannot confirm a ruling about the target architecture. Q3 was ratified on the ABA-matching argument, which stands entirely on its own; dressing it in a spike's implementation detail adds nothing and would mislead the next reader into thinking the ruling has support it does not have.
What the probe actually established: the spike carries no durable credential, and the runtime that succeeds it has not yet chosen whether a queen has an identity that outlives its process. Unchosen.
What this changes for the record. Q1 stays open as a probe against the successor runtime. Q3's ruling is untouched and unweakened — it rests on ABA-matching, which is an argument about pool slots and reassignment, not about vordr.
➡️ The previous comment's suggestion to fold this into #13 is withdrawn as premature. It rested on both records turning on one absent boundary, and "absent" was the part I got wrong. They may still deserve one ruling once the successor runtime has a shape — but that is a question to ask then, not a merge to perform now on a spike's evidence.
Second correction — the probe examined an unestablished artifact, 2026-09-04
Freeholder: "I don't know that I ever ran a swarm from vordr successfully, where I ran a few with claude."
Same defect as on #13, and it invalidates this probe's premise.
Q1 asked to inventory the deployed auth and tenure proofs a returning Queen could present. I inventoried vordr's, having never established that vordr runs swarms — and it may never have run one. The swarms that actually ran were Claude-driven.
So "the inventory is empty" was a statement about the wrong tree. It may still turn out to be true of whatever does run swarms, but nothing in that comment is evidence for it, and my saying it "confirms the ratified Q3 ruling from the other direction" was doubly wrong: wrong artifact, and a ruling that never needed the support.
What survives: nothing bearing on this record. The
Env-is-not-for-secrets reasoning is good engineering and belongs to vordr.What Q1 still needs, in order: name the runtime that actually runs a swarm; then inventory what a queen in that runtime holds across a restart.
➡️ Q1 stays open with its first step corrected. Q3's ruling is unaffected and self-supporting — it rests on ABA-matching across pool-slot reassignment, which owes nothing to any runtime's internals.