ops-warden/workplans/ADHOC-2026-06-27.md
repo-manager 529feeac49
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
repo.work.assign_missing_identifiers
source: repo-manager
reason: deterministic projection registration

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a058f3-8ba0-7692-a042-9a870fc3d663
2026-09-01 00:51:59 +02:00

1.6 KiB

id type title domain repo status owner topic_slug created updated state_hub_workstream_id
WARDEN-WP-ADHOC-2026-06-27 workplan Ad Hoc Tasks — 2026-06-27 infotech ops-warden finished claude custodian 2026-06-27 2026-06-27 a222c91f-3bb5-58a4-b6b2-f0fb18cdd5c3

Ad Hoc Tasks — 2026-06-27

Low-risk opportunistic fixes completed directly during the consolidation session.

T01 — Fix stale warden CLI install + make it usable outside the repo

id: WARDEN-WP-ADHOC-2026-06-27-T01
status: done
priority: medium
state_hub_task_id: "9176b560-8ca5-5143-888d-479857fe60f0"

issue-core reported (msg 70bcf238) that the warden CLI on ~/.local/bin lacked the route subcommand, forcing a uv run warden fallback.

  • Root cause: uv tool install had reused a cached wheel (version stayed 0.1.0), so the installed warden.cli predated the route/access/policy subcommands. uv cache clean ops-warden + uv tool install . --reinstall fixed it.
  • Deeper cause: even rebuilt, warden route/policy failed outside a checkout because the catalog + posture descriptors live in registry/ at repo root, outside the package. Bundled registry/ into the wheel via hatch force-includewarden/_registry, and added a packaged-data fallback in find_catalog_path / find_posture_path (after the repo walk, so source runs still prefer the repo's registry/ as the single source of truth).
  • Verified warden route list / warden policy list work from /tmp; 200 tests pass, lint clean.