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.

Grooming log

This page records evidence discovered during issue and pull-request grooming so later runs can reuse prior research.

Rules

• Record authoritative rulings, supersessions, contradictions, and cross-repository connections.
• Link the source and distinguish owner rulings, accepted governance, implementation evidence, wiki statements, and agent inference.
• Prefer later authoritative evidence; implementation may obsolete a question but does not create unrelated policy.
• Update an existing entry when its status changes. Do not treat this page itself as authority.
• Before applying Status/Need More Info, search this log and the linked sources.

Entries

Date	Subject	Finding	Authority
2026-08-14	Session delivery	Issue #6 records one PR per working session, not per ticket, while commits remain one-concern each.	Owner ruling
2026-08-16	typed delivery hierarchy	Ruling 6883 defined the typed Campaign → Epic → Session → Deliverable DAG (conformance epoch 2026-08-16 07:20:29 UTC, closed-history waiver). Superseded in part by the freeholder clarification: Session is now optional grooming (Epic → Deliverable is the default; Epic → Session → Deliverable only when positively declared). Ting/Ting#28 (rewritten 2026-08-16T12:05Z) now splits its 64 stable IDs into 47 historical/routine grooming debt, 11 live grooming targets (ordinary groomer/author action, not a freeholder call), and 6 residual freeholder rulings. Only the residual 6 carry Status/Need More Info.	Owner ruling by proxy; decision ledger
2026-08-29	Session sizing	The freeholder clarified in the Forge identity lifecycle grooming thread that a Session is a PR-review constraint: “does this PR fit as 1?” It is not sized by a fixed number of inner units. #20 remains one interface-compatibility review across its six leaves.	Owner ruling
2026-08-26	IDM API-token lifecycle	Freeholder ruling: Vedanta owns mint_api_token, rotate_api_token, and explicit invalidate_api_token for IDM. Jostoph has Forge-only legitimacy, not IDM-plan authority.	Owner ruling, attended grooming
2026-08-26	Roster/directory drift	Vedanta#11 has a live missing-membership case alongside its stale-entity case. Its destructive scope conflicts with Vedanta’s additive-only perimeter; its detector/reporting boundary and bidirectional record scope require grilling.	#11; flake-ops#135; repository perimeter
2026-08-30	Wave-1 D3 / KV assignment isolation	R4 in Ting/Ting#18 and the live flake-ops#96/#178 records still name a per-assignment claim, while the later Ting/Ting#21/OpenSpec 61 production graph omits Vedanta#9 and treats KV-only roads as temporary. The exact retain/retire decision remains open on Vedanta#9 Q1; do not infer that the Forge-capability contract repealed the KV ruling.	Contradictory authoritative scopes
2026-09-03	Forge identity lifecycle — native adapters	Freeholder ruling on Vedanta#20 Q1: Kanidm and Forgejo each get their own native-adapter Deliverable (#8 and #29) rather than one broadened record, because the two issuers have independent APIs, permissions, failure modes, and acceptance doubles. The Session boundary is unchanged — one interface-compatibility verdict still covers every leaf. Closes the structural gap OpenSpec 61 v0.1.4 opened.	Owner ruling, attended grooming
2026-09-03	Queen-death invalidation plane	Freeholder ruling on Vedanta#13 Q3: a Queen death reaches OpenBao leases and the exact downstream resource-token IDs they name, and stops there. The principal-authentication JWT plane is excluded until a separate ruling names its issuer, signing key, and revocation boundary. Applies to any record proposing credential invalidation on abnormal termination, not only #13.	Owner ruling, attended grooming
2026-09-03	Dormancy continuity	Freeholder ruling on Vedanta#14 Q3: after abnormal Queen death 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 #14's prior design (preserved workflow UUID, three-field identity/node/mount-path match), which could ABA-match a later occupant. Treat any same-workflow resumption proposal as refused until such a proof exists.	Owner ruling, attended grooming
2026-09-03	Promotion/suppression Campaign has no OpenSpec root	Vedanta#15's authorized refinement pass found no OpenSpec package for the Campaign: Vedanta's wiki holds only OpenSpec 20, Ting/Ting's only OpenSpec 61. Its six Session nodes (#18, #19, flake-ops#403/#404, nixops4-providers#25/#26) each carry 2-3 tasks and no Specification Delta, so the Session tier is likely unearned. Campaign placement, root shape, and tier dissolution are open as #15 Q1-Q3. Derive no leaf from the current bodies.	Refinement pass; open frontier
2026-09-03	Vedanta's observation mandate	Standing freeholder rule, on Vedanta#11 Q1: Vedanta is in charge of observing ALL drift on the identity plane, and MUST raise an alert where resolution is out of her scope. Creation of permanent identities remains the provider's fief; principal rotation, disabling, and retirement remain Jostoph's; Vedanta acts only on exact resource-credential token IDs. Observation is unbounded within the identity plane, authority to act is not, and silent tolerance of observed-but-unresolvable drift is a defect in Vedanta. Estate-wide — applies to any record proposing to site a detector or to leave known drift unreported. The alert's landing surface is open as #11 Q3.	Owner ruling, attended grooming
2026-09-03	Alert plane	Freeholder ruling on Vedanta#11 Q3: the observation mandate's MUST discharges onto an estate alert plane, created by lar.ad/flake-ops#470 — not telemetry, whose OTLP path is optional by configuration and which no one is obliged to read. The plane must persist beyond the raising run, address the component owning the resolution, reconcile repeated raisings under a stable alert identity, and distinguish resolved from no-longer-observed. Any estate component that separates observation from authority is a future producer; Vedanta's identity-plane drift is the first.	Owner ruling, attended grooming
2026-09-03	Swarm KV ACL paths are unbuilt	Checked for Vedanta#9 Q1: the swarm secret space does not exist in either declared tree — lar.ad/nixops4-providers @ b9c119d has the nixops-openbao flake but no swarm declaration (no swarm-example.nix, no checks.swarm), and lar.ad/flake-ops @ e4290ac has no swarm/data, drones/, or reports/ path in any .nix/.nu. Only the identity half landed (heimdallr's swarm-* groups, openbao-swarm OIDC client, claim maps). So R4's per-assignment isolation is neither superseded by AssignmentGrant/OpenSpec 61 nor live debt — it is a constraint on unbuilt work, belonging to flake-ops#96 which will write the path. The claim-to-alias-metadata mechanism it needs is proven live in #96 comment 6045. Declared trees only; a live OpenBao was not inspected.	Investigation, attended grooming
2026-09-03	Two meanings of "assignment"	The delivered private contract's assignment_id (QueenAuthorityRef, src/private_api.rs) is the QUEEN'S TENURE assignment that authorized a request — one value shared by every drone under a queen. R4's per-assignment isolation (Ting/Ting#18) means which OCCUPANCY of a reusable pool slot is calling. The first cannot separate two occupants of one slot, so it never substitutes for the second; a path built on it looks isolated and is not. The occupancy value rides OpenBao alias custom_metadata, not a claim — a kanidm claim map is valuesByGroup, and per-allocation values have no group to hang on.	Investigation, attended grooming
2026-09-03	Vedanta IS Ting/Ting#2's pool manager	Ting/Ting#2 (2026-08-09) describes the pool manager as "a new, 100%-code service, parallel to the steward … NOT queen's responsibility and NOT Jostoph's either". That predates the naming and reads like a fourth party; it is Vedanta. flake-ops#96 comment 3012 carries both facts together — the rename from the invented "Sevanta", and "Vedanta mints and allocates; Jostoph rotates and disables". ALLOCATION IS CHECKOUT, so pool checkout/reissue is Vedanta's. src/main.rs excluding worker- slots from the mint CLI scopes the one-shot mint against that path; it is not a handoff. A grooming pass misread this on 2026-09-03 and the freeholder corrected it.	Owner correction; cross-repository naming drift
2026-09-04	Deferred mechanism, undeferred behaviour	Freeholder direction on Ting/Ting#2 Q2: leave the pool liveness mechanism undefined — "until we have the problem a few times we will not know". Recorded as a decision rather than a gap by taking the shape that needs no mechanism: nothing infers liveness, and a slot is freed by explicit release alone. The safety property then holds by construction instead of by an unvalidated mechanism, and no acceptance is blocked. GENERAL FORM, reusable beyond this record: when a mechanism is deferred, choose the conservative behaviour that cannot produce the bad outcome, name the failure it does produce, and make that failure the evidence the mechanism will later be designed against — here, pool exhaustion (loud, bounded, recoverable) chosen over silent identity sharing (unbounded, found late).	Owner ruling, attended grooming
2026-09-04	vordr is NOT established as the swarm runtime	Two grooming passes have now read swarm/vordr as "the Queen runtime" and reported its internals as answers to Vedanta#13/#14 — the 2026-08-26 record ("The checked Vordr runtime has an in-process Queen fleet…") and the 2026-09-04 probe. The freeholder states vordr may never have run a swarm successfully; the swarms that ran were Claude-driven. So both passes described an artifact whose relevance was never established, and did so confidently. THE RULE: a probe that asks "what does the deployed X do" must first establish WHICH artifact is deployed — the repository that looks like the runtime is not evidence that it is one, and neither is a previous pass having assumed so. Check phase and check use before treating a tree as evidence. Vordr-internal facts remain true of vordr and bear on nothing else: warden.Sentinel is drone-birth scoped and counts printable bytes rather than bytes (a wedged drone under fish emits 62 bytes of terminal negotiation and none printable); its vordr#93 fix re-checks under lock because a deadline and a disarm can be ready in the same instant.	Owner correction; repeated-error record
2026-09-04	Forgejo tokens do not expire	Checked the deployed instance's OpenAPI description, Forgejo 16.0.3, for Vedanta#29. CreateAccessTokenOption takes name, scopes and repositories only — no TTL on the wire, and no expiry on the AccessToken returned. So a Forge credential's boundedness cannot be requested at mint; it is enforced by the LEASE deleting the exact token, which is a real divergence from the Kanidm adapter, whose mint refuses without an explicit expiry. Also: repositories is Forgejo's native least-scope field (an empty list is account-wide), and /admin/users/{name}/tokens lets one operator identity mint on another account without holding that account's own credential.	Investigation, attended grooming