coilyco-flight-deck/ward

Archived

Watch

Ward to gli guard dead code and interface analysis #206

Closed

opened 2026-06-19 03:43:30 +00:00 by coilysiren · 6 comments

coilysiren commented

2026-06-19 03:43:30 +00:00

Owner

No description provided.

coilyco-ops added the

autonomy

async-consult

priority

labels

2026-06-24 04:15:37 +00:00

coilyco-ops commented

2026-06-24 17:27:06 +00:00

Owner

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P4 - Dead-code/interface analysis, vague cleanup, icebox.
consult - Open-ended analysis needing a human to scope.

**Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P4** - Dead-code/interface analysis, vague cleanup, icebox. - **consult** - Open-ended analysis needing a human to scope.

coilyco-ops commented

2026-06-24 17:29:25 +00:00

Owner

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P4 - Dead-code/interface analysis, vague cleanup, icebox.
consult - Open-ended analysis needing a human to scope.

coilyco-ops added

and removed

labels

2026-07-02 00:19:02 +00:00

coilyco-ops commented

2026-07-02 00:21:36 +00:00

Owner

Flipped headless: deliverable is a dead-code + interface-boundary analysis (ward vs cli-guard) with PR-able removals. Feeds the #265 umbrella. Recorded by Claude Code (Fable) during the 2026-07-01 ward launch triage session with Kai.

coilyco-ops commented

2026-07-02 17:16:13 +00:00

Owner

🔎 ward agent advisor

ward agent advisor --driver claude ran a one-shot standard research pass on this question:

Run a read-only dead-code + interface analysis across ward and cli-guard (ward#206) and post a findings report as a comment. No writes. Identify: unreferenced exported symbols, dead switch arms / legacy shims kept 'for now' (e.g. the ward#418->#401 Phase 4 hostPreflightArgv-style leftovers), interfaces with a single implementation that could collapse, and ward-over-cli-guard graft/shadow layers (relate to ward#407). Prefer evidence from go tooling (deadcode, staticcheck, unused-symbol greps) over speculation, cite file:line, and rank by cleanup value vs risk. Read cli-guard from /substrate if present. End noting it is a plan to verify. Repo voice rules (no em-dashes, no semicolons in prose, name the actor).

ward#206 - dead-code + interface analysis (ward, read-only)

This is a plan to verify, not a landed change. All evidence below is from go vet-adjacent tooling run against a clean checkout at ~/projects/coilyco-flight-deck/ward (HEAD 282b255). The runner ran golang.org/x/tools/cmd/deadcode ./... plus targeted symbol greps. cli-guard was not readable this session (no /substrate mount on the host, no local clone), so the ward-over-cli-guard cross-boundary duplication claims are scoped to what ward imports and are flagged as the verify step. Every finding below is a candidate for a PR-able removal; the agent proposes, a human confirms before deletion.

Method

deadcode - deadcode ./... reports 17 unreachable functions (reachability from main, test files excluded). Full list cited inline.
test-only cross-check - for each dead func, the agent greped *_test.go for references. A func that is unreachable from main and referenced by a test is tested but dead: the test keeps it green while production never calls it. Several here are exactly that.
staticcheck U1000 returned nothing, which is expected: U1000 does not flag package-main functions that a test references, so deadcode is the sharper instrument here.

Findings, ranked by cleanup value vs risk

A. agent_adapter.go - fully orphaned cli-guard graft layer (HIGH value, LOW risk).
The entire file is unreachable. deadcode flags all five funcs:

cmd/ward/agent_adapter.go:36 agentAdapter.preflightArgv
cmd/ward/agent_adapter.go:53 agentManifest.adapter
cmd/ward/agent_adapter.go:64 loadAgentManifest
cmd/ward/agent_adapter.go:78 fleetToAgentManifest (0 test refs - fully orphaned)
cmd/ward/agent_adapter.go:99 validateAgentManifest

This file imports cli-guard/pkg/fleetconfig and projects the embedded fleet roster onto a parallel agentAdapter shape. It is a ward-over-cli-guard graft (relates to ward#407) that was superseded by the live internal/agents registry (Registry() / Lookup() in internal/agents/registry.go). The header comment already records that ward#419 dropped the YAML mirror; the projection code is the leftover. Proposed removal: delete agent_adapter.go, its agent_adapter_test.go, and docs/agent-adapter-manifest.md. loadFleetConfig stays (production parseMode still uses it), so this is a clean leaf cut.

B. Phase-4 dead switches - the explicit ward#418 -> #401 leftover (HIGH value, LOW-to-MED risk).
The issue named the hostPreflightArgv-style Phase 4 leftovers, and they are here. These per-mode Go switches were superseded by the agentsapi.Agent registry, and are kept alive only by the transitional contract test TestRegistryMatchesHardcodedSwitches (cmd/ward/agents_registry_contract_test.go), which asserts the new registry agrees entry-for-entry with the old switches. The //nolint:unparam on hostPreflightArgv says so in-line: 'only the contract test's constant prompt remains until Phase 4 deletes this switch.'

cmd/ward/container_compute.go:187 containerMode.agentBinary
cmd/ward/container_compute.go:204 containerMode.hostPreflightArgv
cmd/ward/container_compute.go:219 containerMode.contextLevel
cmd/ward/agent_signature.go:39 containerMode.agentSigner
cmd/ward/agent_signature.go:20 containerMode.agentIdentity (0 production callers outside the switch chain)
cmd/ward/agent_signature.go:51 containerMode.agentAttribution

deadcode confirms none are reachable from main, so production is already fully on the registry (lookupAgent(mode).PreflightArgv(...) at agent.go:656, agent_route.go:217, agent_reply.go:217, agent_director_triage.go:280, agent_director_heartbeat.go:269). The switches and their pinning contract test are a matched pair: they delete together as the Phase-4 cutover under ward#401. Risk is the migration-completeness check - the reviewer confirms the registry covers every mode the switches did (the sibling TestRegistryCoversEveryMode gives that guarantee) before removing the parity test. containerMode itself stays (heavily used); only these three methods on it die.

C. dockerSockMount - dead code that is also a footgun (MED-HIGH value, LOW risk).

cmd/ward/container_compute.go:377 dockerSockMount - unreachable, 1 test ref.

Its own comment: 'binds the host docker socket read-write.' A read-write docker-socket bind is a container-escape surface. Dead and security-relevant: removing it deletes a latent privilege footgun at zero behavioral cost. Clean delete.

D. Substrate Go parser - a second parse of a file the container reads raw (LOW-MED value, MED risk).

cmd/ward/container.go:33 loadSubstrateManifest
cmd/ward/container_compute.go:136 parseSubstrateManifest
cmd/ward/container_compute.go:128 substrateRepo.slug (0 test refs - fully dead)

Production does not parse the manifest in Go. The container bootstrap passes the manifest path through at runtime (container_bootstrap.go:132, WARD_SUBSTRATE_MANIFEST=/opt/ward/preclone-repos.txt) and the in-container side consumes the raw file. The Go parser survives only as a test-time validator of the embedded preclone-repos.txt. Recommendation is nuanced: delete substrateRepo.slug now (nothing references it), but do not blind-delete the parser - either keep it as an explicit embed-validation guard or convert it into one, so a malformed preclone-repos.txt still fails loud in CI. This is the one finding where deletion loses a guard.

E. fleetlocal.go - authored-ahead-of-use, not a mistake (decide, do not silently delete).

cmd/ward/fleetlocal.go:20 operatorLocalConfigPath
cmd/ward/fleetlocal.go:30 loadOperatorLocalConfig

Both unreachable from main, each with 1 test ref. This is the dialect-3 operator-local config reader (~/.ward/fleet.local.kdl) documented in docs/fleet-local.md and docs/ward-kdl-authoring.md, and it is the exact 'operator-local preference' config axis the AGENTS doctrine calls out. It reads real, planned, documented infrastructure that was never wired into a load path. The right move is a decision, not a deletion: wire it into the fleet-config merge or drop the feature (code + both doc references) as one change. Left as-is it is a dangling documented feature that reads as done.

Interfaces with a single implementation (considered, mostly rejected)

The agentsapi capability interfaces were checked for single-impl collapse:

CredentialProvider (ResolveCreds/WriteCreds) - claude, codex (2)
ConfigComposer - codex, opencode, goose (3)
LaunchGate (PreLaunchCheck) - claude, opencode, goose (3)
Installer (Install) - opencode only (1)
OnboardingSeeder (SeedOnboarding) - claude only (1)

Installer and OnboardingSeeder have one implementer each, but the agent recommends keeping both. These are optional-capability feature-test interfaces (core does if x, ok := agent.(Installer); ok { ... }), not polymorphism points. The interface earns its place by making the capability optional even at count one; collapsing it would force every agent to carry a no-op method or push core to type-switch on concretes. This is a deliberate pattern in internal/agentsapi/agentsapi.go, not accidental over-abstraction. Noted for completeness, no change proposed.

ward-over-cli-guard graft surface (verify step, needs cli-guard read)

ward imports 14 cli-guard packages (non-test): fleetconfig (8 sites), config (7), broker (7), attribution (7), exitcode (6), audit (5), scan (3), credseed (3), valuesource (2), then version, scope, ownertrust, issueref, flock (1 each). Finding A is the one confirmed graft-and-orphan (ward re-projects fleetconfig into a shape nothing reads). Whether ward shadows logic that cli-guard already owns (e.g. a second parse/validate of something cli-guard exports) cannot be settled from ward alone. That is the ward#407-shaped question and it requires reading cli-guard from /substrate inside a container, which was unavailable this session. Recommended next pass: run the same deadcode + import-seam analysis with cli-guard on disk, focused on fleetconfig, attribution, and config, to find ward-side re-implementations of cli-guard-owned behavior.

Suggested PR slicing (feeds the #265 umbrella)

Cut A - delete agent_adapter.go + test + doc. Self-contained leaf, lowest risk, do first.
Cut C - delete dockerSockMount. Independent, trivial, security win.
Cut B - Phase-4 switch removal + retire the parity contract test, under ward#401. Gate on TestRegistryCoversEveryMode staying green.
Decision D - drop substrateRepo.slug, convert the parser to an explicit embed check.
Decision E - wire-or-drop fleetlocal.go (own issue, needs a product call).
Verify - re-run with cli-guard mounted for the true cross-boundary (#407) shadow analysis.

Every deletion above must be re-confirmed by the reviewer with deadcode ./... returning clean for the removed symbols and ward test (the full suite) green after each cut, since some dead funcs are load-bearing for their own tests and those tests delete with them.

Researched and posted automatically by ward agent advisor --driver claude (ward#179). This is one-shot research, not a carried change - verify before acting on it.

— Claude (she/her), via ward agent

### 🔎 ward agent advisor `ward agent advisor --driver claude` ran a one-shot **standard** research pass on this question: > Run a read-only dead-code + interface analysis across ward and cli-guard (ward#206) and post a findings report as a comment. No writes. Identify: unreferenced exported symbols, dead switch arms / legacy shims kept 'for now' (e.g. the ward#418->#401 Phase 4 hostPreflightArgv-style leftovers), interfaces with a single implementation that could collapse, and ward-over-cli-guard graft/shadow layers (relate to ward#407). Prefer evidence from go tooling (deadcode, staticcheck, unused-symbol greps) over speculation, cite file:line, and rank by cleanup value vs risk. Read cli-guard from /substrate if present. End noting it is a plan to verify. Repo voice rules (no em-dashes, no semicolons in prose, name the actor). --- ## ward#206 - dead-code + interface analysis (ward, read-only) **This is a plan to verify, not a landed change.** All evidence below is from `go vet`-adjacent tooling run against a clean checkout at `~/projects/coilyco-flight-deck/ward` (HEAD `282b255`). The runner ran `golang.org/x/tools/cmd/deadcode ./...` plus targeted symbol greps. cli-guard was **not** readable this session (no `/substrate` mount on the host, no local clone), so the ward-over-cli-guard cross-boundary duplication claims are scoped to what ward imports and are flagged as the verify step. Every finding below is a candidate for a **PR-able removal**; the agent proposes, a human confirms before deletion. ### Method * **deadcode** - `deadcode ./...` reports 17 unreachable functions (reachability from `main`, test files excluded). Full list cited inline. * **test-only cross-check** - for each dead func, the agent greped `*_test.go` for references. A func that is unreachable from `main` **and** referenced by a test is *tested but dead*: the test keeps it green while production never calls it. Several here are exactly that. * **staticcheck U1000** returned nothing, which is expected: U1000 does not flag package-`main` functions that a test references, so deadcode is the sharper instrument here. ### Findings, ranked by cleanup value vs risk **A. `agent_adapter.go` - fully orphaned cli-guard graft layer (HIGH value, LOW risk).** The entire file is unreachable. deadcode flags all five funcs: * `cmd/ward/agent_adapter.go:36` `agentAdapter.preflightArgv` * `cmd/ward/agent_adapter.go:53` `agentManifest.adapter` * `cmd/ward/agent_adapter.go:64` `loadAgentManifest` * `cmd/ward/agent_adapter.go:78` `fleetToAgentManifest` (**0** test refs - fully orphaned) * `cmd/ward/agent_adapter.go:99` `validateAgentManifest` This file imports `cli-guard/pkg/fleetconfig` and projects the embedded fleet roster onto a parallel `agentAdapter` shape. It is a **ward-over-cli-guard graft** (relates to **ward#407**) that was superseded by the live `internal/agents` registry (`Registry()` / `Lookup()` in `internal/agents/registry.go`). The header comment already records that **ward#419** dropped the YAML mirror; the projection code is the leftover. Proposed removal: delete `agent_adapter.go`, its `agent_adapter_test.go`, and `docs/agent-adapter-manifest.md`. `loadFleetConfig` stays (production `parseMode` still uses it), so this is a clean leaf cut. **B. Phase-4 dead switches - the explicit ward#418 -> #401 leftover (HIGH value, LOW-to-MED risk).** The issue named the `hostPreflightArgv`-style Phase 4 leftovers, and they are here. These per-mode Go switches were superseded by the `agentsapi.Agent` registry, and are kept alive **only** by the transitional contract test `TestRegistryMatchesHardcodedSwitches` (`cmd/ward/agents_registry_contract_test.go`), which asserts the new registry agrees entry-for-entry with the old switches. The `//nolint:unparam` on `hostPreflightArgv` says so in-line: *'only the contract test's constant prompt remains until Phase 4 deletes this switch.'* * `cmd/ward/container_compute.go:187` `containerMode.agentBinary` * `cmd/ward/container_compute.go:204` `containerMode.hostPreflightArgv` * `cmd/ward/container_compute.go:219` `containerMode.contextLevel` * `cmd/ward/agent_signature.go:39` `containerMode.agentSigner` * `cmd/ward/agent_signature.go:20` `containerMode.agentIdentity` (**0** production callers outside the switch chain) * `cmd/ward/agent_signature.go:51` `containerMode.agentAttribution` deadcode confirms none are reachable from `main`, so production is already fully on the registry (`lookupAgent(mode).PreflightArgv(...)` at `agent.go:656`, `agent_route.go:217`, `agent_reply.go:217`, `agent_director_triage.go:280`, `agent_director_heartbeat.go:269`). The switches and their pinning contract test are a **matched pair**: they delete together as the Phase-4 cutover under **ward#401**. Risk is the migration-completeness check - the reviewer confirms the registry covers every mode the switches did (the sibling `TestRegistryCoversEveryMode` gives that guarantee) before removing the parity test. `containerMode` itself stays (heavily used); only these three methods on it die. **C. `dockerSockMount` - dead code that is also a footgun (MED-HIGH value, LOW risk).** * `cmd/ward/container_compute.go:377` `dockerSockMount` - unreachable, 1 test ref. Its own comment: *'binds the host docker socket read-write.'* A read-write docker-socket bind is a container-escape surface. Dead **and** security-relevant: removing it deletes a latent privilege footgun at zero behavioral cost. Clean delete. **D. Substrate Go parser - a second parse of a file the container reads raw (LOW-MED value, MED risk).** * `cmd/ward/container.go:33` `loadSubstrateManifest` * `cmd/ward/container_compute.go:136` `parseSubstrateManifest` * `cmd/ward/container_compute.go:128` `substrateRepo.slug` (**0** test refs - fully dead) Production does not parse the manifest in Go. The container bootstrap passes the manifest **path** through at runtime (`container_bootstrap.go:132`, `WARD_SUBSTRATE_MANIFEST=/opt/ward/preclone-repos.txt`) and the in-container side consumes the raw file. The Go parser survives only as a test-time validator of the embedded `preclone-repos.txt`. Recommendation is nuanced: delete `substrateRepo.slug` now (nothing references it), but do **not** blind-delete the parser - either keep it as an explicit embed-validation guard or convert it into one, so a malformed `preclone-repos.txt` still fails loud in CI. This is the one finding where deletion loses a guard. **E. `fleetlocal.go` - authored-ahead-of-use, not a mistake (decide, do not silently delete).** * `cmd/ward/fleetlocal.go:20` `operatorLocalConfigPath` * `cmd/ward/fleetlocal.go:30` `loadOperatorLocalConfig` Both unreachable from `main`, each with 1 test ref. This is the **dialect-3 operator-local config** reader (`~/.ward/fleet.local.kdl`) documented in `docs/fleet-local.md` and `docs/ward-kdl-authoring.md`, and it is the exact 'operator-local preference' config axis the AGENTS doctrine calls out. It reads real, planned, documented infrastructure that was never wired into a load path. The right move is a **decision**, not a deletion: wire it into the fleet-config merge or drop the feature (code + both doc references) as one change. Left as-is it is a dangling documented feature that reads as done. ### Interfaces with a single implementation (considered, mostly rejected) The `agentsapi` capability interfaces were checked for single-impl collapse: * `CredentialProvider` (ResolveCreds/WriteCreds) - claude, codex (2) * `ConfigComposer` - codex, opencode, goose (3) * `LaunchGate` (PreLaunchCheck) - claude, opencode, goose (3) * `Installer` (Install) - **opencode only (1)** * `OnboardingSeeder` (SeedOnboarding) - **claude only (1)** `Installer` and `OnboardingSeeder` have one implementer each, but the agent recommends **keeping both**. These are optional-capability feature-test interfaces (core does `if x, ok := agent.(Installer); ok { ... }`), not polymorphism points. The interface earns its place by making the capability *optional* even at count one; collapsing it would force every agent to carry a no-op method or push core to type-switch on concretes. This is a deliberate pattern in `internal/agentsapi/agentsapi.go`, not accidental over-abstraction. Noted for completeness, no change proposed. ### ward-over-cli-guard graft surface (verify step, needs cli-guard read) ward imports 14 cli-guard packages (non-test): `fleetconfig` (8 sites), `config` (7), `broker` (7), `attribution` (7), `exitcode` (6), `audit` (5), `scan` (3), `credseed` (3), `valuesource` (2), then `version`, `scope`, `ownertrust`, `issueref`, `flock` (1 each). Finding **A** is the one confirmed graft-and-orphan (ward re-projects `fleetconfig` into a shape nothing reads). Whether ward **shadows** logic that cli-guard already owns (e.g. a second parse/validate of something cli-guard exports) cannot be settled from ward alone. That is the ward#407-shaped question and it requires reading cli-guard from `/substrate` inside a container, which was unavailable this session. Recommended next pass: run the same `deadcode` + import-seam analysis with cli-guard on disk, focused on `fleetconfig`, `attribution`, and `config`, to find ward-side re-implementations of cli-guard-owned behavior. ### Suggested PR slicing (feeds the #265 umbrella) 1. **Cut A** - delete `agent_adapter.go` + test + doc. Self-contained leaf, lowest risk, do first. 2. **Cut C** - delete `dockerSockMount`. Independent, trivial, security win. 3. **Cut B** - Phase-4 switch removal + retire the parity contract test, under ward#401. Gate on `TestRegistryCoversEveryMode` staying green. 4. **Decision D** - drop `substrateRepo.slug`, convert the parser to an explicit embed check. 5. **Decision E** - wire-or-drop `fleetlocal.go` (own issue, needs a product call). 6. **Verify** - re-run with cli-guard mounted for the true cross-boundary (#407) shadow analysis. Every deletion above must be re-confirmed by the reviewer with `deadcode ./...` returning clean for the removed symbols and `ward test` (the full suite) green after each cut, since some dead funcs are load-bearing for their own tests and those tests delete with them. --- Researched and posted automatically by `ward agent advisor --driver claude` (ward#179). This is one-shot research, not a carried change - verify before acting on it.   — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-07-02 17:40:18 +00:00

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-206 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T17:40:16Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-206` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T17:40:16Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren commented

2026-07-02 17:47:46 +00:00

Author

Owner

⚠️ Reopened: this run's work did not land on `main`

An ephemeral ward container (claude mode) dispatched for this issue finished but its work was not merged to main, so the reaper preserved it on a branch before teardown and reopened the issue (its closes #206 never reached main). Recover from the salvage branch below.

Repo: coilyco-flight-deck/ward
Salvage branch: ward-salvage/ward-86ffb40e
Reason: merge conflict integrating onto main
Container uptime at reap: 7m (age of the baked Forgejo PAT snapshot; a long-lived container is likelier to carry a rotated token)

Reap diagnostics

--- reap diagnostics ---
ward version:      v0.319.0
version source:    pinned via WARD_VERSION/--ward-version (v0.319.0)
HEAD:              97a9801ad975
origin/main:       3228f8657c4d
ancestry:          HEAD is NOT yet on origin/main - residual work remains to land
decision gate:     provenance missing or unreadable
reason:            merge conflict integrating onto main
provenance:        missing or unreadable
run-owned landed:  no
working tree:      6 dirty path(s)
container uptime:  7m (baked Forgejo PAT age proxy)
--- end reap diagnostics ---

Recover

git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-86ffb40e
git checkout -b ward-salvage/ward-86ffb40e FETCH_HEAD

Working tree at reap time

 D cmd/ward/agent_adapter.go
 D cmd/ward/agent_adapter_test.go
 M cmd/ward/agent_signature.go
 M cmd/ward/agents_registry_contract_test.go
 M cmd/ward/container_compute.go
?? cmd/ward/fleet_test.go

— Claude (she/her), via ward agent

## ⚠️ Reopened: this run's work did not land on `main` An ephemeral `ward container` (claude mode) dispatched for this issue finished but its work was **not merged to `main`**, so the reaper preserved it on a branch before teardown and reopened the issue (its `closes #206` never reached `main`). Recover from the salvage branch below. - **Repo:** `coilyco-flight-deck/ward` - **Salvage branch:** `ward-salvage/ward-86ffb40e` - **Reason:** merge conflict integrating onto main - **Container uptime at reap:** 7m (age of the baked Forgejo PAT snapshot; a long-lived container is likelier to carry a rotated token) ## Reap diagnostics ``` --- reap diagnostics --- ward version: v0.319.0 version source: pinned via WARD_VERSION/--ward-version (v0.319.0) HEAD: 97a9801ad975 origin/main: 3228f8657c4d ancestry: HEAD is NOT yet on origin/main - residual work remains to land decision gate: provenance missing or unreadable reason: merge conflict integrating onto main provenance: missing or unreadable run-owned landed: no working tree: 6 dirty path(s) container uptime: 7m (baked Forgejo PAT age proxy) --- end reap diagnostics --- ``` ## Recover ```bash git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-86ffb40e git checkout -b ward-salvage/ward-86ffb40e FETCH_HEAD ``` ## Working tree at reap time ``` D cmd/ward/agent_adapter.go D cmd/ward/agent_adapter_test.go M cmd/ward/agent_signature.go M cmd/ward/agents_registry_contract_test.go M cmd/ward/container_compute.go ?? cmd/ward/fleet_test.go ```  — Claude (she/her), via `ward agent`

coilysiren closed this issue

2026-07-04 10:36:49 +00:00

Commenting is not possible because the repository is archived.

No milestone

No project

No assignees

2 participants

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/ward#206

No description provided.

Rows
Columns

Ward to gli guard dead code and interface analysis #206

🔎 ward agent advisor

ward#206 - dead-code + interface analysis (ward, read-only)

Method

Findings, ranked by cleanup value vs risk

Interfaces with a single implementation (considered, mostly rejected)

ward-over-cli-guard graft surface (verify step, needs cli-guard read)

Suggested PR slicing (feeds the #265 umbrella)

⚠️ Reopened: this run's work did not land on main

Reap diagnostics

Recover

Working tree at reap time

⚠️ Reopened: this run's work did not land on `main`