coilyco-flight-deck/ward

Watch

Retire the catalog.dependsOn substrate auto-mount so repos can drop .ward/ward.yaml #1660

New issue

Open

opened 2026-08-14 02:21:34 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-08-14 02:21:34 +00:00

Member

Follow-on from coilysiren/inbox#365, which rules that .ward/ward.yaml is deleted from repos entirely. just takes over commands:, and every other key is deleted or relocated.

catalog.dependsOn is ruled delete, but unlike the other keys it is live and consumed by ward, so the deletion is a ward feature retirement rather than a config move.

What reads it today

cmd/ward/agent.go - seeds external (non-Forgejo) catalog.dependsOn mirrors host-side before the sealed container clones from the warm gitcache (ward#612).
cmd/ward/agent_context.go - carries the role-neutral read-only catalog.dependsOn context grant.
docs/ward-yaml.md - documents it as "a list of repository refs and supplies read-only context repositories".

Who declares it

Non-empty in at least two repos:

coilyco-bridge/deploy - five entries: eco-app, factory-game-v3, galaxy-gen, website, agent-proxy.
coilyco-flight-deck/ward - one entry: cli-guard.

Empty ([]) in agentic-os and infrastructure. I have not swept every repo, so treat those two as a floor rather than the full set.

What retirement means

Agents launched against deploy lose five repositories of mounted read-only context, and ward loses cli-guard. If that context is still wanted, it needs a replacement source that is not a per-repo file, since the whole point of inbox#365 is that repos stop carrying ward config.

Options worth weighing:

Move the mapping operator-side into ~/.ward/config.yaml, keeping the feature and dropping the repo dependency.
Derive context repos from the catalog graph rather than a hand-declared list.
Retire the feature outright and let agents clone what they need.

Also blocked on this

agentic_os/pre_commit/check_catalog_block.py in agentic-os exists solely to enforce that dependsOn is present and a list. It gets retired alongside this.

Decision record: coilysiren/inbox#365
just spike: coilyco-flight-deck/agentic-os#1048

Follow-on from coilysiren/inbox#365, which rules that `.ward/ward.yaml` is deleted from repos entirely. `just` takes over `commands:`, and every other key is deleted or relocated. `catalog.dependsOn` is ruled **delete**, but unlike the other keys it is live and consumed by ward, so the deletion is a ward feature retirement rather than a config move. ## What reads it today * `cmd/ward/agent.go` - seeds external (non-Forgejo) `catalog.dependsOn` mirrors host-side before the sealed container clones from the warm gitcache (ward#612). * `cmd/ward/agent_context.go` - carries the role-neutral read-only `catalog.dependsOn` context grant. * `docs/ward-yaml.md` - documents it as "a list of repository refs and supplies read-only context repositories". ## Who declares it Non-empty in at least two repos: * `coilyco-bridge/deploy` - five entries: eco-app, factory-game-v3, galaxy-gen, website, agent-proxy. * `coilyco-flight-deck/ward` - one entry: cli-guard. Empty (`[]`) in agentic-os and infrastructure. I have not swept every repo, so treat those two as a floor rather than the full set. ## What retirement means Agents launched against deploy lose five repositories of mounted read-only context, and ward loses cli-guard. If that context is still wanted, it needs a replacement source that is not a per-repo file, since the whole point of inbox#365 is that repos stop carrying ward config. Options worth weighing: * Move the mapping operator-side into `~/.ward/config.yaml`, keeping the feature and dropping the repo dependency. * Derive context repos from the catalog graph rather than a hand-declared list. * Retire the feature outright and let agents clone what they need. ## Also blocked on this `agentic_os/pre_commit/check_catalog_block.py` in agentic-os exists solely to enforce that `dependsOn` is present and a list. It gets retired alongside this. ## Related * Decision record: coilysiren/inbox#365 * `just` spike: coilyco-flight-deck/agentic-os#1048

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

2026-08-14 02:24:15 +00:00

chore(ward): drop dead ward.yaml keys #818

coilyco-ops commented

2026-08-16 06:28:52 +00:00

Author

Member

The full sweep you asked for. Lucia (AI Engineer seat), 2026-08-15.

I have not swept every repo, so treat those two as a floor rather than the full set.

All 33 repos across the four owners, read from HEAD of each rather than from a catalog snapshot. Twelve declare a non-empty catalog.dependsOn, not two.

Non-empty: these lose mounted read-only context

coilyco-bridge/agentic-os-kai       ward, agentic-os-hardware
coilyco-bridge/deploy               eco-app, factory-game-v3, galaxy-gen, website, agent-proxy
coilyco-flight-deck/agent-compose   agentic-os, ward
coilyco-flight-deck/homebrew-tap    ward
coilyco-flight-deck/ward            umbra
coilyco-gaming/eco-app              Eco
coilyco-gaming/eco-mods             Eco
coilyco-gaming/eco-ops              Eco
coilyco-gaming/galaxy-gen           deploy
coilyco-gaming/sirens-echo          infrastructure
coilysiren/voice-corpus             lore
coilysiren/website                  infrastructure

deploy and ward match this issue exactly. ward resolves to umbra, not cli-guard — presumably renamed since filing, worth confirming rather than assuming.

The shape of the loss, which is not uniform

Three distinct kinds, and they should not retire the same way:

Three Eco repos mount StrangeLoopGames/Eco, the only external non-Forgejo entry in the fleet. That is the path agent_context_seed.go mirrors host-side before the sealed container clones, so it is the one that exercises the external-seed code rather than the plain Forgejo grant. It is also game source an agent genuinely cannot reconstruct.
Five repos mount infrastructure-ish context (ward, infrastructure, agentic-os, agentic-os-hardware, deploy, lore). This is the class inbox#182 and #229 already argued against: "Ward User Alice should not have ward in their substrate." Three of these mount ward itself.
deploy mounts five product repos, which is the largest single loss and the one worth a replacement source rather than deletion.

So the Eco case and the ward-in-substrate case point opposite directions. Retiring the feature outright serves #182 and #229 and costs the Eco repos something real.

Also present, and the block hook will reject them today

Six repos ship .ward/ward.yaml with no dependsOn key at all:

coilyco-bridge/.github          coilyco-flight-deck/.github
coilyco-flight-deck/mcp-beaver  coilyco-gaming/.github
coilyco-gaming/factorio-mods    coilysiren/inbox

check_catalog_block requires the key and says "Missing is not" fine. These pass only because the hook is not wired in them. When check_catalog_block retires alongside this, that latent inconsistency retires with it rather than needing six commits.

coilyco-flight-deck/umbra has no .ward/ward.yaml at all, so exactly one repo is already where inbox#365 wants everything.

Method, and one correction

Cloned each repo shallow and read HEAD:.ward/ward.yaml through git's credential helper.

My first pass used the raw HTTP API with an empty token, so every private repo returned 404 and I recorded it as "no file" — including deploy, which this issue already documents as having five entries. That contradiction is what caught it. The numbers above are the corrected run, and deploy now matches its local checkout exactly.

**The full sweep you asked for. Lucia (AI Engineer seat), 2026-08-15.** > I have not swept every repo, so treat those two as a floor rather than the full set. All 33 repos across the four owners, read from `HEAD` of each rather than from a catalog snapshot. **Twelve declare a non-empty `catalog.dependsOn`, not two.** ## Non-empty: these lose mounted read-only context ``` coilyco-bridge/agentic-os-kai ward, agentic-os-hardware coilyco-bridge/deploy eco-app, factory-game-v3, galaxy-gen, website, agent-proxy coilyco-flight-deck/agent-compose agentic-os, ward coilyco-flight-deck/homebrew-tap ward coilyco-flight-deck/ward umbra coilyco-gaming/eco-app Eco coilyco-gaming/eco-mods Eco coilyco-gaming/eco-ops Eco coilyco-gaming/galaxy-gen deploy coilyco-gaming/sirens-echo infrastructure coilysiren/voice-corpus lore coilysiren/website infrastructure ``` `deploy` and `ward` match this issue exactly. **`ward` resolves to `umbra`, not `cli-guard`** — presumably renamed since filing, worth confirming rather than assuming. ## The shape of the loss, which is not uniform Three distinct kinds, and they should not retire the same way: * **Three Eco repos mount `StrangeLoopGames/Eco`**, the only external non-Forgejo entry in the fleet. That is the path `agent_context_seed.go` mirrors host-side before the sealed container clones, so it is the one that exercises the external-seed code rather than the plain Forgejo grant. It is also game source an agent genuinely cannot reconstruct. * **Five repos mount infrastructure-ish context** (`ward`, `infrastructure`, `agentic-os`, `agentic-os-hardware`, `deploy`, `lore`). This is the class inbox#182 and #229 already argued against: *"Ward User Alice should not have ward in their substrate."* Three of these mount `ward` itself. * **`deploy` mounts five product repos**, which is the largest single loss and the one worth a replacement source rather than deletion. **So the Eco case and the ward-in-substrate case point opposite directions.** Retiring the feature outright serves #182 and #229 and costs the Eco repos something real. ## Also present, and the block hook will reject them today Six repos ship `.ward/ward.yaml` with **no `dependsOn` key at all**: ``` coilyco-bridge/.github coilyco-flight-deck/.github coilyco-flight-deck/mcp-beaver coilyco-gaming/.github coilyco-gaming/factorio-mods coilysiren/inbox ``` `check_catalog_block` requires the key and says *"Missing is not"* fine. These pass only because the hook is not wired in them. **When `check_catalog_block` retires alongside this, that latent inconsistency retires with it** rather than needing six commits. `coilyco-flight-deck/umbra` has no `.ward/ward.yaml` at all, so exactly one repo is already where inbox#365 wants everything. ## Method, and one correction Cloned each repo shallow and read `HEAD:.ward/ward.yaml` through git's credential helper. My first pass used the raw HTTP API with an empty token, so every **private** repo returned 404 and I recorded it as "no file" — including `deploy`, which this issue already documents as having five entries. That contradiction is what caught it. The numbers above are the corrected run, and `deploy` now matches its local checkout exactly.

coilyco-ops commented

2026-08-16 06:57:36 +00:00

Author

Member

The downstream half is filed: coilyco-flight-deck/agentic-os #1101. Lucia (AI Engineer seat), 2026-08-15.

This issue notes that check_catalog_block retires alongside it. catalog-trifecta does not, because it is a documentation cross-link rule rather than a catalog-block rule, and it requires .ward/ward.yaml as an existence-only fourth member plus a resolving link from README, AGENTS, and FEATURES.

So deleting the file produces four violations per repo, not one: the missing-file check, plus three dead links.

One repo is already living it. coilyco-flight-deck/umbra has no .ward/ward.yaml and is the only repo in the fleet already in this issue's target state. It wires both hooks with no opt-out in its pyproject.toml, and its pinned v0.65.0 already carried both requirements. It is red today, not at the next rev bump.

That makes umbra a free preview of what the other 32 repos hit when this lands, and worth watching rather than fixing in isolation.

Sequencing on #1101 is explicitly behind this issue: while ward still reads catalog.dependsOn at launch the file has to exist, so relaxing the hook first would let a repo delete something ward still needs.

**The downstream half is filed: `coilyco-flight-deck/agentic-os` #1101.** Lucia (AI Engineer seat), 2026-08-15. This issue notes that `check_catalog_block` retires alongside it. **`catalog-trifecta` does not**, because it is a documentation cross-link rule rather than a catalog-block rule, and it requires `.ward/ward.yaml` as an existence-only fourth member plus a resolving link from README, AGENTS, and FEATURES. So deleting the file produces **four violations per repo**, not one: the missing-file check, plus three dead links. **One repo is already living it.** `coilyco-flight-deck/umbra` has no `.ward/ward.yaml` and is the only repo in the fleet already in this issue's target state. It wires both hooks with no opt-out in its `pyproject.toml`, and its pinned `v0.65.0` already carried both requirements. **It is red today**, not at the next rev bump. That makes umbra a free preview of what the other 32 repos hit when this lands, and worth watching rather than fixing in isolation. Sequencing on #1101 is explicitly behind this issue: while ward still reads `catalog.dependsOn` at launch the file has to exist, so relaxing the hook first would let a repo delete something ward still needs.

No milestone

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/ward#1660

No description provided.

Rows
Columns