Wiki sync: unjustified deviations #10

New issue

Open

opened 2026-08-21 19:03:11 +00:00 by codexo · 0 comments

codexo commented

2026-08-21 19:03:11 +00:00

Pass: 2026-08-21

Unjustified deviations

mint-agent / mint-service create kanidm service accounts — create_service_account in src/kanidm.rs (POST /v1/service_account), called from mint() in src/main.rs. A later owner ruling assigns that act elsewhere: "Also ruled: birth = #2's provider (declared nixops surface); drift/lifecycle enforcement = Vedanta" (lar.ad/flake-ops#89, 2026-08-12). lar.ad/flake-ops#123 reads it the same way — "#89 grill: #2's provider births, Vedanta converges/rotates" — and the same thread's research note states it again: "#2's provider births SAs, Vedanta converges them" (comment 3601).
This repository's own authority for the effector is earlier: Ting/Vedanta#5 (owner ruling, 2026-08-11), delivered by merged PR #7.
The first-wave plan names the same tension and proposes a carve-out — provider-declared birth for identities known at flake-eval time, Vedanta-minted creation for those that are not — and says of it: "it should be written down as a ruling, not left implicit" (Ting/Ting#18, §3). The 2026-08-15 ratifications cover R1–R4; none of them covers that carve-out, so the proposal is a synthesis, not an authority.
Recorded in the wiki documentation-log, marked, not ratified.
Larandar: ruling required — does Vedanta's mint path stand as birth for runtime, not-known-ahead-of-time identities, or does birth belong wholly to the nixops-kanidm provider?

Justified this pass

The kanidm effector's shape — service accounts rather than persons, one bearer api-token as sa-vedanta, +→- directory names joined by UUID, roster-group join with partial success reported and not rolled back — is covered by owner ruling Ting/Vedanta#5 (2026-08-11), delivered by merged PR #7. Wiki rows stand; no flag.

Not deviations, recorded so the next pass does not re-open them

No _api_token call exists in src/kanidm.rs, and sa-vedanta's token answers 403 on POST /v1/service_account/{id}/_api_token (lar.ad/flake-ops#123, open). This is ruled work not yet done, not drift: R3, ratified 2026-08-15, makes SA api-token minting Vedanta's by way of entry-scoped entry_managed_by delegation rather than a wider blanket membership, pending the live probe. Tracked by #8.
CONTEXT.md § The roster group is not deployed, and will eat its own members and src/kanidm.rs's DEFAULT_GROUP comment both describe two hazards as live. The live probe of 2026-08-12 placed sa-test in agents and it survived a second activation; lar.ad/flake-ops#99 closed on that evidence (comment 3655). Behaviour is unaffected. Both statements are in-tree prose trailing the record; correcting the tree is review's, not this pass's.

This issue is the repository's one wiki-sync record. It is edited in place each pass and is not closed.

**Pass:** 2026-08-21 ### Unjustified deviations - `mint-agent` / `mint-service` **create** kanidm service accounts — `create_service_account` in `src/kanidm.rs` (`POST /v1/service_account`), called from `mint()` in `src/main.rs`. A later owner ruling assigns that act elsewhere: *"Also ruled: birth = #2's provider (declared nixops surface); drift/lifecycle enforcement = Vedanta"* ([lar.ad/flake-ops#89, 2026-08-12](https://jo.et0.pw/lar.ad/flake-ops/issues/89#issuecomment-3593)). [lar.ad/flake-ops#123](https://jo.et0.pw/lar.ad/flake-ops/issues/123) reads it the same way — *"#89 grill: #2's provider births, Vedanta converges/rotates"* — and the same thread's research note states it again: *"#2's provider births SAs, Vedanta converges them"* ([comment 3601](https://jo.et0.pw/lar.ad/flake-ops/issues/89#issuecomment-3601)). This repository's own authority for the effector is earlier: [Ting/Vedanta#5](https://jo.et0.pw/Ting/Vedanta/issues/5) (owner ruling, 2026-08-11), delivered by merged [PR #7](https://jo.et0.pw/Ting/Vedanta/pulls/7). The first-wave plan names the same tension and proposes a carve-out — provider-declared birth for identities known at flake-eval time, Vedanta-minted creation for those that are not — and says of it: *"it should be written down as a ruling, not left implicit"* ([Ting/Ting#18](https://jo.et0.pw/Ting/Ting/issues/18#issuecomment-5392), §3). The 2026-08-15 ratifications cover R1–R4; none of them covers that carve-out, so the proposal is a synthesis, not an authority. Recorded in the wiki `documentation-log`, marked, not ratified. **Larandar:** ruling required — does Vedanta's mint path stand as birth for runtime, not-known-ahead-of-time identities, or does birth belong wholly to the nixops-kanidm provider? ### Justified this pass - The kanidm effector's shape — service accounts rather than persons, one bearer api-token as `sa-vedanta`, `+`→`-` directory names joined by UUID, roster-group join with partial success reported and not rolled back — is covered by owner ruling [Ting/Vedanta#5](https://jo.et0.pw/Ting/Vedanta/issues/5) (2026-08-11), delivered by merged [PR #7](https://jo.et0.pw/Ting/Vedanta/pulls/7). Wiki rows stand; no flag. ### Not deviations, recorded so the next pass does not re-open them - No `_api_token` call exists in `src/kanidm.rs`, and `sa-vedanta`'s token answers `403` on `POST /v1/service_account/{id}/_api_token` ([lar.ad/flake-ops#123](https://jo.et0.pw/lar.ad/flake-ops/issues/123), open). This is ruled work not yet done, not drift: R3, ratified 2026-08-15, makes SA api-token minting Vedanta's by way of entry-scoped `entry_managed_by` delegation rather than a wider blanket membership, pending the live probe. Tracked by [#8](https://jo.et0.pw/Ting/Vedanta/issues/8). - `CONTEXT.md` § *The roster group is not deployed, and will eat its own members* and `src/kanidm.rs`'s `DEFAULT_GROUP` comment both describe two hazards as live. The live probe of 2026-08-12 placed `sa-test` in `agents` and it survived a second activation; [lar.ad/flake-ops#99](https://jo.et0.pw/lar.ad/flake-ops/issues/99) closed on that evidence ([comment 3655](https://jo.et0.pw/lar.ad/flake-ops/issues/89#issuecomment-3655)). Behaviour is unaffected. Both statements are in-tree prose trailing the record; correcting the tree is review's, not this pass's. This issue is the repository's one wiki-sync record. It is edited in place each pass and is not closed.