rdmsm4x-changelog-20260901-1537-xentropy-rotation-gap-audit-tickets

[2026-09-01 15:37:42 EDT · rdmsm4x]

XEntropy source-code audit found it can plan and request credential rotations but cannot execute one end-to-end (zero outbound provider HTTP client anywhere in Sources/); filed 7 Xentropy feat tickets enumerating exactly what's missing, so the 4 open SEC rotation tickets (Cloudflare Global key, GoDaddy, dataroo.net TLS, 9-repo GitHub exposure) have a concrete build path instead of staying blocked indefinitely.

Scope

• Host: rdmsm4x only. Read-only review of ~/dev/apps/Xentropy source; no Xentropy code was edited (explicit task constraint — swift build run for compile-check only).
• No credential value was read, printed, or quoted at any point. ~/.secrets/global.env was never opened; existence checks used grep -l / counts only.

What changed (new files written this session)

1. /Users/richh/dev/_ops/ecs0lib-audit-20260901/xentropy-rotation-review.md — full audit with file:line citations, every claim paired with a re-runnable command and raw output, positive controls for every "capability is absent" claim.
2. Seven new ticket files under ~/dev/issues/open/ (see below) — no existing ticket file was modified.
3. This changelog + its Apple Notes projection.

Key finding

RotationExecutionBoundary (Sources/XEntropyCore/RotationPlanning.swift:59-61) has exactly one case, ownerAttendedDeferred, applied unconditionally to every rotation-plan step. Zero URLSession/URLRequest/Process()/curl/libcurl hits anywhere in Sources/ (exhaustive grep, positive-controlled against import Foundation → 55 files). The app's own regression tests (SecretLeakBoundaryTests, CredentialCatalogServiceTests, StatelessMCPHandlerTests) already assert rotation.execute is permanently unavailable — this is a declared design boundary, not an oversight. Headless-agent authentication to request a rotation (per-lane HMAC keys, signed inbox files) is already real and working — that part of the brief is not a gap.

Tickets filed (~/dev/issues/bin/ticket open, project Xentropy, parent EPIC-20260829-02)

Each ticket's --desc states what's missing, the file it belongs in, acceptance criteria, and whether it's agent-safe to build/test vs. owner-gated to run against a real provider. Verified via ticket show/ticket tree after filing — blocked_by/relates_to arrays confirmed populated, not just silently accepted.

Verification evidence

• swift build (in app/): rc=0, "Build complete! (0.27 sec)" — exit code captured before any pipe.
• Line counts for the six files the task asked to verify (RotationPlanning.swift 470, RotationRequestInbox.swift 648, AgentRotationRequestService.swift 315, CredentialRotationControlClient.swift 247, CredentialLifecycleCoordinator.swift 297, RedactedCredentialBaseline.swift 572) confirmed exact via wc -l — no discrepancy.
• Every "capability X is absent" claim in the audit doc carries a positive-control grep proving the search methodology works on this codebase (not a broken/empty query).

Backup / undo

Nothing destructive happened. To undo: delete the 7 ticket files under ~/dev/issues/open/ (their filenames are listed in the audit doc's ticket-filing command output) and re-run ticket reindex; delete the audit doc and this changelog pair. No other file was touched.

Outstanding owner actions

• The 4 live SEC rotation tickets (SEC-20260831-01/02/03/07) are still open and still require Rich's own action today — this session did not rotate anything and could not have (that's the finding). ~/.secrets/global.env is untouched.
• Aside, not remediated here: filing tickets surfaced a pre-existing fleet-ticketing-system issue — ticket open/ticket link print a "35 ticket file(s) SHADOWED by a duplicate id" warning on every invocation (unrelated tickets across projects colliding on the same ID, e.g. FEAT-20260901-01). Did not affect the 7 tickets filed here (each individually verified via ticket show); flagged to claude@rdmsm4x rather than fixed in this session, per "stay on task."
• The 7 new tickets are unclaimed/unassigned-to-implementation — filing them was the deliverable, not building them.