Ting/Vedanta

Watch

Fork 0

Session: pool bring-up — ten pinned principals and their grants, ratified before activation #30

New issue

Closed

opened 2026-09-03 18:14:55 +00:00 by larandar · 1 comment

larandar commented

2026-09-03 18:14:55 +00:00

Owner

Proposal

Provision the durable drone pool once: ten UUID-pinned principals with reserved names, one immutable AssignmentGrant each, and a human ratification of the realized mapping before any of it becomes active.

Session review boundary

One PR, one verdict over the whole bring-up: name reservation, principal creation, grant issuance, collision and retry behaviour, and the ratification gate. This is a one-time act with a large blast radius and no steady-state loop in it — the checkout/return cycle is a separate Session with a different reviewer question.

Design

Provisioning creates identity and authority, and nothing else. It creates no per-drone Forgejo account, no standing Forge token, and no active lease; pool membership makes all ten eligible for allocation and allocates none of them.

The name is reserved before the principal is created, in the form swarm-alpha-drone-<word>-<word>-<word>-<word>, and the returned UUID is pinned to that name and slot without a rename pass. The ordering is the point: a create-then-name flow has a window in which a principal exists under a name nothing reserved, and a retry across that window is how one slot becomes two principals. A retry therefore adopts matching name/slot metadata, and on collision denies or re-reserves rather than duplicating.

The realized name/UUID/grant-ID/version/digest mapping is presented for ratification before activation. Per the freeholder ruling on Ting/Ting#2 Q4, ratification is presence, not channel: activation blocks on a freeholder act at a keyboard, never on a notification having been sent.

Tasks

Reserve names before creation, and pin the returned UUID to name and slot without renaming.
Provision exactly ten principals, idempotently under retry.
Deny or re-reserve on collision; never duplicate a principal.
Issue one distinct immutable AssignmentGrant per slot, delegated to the swarm-alpha/queen seat.
Present the realized mapping and block activation on a freeholder act.
Prove bring-up creates no Forge account, standing token, or active lease.

Specification Delta

Requirement: bring-up creates eligibility, never an active credential

Scenario: the pool is provisioned

GIVEN an empty pool and a declared swarm-alpha/queen seat
WHEN bring-up runs to completion and is ratified
THEN ten UUID-pinned principals exist, each with one immutable grant
AND no Forgejo account, standing token, or active lease was created

Requirement: a name is reserved before a principal exists

Scenario: provisioning is retried mid-flight

GIVEN a reserved name whose principal creation may already have succeeded
WHEN provisioning retries
THEN it adopts the principal matching that name and slot
AND no second principal is created for the slot
AND a mismatched collision is denied or re-reserved

Requirement: activation waits for a person

Scenario: the mapping is realized but unratified

GIVEN a realized name/UUID/grant mapping
WHEN no freeholder has acted on it
THEN the pool is not active and no slot may be allocated
AND delivery of a notice does not by itself satisfy this

OpenSpec

OpenSpec 30 — agent identity pool lifecycle, which projects from ratified OpenSpec 61 v0.1.4. This Session is its bring-up half; #31 is the other.

Structural parent

Ting/Ting#2 — Epic: agent identity pool lifecycle. Session split ratified there as Q3 (2026-09-03).

## Proposal Provision the durable drone pool once: ten UUID-pinned principals with reserved names, one immutable `AssignmentGrant` each, and a human ratification of the realized mapping before any of it becomes active. ## Session review boundary One PR, one verdict over the whole bring-up: name reservation, principal creation, grant issuance, collision and retry behaviour, and the ratification gate. This is a one-time act with a large blast radius and no steady-state loop in it — the checkout/return cycle is a separate Session with a different reviewer question. ## Design Provisioning creates identity and authority, and nothing else. It creates no per-drone Forgejo account, no standing Forge token, and no active lease; pool membership makes all ten eligible for allocation and allocates none of them. The name is reserved **before** the principal is created, in the form `swarm-alpha-drone-<word>-<word>-<word>-<word>`, and the returned UUID is pinned to that name and slot without a rename pass. The ordering is the point: a create-then-name flow has a window in which a principal exists under a name nothing reserved, and a retry across that window is how one slot becomes two principals. A retry therefore adopts matching name/slot metadata, and on collision denies or re-reserves rather than duplicating. The realized name/UUID/grant-ID/version/digest mapping is presented for ratification before activation. Per the freeholder ruling on [Ting/Ting#2](https://jo.et0.pw/Ting/Ting/issues/2#issuecomment-15365) Q4, ratification is **presence, not channel**: activation blocks on a freeholder act at a keyboard, never on a notification having been sent. ## Tasks - [ ] Reserve names before creation, and pin the returned UUID to name and slot without renaming. - [ ] Provision exactly ten principals, idempotently under retry. - [ ] Deny or re-reserve on collision; never duplicate a principal. - [ ] Issue one distinct immutable `AssignmentGrant` per slot, delegated to the `swarm-alpha/queen` seat. - [ ] Present the realized mapping and block activation on a freeholder act. - [ ] Prove bring-up creates no Forge account, standing token, or active lease. ## Specification Delta ### Requirement: bring-up creates eligibility, never an active credential #### Scenario: the pool is provisioned - **GIVEN** an empty pool and a declared `swarm-alpha/queen` seat - **WHEN** bring-up runs to completion and is ratified - **THEN** ten UUID-pinned principals exist, each with one immutable grant - **AND** no Forgejo account, standing token, or active lease was created ### Requirement: a name is reserved before a principal exists #### Scenario: provisioning is retried mid-flight - **GIVEN** a reserved name whose principal creation may already have succeeded - **WHEN** provisioning retries - **THEN** it adopts the principal matching that name and slot - **AND** no second principal is created for the slot - **AND** a mismatched collision is denied or re-reserved ### Requirement: activation waits for a person #### Scenario: the mapping is realized but unratified - **GIVEN** a realized name/UUID/grant mapping - **WHEN** no freeholder has acted on it - **THEN** the pool is not active and no slot may be allocated - **AND** delivery of a notice does not by itself satisfy this ## OpenSpec [OpenSpec 30 — agent identity pool lifecycle](https://jo.et0.pw/Ting/Vedanta/wiki/OpenSpec-30-agent-identity-pool-lifecycle), which projects from ratified [OpenSpec 61](https://jo.et0.pw/Ting/Ting/wiki/OpenSpec-61-forge-identity-lifecycle-contract) v0.1.4. This Session is its bring-up half; [#31](https://jo.et0.pw/Ting/Vedanta/issues/31) is the other. ## Structural parent [Ting/Ting#2](https://jo.et0.pw/Ting/Ting/issues/2) — Epic: agent identity pool lifecycle. Session split ratified there as Q3 (2026-09-03).

larandar referenced this issue

2026-09-03 18:15:16 +00:00

Session: pool checkout and return — the steady-state slot cycle #31

larandar added the

Kind/Feature

Kind/Security

Meta/Session

labels

2026-09-03 18:15:25 +00:00

larandar referenced this issue from Ting/Ting

2026-09-03 18:18:39 +00:00

Epic: agent identity pool lifecycle — pool-manager service, sibling to the steward #2

larandar referenced this issue

2026-09-03 18:23:54 +00:00

Reserve a slot name before its principal exists, and adopt it on retry #32

larandar referenced this issue

2026-09-03 18:24:07 +00:00

Provision ten pool principals, each with one immutable grant and nothing else #33

larandar referenced this issue

2026-09-03 18:24:22 +00:00

Block pool activation until a freeholder acts on the realized mapping #34

larandar added a new dependency

2026-09-03 18:25:27 +00:00

#32 Reserve a slot name before its principal exists, and adopt it on retry

larandar added a new dependency

2026-09-03 18:25:28 +00:00

#33 Provision ten pool principals, each with one immutable grant and nothing else

larandar added a new dependency

2026-09-03 18:25:29 +00:00

#34 Block pool activation until a freeholder acts on the realized mapping

larandar referenced this issue

2026-09-03 22:25:19 +00:00

pool: bring-up — reserve, provision, and wait for a person #38

larandar commented

2026-09-03 22:34:18 +00:00

Author

Owner

Delivered by PR #38, merged into fastlane at 7b9b5ba. All three leaves closed: #32, #33, #34.

src/pool.rs carries reserve-before-create with adopt-on-retry, ten UUID-pinned principals with one immutable grant each, and the ratification gate. Gate green: fmt, clippy -D warnings, full workspace suite.

What this Session does not give you. PoolDirectory has no Kanidm implementation — the state machine is complete and nothing drives it against a real directory. That waits on sa-vedanta, which is flake-ops#98's owner act. Closing this record says the bring-up logic is written and tested, not that a pool exists.

Delivered by [PR #38](https://jo.et0.pw/Ting/Vedanta/pulls/38), merged into `fastlane` at `7b9b5ba`. All three leaves closed: [#32](https://jo.et0.pw/Ting/Vedanta/issues/32), [#33](https://jo.et0.pw/Ting/Vedanta/issues/33), [#34](https://jo.et0.pw/Ting/Vedanta/issues/34). `src/pool.rs` carries reserve-before-create with adopt-on-retry, ten UUID-pinned principals with one immutable grant each, and the ratification gate. Gate green: fmt, clippy `-D warnings`, full workspace suite. **What this Session does not give you.** `PoolDirectory` has no Kanidm implementation — the state machine is complete and nothing drives it against a real directory. That waits on `sa-vedanta`, which is [flake-ops#98](https://jo.et0.pw/lar.ad/flake-ops/issues/98)'s owner act. Closing this record says the bring-up logic is written and tested, not that a pool exists.

larandar closed this issue

2026-09-03 22:34:21 +00:00

larandar referenced this issue

2026-09-05 20:17:55 +00:00

Session: pool manager bring-up (HITL-gated) #45

larandar referenced this issue

2026-09-05 20:18:23 +00:00

Session: host the private lifecycle service, and retire pool bring-up from Vedanta (ruling D2) #47

larandar referenced this issue from a commit

2026-09-06 02:19:45 +00:00

pool: bring-up leaves this repository — the realized mapping is read, never made