source: repo-manager reason: deterministic projection registration Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a058f3-8ba0-7692-a042-9a870fc3d663
1.6 KiB
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 installhad reused a cached wheel (version stayed0.1.0), so the installedwarden.clipredated theroute/access/policysubcommands.uv cache clean ops-warden+uv tool install . --reinstallfixed it. - Deeper cause: even rebuilt,
warden route/policyfailed outside a checkout because the catalog + posture descriptors live inregistry/at repo root, outside the package. Bundledregistry/into the wheel via hatchforce-include→warden/_registry, and added a packaged-data fallback infind_catalog_path/find_posture_path(after the repo walk, so source runs still prefer the repo'sregistry/as the single source of truth). - Verified
warden route list/warden policy listwork from/tmp; 200 tests pass, lint clean.