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

New issue

Closed

opened 2026-09-03 18:24:07 +00:00 by larandar · 0 comments

larandar commented

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

Owner

Proposal

Create the pool: exactly ten UUID-pinned principals, each carrying one distinct immutable AssignmentGrant delegated to the swarm-alpha/queen seat.

Delivery class

agent-unit — provisioning and grant issuance against Kanidm capture doubles.

Design

Provisioning creates identity and authority, and nothing else. Pool membership makes all ten eligible for allocation and allocates none of them. It creates no per-drone Forgejo account, no standing Forge token, and no active lease — those belong to a lease at checkout, not to a principal at birth, and a pool that hands them out at provisioning has ten standing credentials nobody is using.

Each slot's grant is distinct and immutable. One grant shared across slots would make the pool one principal wearing ten names; a mutable grant would let a later session inherit an earlier one's authority by amendment rather than by issue.

Consumes the reservation and adoption behaviour of #32, so provisioning is idempotent under retry rather than merely usually-correct.

Tasks

Provision exactly ten principals over reserved names, idempotently under retry.
Issue one distinct immutable AssignmentGrant per slot, delegated to the swarm-alpha/queen seat.
Prove no Forgejo account, standing Forge token, or active lease is created.
Prove re-running provisioning converges rather than growing the pool.

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 provisioning completes
THEN ten UUID-pinned principals exist, each carrying one distinct immutable grant
AND no Forgejo account, standing Forge token, or active lease was created

Scenario: provisioning runs twice

GIVEN a provisioned pool
WHEN provisioning runs again
THEN the pool still holds exactly ten principals

OpenSpec

OpenSpec 30

Structural parent

Vedanta#30

## Proposal Create the pool: exactly ten UUID-pinned principals, each carrying one distinct immutable `AssignmentGrant` delegated to the `swarm-alpha/queen` seat. ## Delivery class `agent-unit` — provisioning and grant issuance against Kanidm capture doubles. ## Design Provisioning creates **identity and authority, and nothing else**. Pool membership makes all ten eligible for allocation and allocates none of them. It creates no per-drone Forgejo account, no standing Forge token, and no active lease — those belong to a lease at checkout, not to a principal at birth, and a pool that hands them out at provisioning has ten standing credentials nobody is using. Each slot's grant is distinct and immutable. One grant shared across slots would make the pool one principal wearing ten names; a mutable grant would let a later session inherit an earlier one's authority by amendment rather than by issue. Consumes the reservation and adoption behaviour of [#32](https://jo.et0.pw/Ting/Vedanta/issues/32), so provisioning is idempotent under retry rather than merely usually-correct. ## Tasks - [ ] Provision exactly ten principals over reserved names, idempotently under retry. - [ ] Issue one distinct immutable `AssignmentGrant` per slot, delegated to the `swarm-alpha/queen` seat. - [ ] Prove no Forgejo account, standing Forge token, or active lease is created. - [ ] Prove re-running provisioning converges rather than growing the pool. ## 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** provisioning completes - **THEN** ten UUID-pinned principals exist, each carrying one distinct immutable grant - **AND** no Forgejo account, standing Forge token, or active lease was created #### Scenario: provisioning runs twice - **GIVEN** a provisioned pool - **WHEN** provisioning runs again - **THEN** the pool still holds exactly ten principals ## OpenSpec [OpenSpec 30](https://jo.et0.pw/Ting/Vedanta/wiki/OpenSpec-30-agent-identity-pool-lifecycle) ## Structural parent [Vedanta#30](https://jo.et0.pw/Ting/Vedanta/issues/30)

larandar added the

Kind/Feature

Kind/Security

labels

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

larandar added a new dependency

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

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

larandar added a new dependency

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

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

larandar referenced this issue from a commit