No results
Table of contents
This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Documentation log
An index of evidence and a record of wiki-update pass dates for this repository. Not an authority by itself — validate a linked source before relying on a row.
Findings
| Date | Subject | Finding | Authority |
|---|---|---|---|
| 2026-08-14 | Delivery branch | The code as it stands lives on fastlane. main is the forge default branch but trails at f3aecac (2026-08-09, the first gate commit) and describes a service that no longer resembles the one that ships. All three merged PRs (#2, #4, #7) target fastlane. A pass reading main reads a stale repository. The split is now ruled estate-wide: fastlane is the deploy channel and main is reserved for public releases (freeholder ruling, 2026-08-15). |
Accepted governance: AGENTS.md § Version control and delivery — "PR against fastlane. main trails" — and owner ruling #6; freeholder ruling, 2026-08-15, recorded in Ting/Ting#18 |
| 2026-08-14 | Directory: lldap → kanidm | The effector is src/kanidm.rs: one bearer api-token as sa-vedanta, POST /v1/service_account, UUID read back, then POST /v1/group/<g>/_attr/member. src/lldap.rs is gone, ldap3 left the dependency graph, module.nix exposes services.vedanta.kanidm.{url,group}. README.md still describes creating an lldap user; that clause is superseded, not a live contract. Do not re-litigate. |
Owner ruling #5 (2026-08-11), delivered by merged PR #7 |
| 2026-08-14 | Principal prefix vs directory name | a+/sa+/worker- is a JWT sub contract, not a directory name: kanidm refuses + in name (400 schemaviolation) but accepts it in mail. The entity is a-freki/sa-librefang, the plus-addressed mailbox survives, and the two are joined by UUID. principal-shape still gates on the + spelling; kanidm::directory_name performs the total +→- transform. |
Owner ruling #5, from a live probe of kanidm 1.11 |
| 2026-08-14 | Substrate distribution | vendor/jostoph-rs is not tracked here and must not be committed again; it is materialized from the jostoph-rs flake input (midgard/jostoph-rs, anonymous HTTPS) and stays a Cargo path dependency, with the pin in flake.lock. The vendoring PR #2 landed was explicitly provisional. |
Issue #3 closed by merged PR #4; publish pattern ruled in Ting/Jostoph#3 |
| 2026-08-14 | In-tree docs trailing the port | CONTEXT.md § What does not exist still says group membership is unbuilt and create_user sets id/email/displayName only, and counts one test; the shipped effector sets name/displayname/mail and joins the roster group, and there are three tests. AGENTS.md still names AdminClient::create_user in perimeter rule 3 and a "real admin bind credential" in the gigachad hazard, where the justfile now pipes one bearer token. The port ruling governs; correcting the tree is review's, not this pass's. |
Owner ruling #5 |
| 2026-08-14 | Estate placement | Ting/Ting's PROJECTS.md names no project holding Ting/Vedanta (or its sibling Ting/Jostoph); the repository's scope authority is Ting/Ting#2 alone. Nothing rules this a gap — recorded so the next pass does not search for a project assignment that does not exist. |
None (cross-repository, unruled) |
| 2026-08-21 | Birth vs lifecycle | mint-agent/mint-service create the kanidm entity — 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: "birth = #2's provider (declared nixops surface); drift/lifecycle enforcement = Vedanta" (flake-ops#89, 2026-08-12), read the same way by flake-ops#123 and by comment 3601. The first-wave plan proposes the carve-out that would settle it — provider births identities known at flake-eval time, Vedanta mints those that are not — and asks for it to be ruled (Ting/Ting#18, §3); the 2026-08-15 ratifications (R1–R4) do not cover it. Deviates: contradicts the 2026-08-12 ruling, later than this repository's own #5. Flagged in #10. Recorded, not ratified. |
Owner ruling (flake-ops#89) |
| 2026-08-21 | SA api-token minting | No _api_token call exists in src/kanidm.rs, and sa-vedanta's token answers 403 on POST /v1/service_account/{id}/_api_token (flake-ops#123, open). Ruled work not yet done, not drift: R3, ratified 2026-08-15, makes SA api-token minting Vedanta's, granted by entry-scoped entry_managed_by delegation rather than by widening sa-vedanta's blanket idm_service_account_admins/idm_group_admins membership, pending one live probe. Tracked by #8. CONTEXT.md § Open, and owner-gated still calls the rights question uncosted; that clause trails R3. |
Owner ruling (R3, Ting/Ting#18) |
| 2026-08-21 | Roster group hazard closed | CONTEXT.md § The roster group is not deployed… and src/kanidm.rs's DEFAULT_GROUP comment describe two hazards as live — agents undeployed, and overwriteMembers wiping it at activation. The live probe of 2026-08-12 placed sa-test in agents and it survived a second activation; flake-ops#99 closed on that evidence (comment 3655). Behaviour is unaffected — the kanidm.group option and the partial-success report stand — but both in-tree statements now trail the record. Correcting the tree is review's, not this pass's. |
Live probe recorded in flake-ops#89; flake-ops#99 closed |
Passes
- 2026-08-21 — bound by the 2026-08-14 pass.
fastlaneis unchanged at5003add(last code commit 2026-08-11), so the code was re-read at that head alongsidemain, issues #5/#6/#8/#9 and the first-wave plan on Ting/Ting#18. No page describes the code, so none needed re-describing; three findings added and the delivery-branch row updated. One unjustified deviation (birth vs lifecycle), flagged on #10, the canonical wiki-sync issue opened this pass. No pull request is open, so nothing was commented on. - 2026-08-14 — first recorded pass; no prior bound, so the current state was read broadly (
fastlanetree,main, issues #1/#3/#5/#6, merged PRs #2/#4/#7). No page needed syncing: the wiki carried onlygrooming-log, which is true. No unjustified deviation found, so no canonical issue was opened and no pull-request comment was written (none are open).