clarify surviving coily compatibility surfaces after the coily -> ward retirement #673

New issue

Closed

opened 2026-07-08 10:07:52 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-07-08 10:07:52 +00:00

Member

Summary

The inbox-wide coily retirement sweep needs one canonical lane in ward that says what is still intentionally supported as legacy compatibility versus what is stale guidance that should be scrubbed.

This repo is mostly not carrying a runtime dependency on retired coily surfaces. The main work is to fix docs, comments, and recovery hints that still present coily as current, while preserving the intentional migration bridge where ward still honors legacy .coily/coily.yaml repos.

Why this lane exists

The 2026-07-08 inbox hard-search found three different categories mixed together:

true runtime dependencies on retired coily commands
cold-agent docs/help text that still teach coily
intentional compatibility surfaces such as .coily/coily.yaml fallback

ward owns the compatibility boundary. Downstream cleanup in agentic-os-kai and infrastructure can proceed in parallel on obvious replacements, but they should treat this issue's outcome as the canonical rule for what remains allowed as legacy.

Scope

Audit and update cold-agent-facing copy such as:

docs/ward-kdl-surface.md
cmd/ward/pkg.go
cmd/ward/pkg_brew.go
cmd/ward/hook.go recovery hints
any similar hand-authored docs/help text that still frames coily as the normal path

Keep, but label clearly as legacy compatibility if still intended:

.coily/coily.yaml discovery fallback in cmd/ward/repocfg.go
docs like docs/config-discovery.md, docs/ward-yaml.md, docs/doctor.md that describe the fallback
tests that intentionally exercise the fallback

Acceptance

ward docs/help text no longer teaches retired coily surfaces as the preferred current path.
Any surviving .coily/coily.yaml support is explicitly framed as legacy compatibility or migration support.
No behavior change removes compatibility fallback unless that removal is separately approved.

Dependency note

This is the upstream clarity lane for the broader retirement sweep. agentic-os-kai and infrastructure are downstream consumers of the rule here, not blockers for it.

Filed by ward agent advisor cross-repo fan-out from coilysiren/inbox#156 (part 1 of 2, ward#424).

— Codex, via ward agent

## Summary The inbox-wide `coily` retirement sweep needs one canonical lane in `ward` that says what is still intentionally supported as **legacy compatibility** versus what is stale guidance that should be scrubbed. This repo is mostly not carrying a runtime dependency on retired `coily` surfaces. The main work is to fix docs, comments, and recovery hints that still present `coily` as current, while **preserving** the intentional migration bridge where `ward` still honors legacy `.coily/coily.yaml` repos. ## Why this lane exists The 2026-07-08 inbox hard-search found three different categories mixed together: - true runtime dependencies on retired `coily` commands - cold-agent docs/help text that still teach `coily` - intentional compatibility surfaces such as `.coily/coily.yaml` fallback `ward` owns the compatibility boundary. Downstream cleanup in `agentic-os-kai` and `infrastructure` can proceed in parallel on obvious replacements, but they should treat this issue's outcome as the canonical rule for what remains allowed as legacy. ## Scope Audit and update cold-agent-facing copy such as: - `docs/ward-kdl-surface.md` - `cmd/ward/pkg.go` - `cmd/ward/pkg_brew.go` - `cmd/ward/hook.go` recovery hints - any similar hand-authored docs/help text that still frames `coily` as the normal path Keep, but label clearly as legacy compatibility if still intended: - `.coily/coily.yaml` discovery fallback in `cmd/ward/repocfg.go` - docs like `docs/config-discovery.md`, `docs/ward-yaml.md`, `docs/doctor.md` that describe the fallback - tests that intentionally exercise the fallback ## Acceptance - `ward` docs/help text no longer teaches retired `coily` surfaces as the preferred current path. - Any surviving `.coily/coily.yaml` support is explicitly framed as legacy compatibility or migration support. - No behavior change removes compatibility fallback unless that removal is separately approved. ## Dependency note This is the upstream clarity lane for the broader retirement sweep. `agentic-os-kai` and `infrastructure` are downstream consumers of the rule here, not blockers for it. --- Filed by `ward agent advisor` cross-repo fan-out from coilysiren/inbox#156 (part 1 of 2, ward#424).  — Codex, via `ward agent`

coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure

2026-07-08 10:07:53 +00:00

retire live coily CLI refs from infrastructure scripts while preserving intentional kai-server coily-retention services #477