Remove legacy cli-guard dispatch subsystem if unused #203
Labels
No labels
burndown-2026-06
sunday-sprint
coherence-core
consult
headless
interactive
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
coilyco-flight-deck/cli-guard#203
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Remove the legacy cli-guard dispatch subsystem from the release surface:
cli/dispatch.Rationale: ward now owns agent dispatch. cli-guard dispatch appears to be the older issue-runner and should not ship unless a current consumer still depends on it.
🔒 Reserved by
ward agent --harness codex— containerengineer-codex-cli-guard-203on hostkais-macbook-pro-2.localis carrying this issue (reserved 2026-07-09T02:27:30Z). Concurrentward agentruns are blocked until it finishes or the reservation goes stale (1h TTL);--forceoverrides.Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).
run seed context — what this run is carrying (ward#609)
coilyco-flight-deck/cli-guard#203· branchissue-203· harnesscodex· workflowprengineer-codex-cli-guard-203· wardv0.470.0· dispatched2026-07-09T02:27:30ZStatic container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.470.0).
— Codex, via
ward agentWARD-OUTCOME: done - removed the legacy cli-guard dispatch subsystem from the release surface.
Review gate: skipped because --skip-preflight / --no-preflight also skips review.
The cut was straightforward after confirming nothing else imported cli/dispatch. The only friction was the generated godoc snapshot and example treebuilder cleanup, both resolved cleanly. Confidence is high, and I do not see a follow-up beyond watching for any downstream docs that still mention dispatch.
⚠️ Reopened: this run's work did not land on
mainAn ephemeral
ward container(codex mode) dispatched for this issue finished but its work was not merged tomain, so the reaper preserved it on a branch before teardown and reopened the issue (a closing reference for #203 never reachedmain). Recover from the salvage branch below.coilyco-flight-deck/cli-guardward-salvage/cli-guard-7f69a8f5Reap diagnostics
Recover
— Codex, via
ward agentWARD-RESERVATION: held 🔒
reservation details
Holder: container
engineer-codex-cli-guard-203on hostkais-macbook-pro-2.local.Reserved by
ward agent --harness codex(reserved 2026-07-10T16:54:13Z). Concurrentward agentruns are blocked until it finishes or the reservation goes stale (1h TTL).--forceoverrides.Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).
run seed context — what this run is carrying (ward#609)
coilyco-flight-deck/cli-guard#203· branchissue-203· harnesscodex· workflowpull-requests-and-mergeengineer-codex-cli-guard-203· wardv0.584.0· dispatched2026-07-10T16:54:13ZStatic container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.584.0).
— Codex, via
ward agentWARD-OUTCOME: merge-ready
details
workflow: pull-requests-and-merge; review summary: skipped because review gate skipped by ~/.ward/config.yaml default summary: removed the legacy cli/dispatch subsystem and refreshed the branch onto current main felt: straightforward once the stale PR was merged onto current main and the docs snapshot was regenerated confidence: high surprises: main had drifted, but the dispatch removal still held cleanly follow-ups: merge PR #207