Delete aos-eval/ and its nine reference sites, once sirens-echo has moved to housecast grade #1374

Closed
opened 2026-08-29 02:43:56 +00:00 by coilyco-ops · 1 comment
Owner

Step 5 of five, and the last. Blocked on coilyco-gaming/sirens-echo#1166. Deleting before that lands stops a deployed bot's grading workflow.

housecast was always supposed to end aos-eval and had not. housecast-v0.2.0 now carries the grading half entire, so the package here is a duplicate waiting on one consumer.

Blocked, not ready

  • coilyco-gaming/sirens-echo calls the aos-eval CLI from its justfile and keeps eval/aos-eval-profile.yaml. Tracked in #1166.
  • housecast no longer depends on it. housecast-v0.2.0 dropped the pin and the [tool.uv.sources] entry.

When sirens-echo reports done, this is a delete with no consumer left.

What to delete

aos-eval/ entire, plus nine reference sites outside it:

  • .agents/skills/tooling-aos-eval/SKILL.md - the skill teaching the old command
  • .forgejo/workflows/aos-eval-release.yml - the whole release train, tag_prefix: aos-eval-v
  • .forgejo/workflows/ci.yml and promote.yml - the aos-eval-tests jobs
  • docs/aos-eval.md, docs/FEATURES.md, docs/release.md
  • justfile, pyproject.toml

Two things that must survive the delete

The aos-eval-v* tags stay. They are what existing pins resolve against, and deleting a tag breaks a checkout that pins it rather than merely aging it. The train stops cutting new ones; the old ones are history.

Schema ids keep the aos-eval. prefix in housecast. aos-eval.board.v1 and friends name a wire format that committed evidence carries, not this package. That prefix outliving the directory is correct rather than an oversight, and docs/grading.md in housecast records why.

A trap to fix or delete along the way

#1373: aos-eval/build/ is not ignored, so running its test suite makes 1,577 lines of generated output committable, which is exactly how it reached #1370. If the directory goes, that issue goes with it.

Suggested acceptance

  • sirens-echo#1166 closed.
  • aos-eval/ gone, and no reference to it in a workflow, skill, doc, justfile, or pyproject.
  • aos-eval-v* tags still resolve.
  • docs/release.md records the retirement rather than pretending the train never existed.

Filed by Evie, science seat, session ad84.

Step 5 of five, and the last. **Blocked on `coilyco-gaming/sirens-echo#1166`.** Deleting before that lands stops a deployed bot's grading workflow. housecast was always supposed to end aos-eval and had not. `housecast-v0.2.0` now carries the grading half entire, so the package here is a duplicate waiting on one consumer. ## Blocked, not ready * `coilyco-gaming/sirens-echo` calls the `aos-eval` CLI from its justfile and keeps `eval/aos-eval-profile.yaml`. Tracked in `#1166`. * housecast no longer depends on it. `housecast-v0.2.0` dropped the pin and the `[tool.uv.sources]` entry. When sirens-echo reports done, this is a delete with no consumer left. ## What to delete `aos-eval/` entire, plus nine reference sites outside it: * `.agents/skills/tooling-aos-eval/SKILL.md` - the skill teaching the old command * `.forgejo/workflows/aos-eval-release.yml` - the whole release train, `tag_prefix: aos-eval-v` * `.forgejo/workflows/ci.yml` and `promote.yml` - the `aos-eval-tests` jobs * `docs/aos-eval.md`, `docs/FEATURES.md`, `docs/release.md` * `justfile`, `pyproject.toml` ## Two things that must survive the delete **The `aos-eval-v*` tags stay.** They are what existing pins resolve against, and deleting a tag breaks a checkout that pins it rather than merely aging it. The train stops cutting new ones; the old ones are history. **Schema ids keep the `aos-eval.` prefix in housecast.** `aos-eval.board.v1` and friends name a wire format that committed evidence carries, not this package. That prefix outliving the directory is correct rather than an oversight, and `docs/grading.md` in housecast records why. ## A trap to fix or delete along the way `#1373`: `aos-eval/build/` is not ignored, so running its test suite makes 1,577 lines of generated output committable, which is exactly how it reached `#1370`. If the directory goes, that issue goes with it. ## Suggested acceptance - [ ] `sirens-echo#1166` closed. - [ ] `aos-eval/` gone, and no reference to it in a workflow, skill, doc, justfile, or pyproject. - [ ] `aos-eval-v*` tags still resolve. - [ ] `docs/release.md` records the retirement rather than pretending the train never existed. Filed by Evie, science seat, session `ad84`.
Author
Owner

Decided by Kai, 2026-08-29: delete regardless. The gate in the title, "once sirens-echo has moved to housecast grade", is lifted.

I offered this option with the caveat attached, that it is only right if the consumer has already stopped importing aos-eval, and that otherwise it breaks their grading path from the outside. She chose it with that caveat visible, so it is a decision rather than an oversight and I am proceeding.

How I will execute it

Two things follow from the caveat rather than from the decision, and neither changes the outcome:

  1. Check first, then delete either way. I will read sirens-echo#1166 and grep that repo for live imports of aos_eval before cutting. Not to re-litigate the gate, but so the deletion commit states plainly whether it broke a live consumer or a dead reference. Those are different facts and the next reader deserves the right one.
  2. Notify the consumer in the same turn. If sirens-echo still imports it, deleting from here is externally-visible breakage of a peer repo, so it gets a comment on #1166 naming what went and when, rather than being discovered by a failing grading run.

Consequences inside this repo

  • #1373 gitignores aos-eval/build/, which stops mattering once the directory is gone. It stays in the lane only as a no-op check that the deletion actually removed it. If the deletion lands first, close #1373 as moot rather than doing it.
  • #1118 is the crossed-ownership seam between aos-eval and agent-compose. Kai sequenced it behind this issue, on the reasoning that positioning a boundary inside a package scheduled for deletion is work that evaporates. So #1118 waits for this to land and is then re-read rather than answered now.
  • Nine reference sites go with the package. They are the part most likely to be missed, so the done-condition is a clean grep for aos-eval and aos_eval across the repo, not just the directory being gone.

Not established

Whether sirens-echo has actually moved. I have not read #1166, which is precisely why the first step above exists. The decision does not depend on the answer; the accuracy of the commit message does.

**Decided by Kai, 2026-08-29: delete regardless.** The gate in the title, "once sirens-echo has moved to housecast grade", is lifted. I offered this option with the caveat attached, that it is only right if the consumer has already stopped importing `aos-eval`, and that otherwise it breaks their grading path from the outside. She chose it with that caveat visible, so it is a decision rather than an oversight and I am proceeding. ## How I will execute it Two things follow from the caveat rather than from the decision, and neither changes the outcome: 1. **Check first, then delete either way.** I will read `sirens-echo#1166` and grep that repo for live imports of `aos_eval` before cutting. Not to re-litigate the gate, but so the deletion commit states plainly whether it broke a live consumer or a dead reference. Those are different facts and the next reader deserves the right one. 2. **Notify the consumer in the same turn.** If sirens-echo still imports it, deleting from here is externally-visible breakage of a peer repo, so it gets a comment on `#1166` naming what went and when, rather than being discovered by a failing grading run. ## Consequences inside this repo * **`#1373`** gitignores `aos-eval/build/`, which stops mattering once the directory is gone. It stays in the lane only as a no-op check that the deletion actually removed it. If the deletion lands first, close `#1373` as moot rather than doing it. * **`#1118`** is the crossed-ownership seam between `aos-eval` and `agent-compose`. Kai sequenced it behind this issue, on the reasoning that positioning a boundary inside a package scheduled for deletion is work that evaporates. So `#1118` waits for this to land and is then re-read rather than answered now. * Nine reference sites go with the package. They are the part most likely to be missed, so the done-condition is a clean grep for `aos-eval` and `aos_eval` across the repo, not just the directory being gone. ## Not established Whether `sirens-echo` has actually moved. I have not read `#1166`, which is precisely why the first step above exists. The decision does not depend on the answer; the accuracy of the commit message does.
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
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/agentic-os#1374
No description provided.