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

New issue

Closed

opened 2026-07-08 10:07:53 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

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

Member

Summary

infrastructure still has a small set of true runtime/script dependencies on retired coily command surfaces. Those should be cleaned up now. At the same time, this repo also contains intentional kai-server coily-retention services that must not be deleted until a successor exists.

Findings from the 2026-07-08 inbox hard-search

High-signal live script refs include:

scripts/provision-coilyco-ops-bot.sh using coily ops aws ssm get-parameter and put-parameter
scripts/grant-coilyco-ops-org-repo-create.sh using coily ops aws ssm get-parameter
scripts/coilysiren-tangled-knot-autodeploy.sh using coily pkg nix build

Intentional retained surfaces include:

systemd/coily-update.service and scripts/coily-update.sh
systemd/coily-audit-dashboard.service
docs in docs/systemd-units.md that mark these as retained because kai-server still keeps coily and coily audit has no ward successor

Scope

Headless-ready cleanup now:

replace live coily ops aws ... calls in the provisioning/grant scripts with the repo's current supported path
replace the autodeploy coily pkg nix build call with the native nix build pattern already used elsewhere in this repo
scrub stale comments/help text in these scripts if they still describe retired coily surfaces as normal

Explicitly out of scope unless a successor lands first:

deleting coily-update
deleting coily-audit-dashboard
removing docs that mark those services as intentional retention

Acceptance

No hand-authored infrastructure runtime script still depends on retired coily CLI surfaces where a current replacement already exists.
docs/systemd-units.md still clearly marks the retained services as intentional exceptions.
The retained coily services remain in place until the successor tracked in infrastructure#377 or an equivalent follow-up is actually available.

Dependency note

This lane depends on the ward compatibility-boundary issue only for final wording on what counts as an allowed legacy exception. The runtime script replacements themselves are ready now. Downstream, nothing in this issue should remove the kai-server retention path before a successor exists.

Filed by ward agent advisor cross-repo fan-out from coilysiren/inbox#156 (part 2 of 2, ward#424). Upstream dependency: coilyco-flight-deck/ward#673.

— Codex, via ward agent

## Summary `infrastructure` still has a small set of **true runtime/script dependencies** on retired `coily` command surfaces. Those should be cleaned up now. At the same time, this repo also contains **intentional kai-server coily-retention services** that must **not** be deleted until a successor exists. ## Findings from the 2026-07-08 inbox hard-search High-signal live script refs include: - `scripts/provision-coilyco-ops-bot.sh` using `coily ops aws ssm get-parameter` and `put-parameter` - `scripts/grant-coilyco-ops-org-repo-create.sh` using `coily ops aws ssm get-parameter` - `scripts/coilysiren-tangled-knot-autodeploy.sh` using `coily pkg nix build` Intentional retained surfaces include: - `systemd/coily-update.service` and `scripts/coily-update.sh` - `systemd/coily-audit-dashboard.service` - docs in `docs/systemd-units.md` that mark these as retained because kai-server still keeps coily and `coily audit` has no ward successor ## Scope Headless-ready cleanup now: - replace live `coily ops aws ...` calls in the provisioning/grant scripts with the repo's current supported path - replace the autodeploy `coily pkg nix build` call with the native `nix build` pattern already used elsewhere in this repo - scrub stale comments/help text in these scripts if they still describe retired `coily` surfaces as normal Explicitly out of scope unless a successor lands first: - deleting `coily-update` - deleting `coily-audit-dashboard` - removing docs that mark those services as intentional retention ## Acceptance - No hand-authored infrastructure runtime script still depends on retired `coily` CLI surfaces where a current replacement already exists. - `docs/systemd-units.md` still clearly marks the retained services as intentional exceptions. - The retained coily services remain in place until the successor tracked in `infrastructure#377` or an equivalent follow-up is actually available. ## Dependency note This lane depends on the `ward` compatibility-boundary issue only for final wording on what counts as an allowed legacy exception. The runtime script replacements themselves are ready now. Downstream, nothing in this issue should remove the kai-server retention path before a successor exists. --- Filed by `ward agent advisor` cross-repo fan-out from coilysiren/inbox#156 (part 2 of 2, ward#424). Upstream dependency: coilyco-flight-deck/ward#673.  — Codex, via `ward agent`

coilyco-ops added the

headless

label

2026-07-08 16:35:05 +00:00

coilyco-ops commented

2026-07-08 17:07:54 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-infrastructure-477 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T17:07:51Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

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)

Resolved: coilyco-flight-deck/infrastructure#477 · branch issue-477 · harness codex · workflow direct-main
Run: engineer-codex-infrastructure-477 · ward v0.451.0 · dispatched 2026-07-08T17:07:51Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Issue body as seeded:

## Summary

`infrastructure` still has a small set of **true runtime/script dependencies** on retired `coily` command surfaces. Those should be cleaned up now. At the same time, this repo also contains **intentional kai-server coily-retention services** that must **not** be deleted until a successor exists.

## Findings from the 2026-07-08 inbox hard-search

High-signal live script refs include:

- `scripts/provision-coilyco-ops-bot.sh` using `coily ops aws ssm get-parameter` and `put-parameter`
- `scripts/grant-coilyco-ops-org-repo-create.sh` using `coily ops aws ssm get-parameter`
- `scripts/coilysiren-tangled-knot-autodeploy.sh` using `coily pkg nix build`

Intentional retained surfaces include:

- `systemd/coily-update.service` and `scripts/coily-update.sh`
- `systemd/coily-audit-dashboard.service`
- docs in `docs/systemd-units.md` that mark these as retained because kai-server still keeps coily and `coily audit` has no ward successor

## Scope

Headless-ready cleanup now:

- replace live `coily ops aws ...` calls in the provisioning/grant scripts with the repo's current supported path
- replace the autodeploy `coily pkg nix build` call with the native `nix build` pattern already used elsewhere in this repo
- scrub stale comments/help text in these scripts if they still describe retired `coily` surfaces as normal

Explicitly out of scope unless a successor lands first:

- deleting `coily-update`
- deleting `coily-audit-dashboard`
- removing docs that mark those services as intentional retention

## Acceptance

- No hand-authored infrastructure runtime script still depends on retired `coily` CLI surfaces where a current replacement already exists.
- `docs/systemd-units.md` still clearly marks the retained services as intentional exceptions.
- The retained coily services remain in place until the successor tracked in `infrastructure#377` or an equivalent follow-up is actually available.

## Dependency note

This lane depends on the `ward` compatibility-boundary is

… (truncated to 2000 chars; full body is on this issue)

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.451.0).

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-infrastructure-477` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T17:07:51Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **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). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/infrastructure#477` · branch `issue-477` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-infrastructure-477` · ward `v0.451.0` · dispatched `2026-07-08T17:07:51Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). **Issue body as seeded:** ``` ## Summary `infrastructure` still has a small set of **true runtime/script dependencies** on retired `coily` command surfaces. Those should be cleaned up now. At the same time, this repo also contains **intentional kai-server coily-retention services** that must **not** be deleted until a successor exists. ## Findings from the 2026-07-08 inbox hard-search High-signal live script refs include: - `scripts/provision-coilyco-ops-bot.sh` using `coily ops aws ssm get-parameter` and `put-parameter` - `scripts/grant-coilyco-ops-org-repo-create.sh` using `coily ops aws ssm get-parameter` - `scripts/coilysiren-tangled-knot-autodeploy.sh` using `coily pkg nix build` Intentional retained surfaces include: - `systemd/coily-update.service` and `scripts/coily-update.sh` - `systemd/coily-audit-dashboard.service` - docs in `docs/systemd-units.md` that mark these as retained because kai-server still keeps coily and `coily audit` has no ward successor ## Scope Headless-ready cleanup now: - replace live `coily ops aws ...` calls in the provisioning/grant scripts with the repo's current supported path - replace the autodeploy `coily pkg nix build` call with the native `nix build` pattern already used elsewhere in this repo - scrub stale comments/help text in these scripts if they still describe retired `coily` surfaces as normal Explicitly out of scope unless a successor lands first: - deleting `coily-update` - deleting `coily-audit-dashboard` - removing docs that mark those services as intentional retention ## Acceptance - No hand-authored infrastructure runtime script still depends on retired `coily` CLI surfaces where a current replacement already exists. - `docs/systemd-units.md` still clearly marks the retained services as intentional exceptions. - The retained coily services remain in place until the successor tracked in `infrastructure#377` or an equivalent follow-up is actually available. ## Dependency note This lane depends on the `ward` compatibility-boundary is ``` … (truncated to 2000 chars; full body is on this issue) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.451.0). </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-08 17:12:58 +00:00

fix: use ward ops for coily install ssm checks

coilyco-ops closed this issue

2026-07-08 17:12:58 +00:00

coilyco-ops commented

2026-07-08 17:14:45 +00:00

Author

Member

WARD-OUTCOME: done - retired the last live coily AWS wrapper call in coily-install.sh.
The change was straightforward, but the repo's comment hook fought the first draft harder than the code did. I am confident in the result, and the only rough edge is that the adversarial panel could not run here.
PR-BODY-NOTE: ADVISORY-ONLY REVIEW: no heterogeneous reviewer family was available besides the worker (codex), so the adversarial panel could not run and did NOT gate this diff. Dropped: opencode (unavailable: opencode not on PATH); codex (worker's own family - never reviews its own diff). A human should review this change with the extra scrutiny an unrun panel would have applied.

WARD-OUTCOME: done - retired the last live coily AWS wrapper call in coily-install.sh. The change was straightforward, but the repo's comment hook fought the first draft harder than the code did. I am confident in the result, and the only rough edge is that the adversarial panel could not run here. PR-BODY-NOTE: ADVISORY-ONLY REVIEW: no heterogeneous reviewer family was available besides the worker (codex), so the adversarial panel could not run and did NOT gate this diff. Dropped: opencode (unavailable: opencode not on PATH); codex (worker's own family - never reviews its own diff). A human should review this change with the extra scrutiny an unrun panel would have applied.