Freeze Ward as a contract: cut its runtime from AOS CI and the dev-base image

coilyco-ops commented

2026-08-27 03:25:13 +00:00

Owner

Decision

Kai settled this on 2026-08-24: Ward is frozen as a contract. Its runtime comes out of the hot paths, the .ward/ward.yaml schema stays, and the ward: AGENTS.md lane vocabulary stays exactly as it is.

Evidence behind it

Ward's dispatch record ends 2026-06-18. Nothing in July or August. All three .dispatch-worktrees entries are empty directories.
Ward's repo took 150 commits in 30 days and then went quiet on 2026-08-17.
That final commit moved Ward's own dev verbs off ward exec onto a justfile (coilysiren/inbox#366). The repo stopped dogfooding the feature it ships.
Meanwhile agent-compose took 50 commits in 7 days, mcp-beaver 22, umbra 13.

The risk this closes

Ward is unmaintained and still sits in the dev-base image verification path. When a toolchain bump eventually breaks its install, the failure surfaces as a broken image build, everything downstream stops, and it reads as an image problem rather than a Ward problem.

Scope

Remove the Ward runtime from these call sites in agentic-os:

.forgejo/workflows/ci.yml:64-73 - the ward-doctor job and its scripts/install-workflow-ward.sh step.
.forgejo/workflows/ci.yml:91-92 - the second install-workflow-ward.sh repo-gate step.
.forgejo/workflows/promote.yml:38-39 and :58-59 - the same two on the promote path.
docker/dev-base/verify-common.sh:53-54 - ward --version and ward doctor.
docker/dev-base/install-common.sh:193-195 - .ward/audit provisioning, only if nothing else reads that path.

Update AGENTS.md, README.md, and docs/FEATURES.md in the same commit so the trifecta stays true.

Non-goals

Do not rename the ward: frontmatter key. It is in daily use across every repo, it is read by composition rather than by any Ward process, and renaming it is a fleet-wide ansible rollout for cosmetic gain.
Do not archive the ward repo. Freeze is not delete, and the schema still has a consumer.
Do not delete .ward/ward.yaml. It carries catalog metadata.
Do not migrate the lane vocabulary to agent-compose in this change. That is a separate call if it ever becomes worth making.

Acceptance criteria

A dev-base image builds and publishes with no Ward binary present in the verify path.
ci.yml and promote.yml pass with no Ward install step.
.ward/ward.yaml is untouched and the ward: frontmatter key still resolves lanes for every repo that declares one.
Trifecta validators pass, and docs/FEATURES.md reflects the removed capability.

Revisit condition

Reopen the posture if Ward's dispatch path gets a real consumer again, meaning an actual unattended run landing work, not a plan to have one. Absent that, Ward stays frozen.

Lore is already updated: lore-stack-agent-systems and lore-project-portfolio record the freeze and the three-layer core.

## Decision Kai settled this on 2026-08-24: **Ward is frozen as a contract.** Its runtime comes out of the hot paths, the `.ward/ward.yaml` schema stays, and the `ward:` AGENTS.md lane vocabulary stays exactly as it is. ## Evidence behind it * Ward's dispatch record ends **2026-06-18**. Nothing in July or August. All three `.dispatch-worktrees` entries are empty directories. * Ward's repo took 150 commits in 30 days and then went quiet on **2026-08-17**. * That final commit moved Ward's own dev verbs off `ward exec` onto a justfile (`coilysiren/inbox#366`). The repo stopped dogfooding the feature it ships. * Meanwhile agent-compose took 50 commits in 7 days, mcp-beaver 22, umbra 13. ## The risk this closes Ward is unmaintained and still sits in the dev-base image verification path. When a toolchain bump eventually breaks its install, the failure surfaces as a broken image build, everything downstream stops, and it reads as an image problem rather than a Ward problem. ## Scope Remove the Ward runtime from these call sites in `agentic-os`: * `.forgejo/workflows/ci.yml:64-73` - the `ward-doctor` job and its `scripts/install-workflow-ward.sh` step. * `.forgejo/workflows/ci.yml:91-92` - the second `install-workflow-ward.sh` repo-gate step. * `.forgejo/workflows/promote.yml:38-39` and `:58-59` - the same two on the promote path. * `docker/dev-base/verify-common.sh:53-54` - `ward --version` and `ward doctor`. * `docker/dev-base/install-common.sh:193-195` - `.ward/audit` provisioning, only if nothing else reads that path. Update `AGENTS.md`, `README.md`, and `docs/FEATURES.md` in the same commit so the trifecta stays true. ## Non-goals * **Do not rename the `ward:` frontmatter key.** It is in daily use across every repo, it is read by composition rather than by any Ward process, and renaming it is a fleet-wide ansible rollout for cosmetic gain. * **Do not archive the ward repo.** Freeze is not delete, and the schema still has a consumer. * **Do not delete `.ward/ward.yaml`.** It carries catalog metadata. * Do not migrate the lane vocabulary to agent-compose in this change. That is a separate call if it ever becomes worth making. ## Acceptance criteria 1. A dev-base image builds and publishes with no Ward binary present in the verify path. 2. `ci.yml` and `promote.yml` pass with no Ward install step. 3. `.ward/ward.yaml` is untouched and the `ward:` frontmatter key still resolves lanes for every repo that declares one. 4. Trifecta validators pass, and `docs/FEATURES.md` reflects the removed capability. ## Revisit condition Reopen the posture if Ward's dispatch path gets a real consumer again, meaning an actual unattended run landing work, not a plan to have one. Absent that, Ward stays frozen. Lore is already updated: `lore-stack-agent-systems` and `lore-project-portfolio` record the freeze and the three-layer core.

coilyco-ops referenced this issue from a commit

2026-08-27 10:11:22 +00:00

fix(skills): Ward is frozen as a contract, not archived

coilyco-ops referenced this issue

2026-08-27 10:11:45 +00:00

feat(skills): add tooling-agent-orchestration carrying Ward and o2r patterns #1326

coilysiren referenced this issue from a commit

2026-08-27 10:14:43 +00:00

feat(skills): add tooling-agent-orchestration carrying Ward and o2r patterns (#1326)

coilyco-ops commented

2026-08-27 10:15:13 +00:00

Author

Owner

Superseded on one point: Ward is being archived after all

Kai's call on 2026-08-27, in session: archive supersedes the freeze posture in this issue. Recording it here rather than in a transcript, because this issue is where the posture lives and its non-goals currently say the opposite.

What changes. The non-goal "do not archive the ward repo" no longer holds. Ward is archived this week. The stated reasoning behind that non-goal, that the schema still has a consumer, is true and is not an argument against archiving, which is the part worth writing down rather than leaving to be rediscovered.

What does not change, and this is the load-bearing half. Archiving the ward repository does not reach any of the following, because none of them is read by a Ward process:

.ward/ward.yaml in every repository. It carries catalog metadata, and check_catalog_block upstream pins that exact path.
The ward: AGENTS.md frontmatter key. Composition reads it to select a landing lane, and it is in daily use across the fleet.
The four lane slugs themselves: merge-remote-main, pull-request, pull-request-and-merge, remote-branch-only. They are vocabulary rather than a runtime.

So the other three non-goals in this issue survive the supersession intact, and the scope section is unaffected. The five call sites still need cutting, and cutting them is still what has to happen first.

Sequencing this implies

Cut the runtime from the five call sites named in this issue. Unchanged.
Confirm nothing reads the ward binary on any hot path, which is acceptance criterion 1 and 2 as already written.
Archive the repository.

Archiving before step 1 lands would make a red image build harder to fix rather than easier, since the repository goes read-only. Worth stating the order explicitly.

One open question this creates

The .ward/ward.yaml schema's canonical documentation lives in the repository being archived, which means the schema stays in force while its definition becomes read-only. That is survivable and it is a real seam. Whether the schema's documentation should move somewhere still-writable before the archive is a separate call, and I am not making it here.

The orchestration patterns Ward formalized are inventoried in #1325, landing on PR #1326, so what it taught outlives the repository regardless of which posture this issue ends on.

## Superseded on one point: Ward is being archived after all Kai's call on 2026-08-27, in session: **archive supersedes the freeze posture in this issue.** Recording it here rather than in a transcript, because this issue is where the posture lives and its non-goals currently say the opposite. **What changes.** The non-goal "do not archive the ward repo" no longer holds. Ward is archived this week. The stated reasoning behind that non-goal, that the schema still has a consumer, is true and is not an argument against archiving, which is the part worth writing down rather than leaving to be rediscovered. **What does not change, and this is the load-bearing half.** Archiving the ward repository does not reach any of the following, because none of them is read by a Ward process: * `.ward/ward.yaml` in every repository. It carries catalog metadata, and `check_catalog_block` upstream pins that exact path. * The `ward:` AGENTS.md frontmatter key. Composition reads it to select a landing lane, and it is in daily use across the fleet. * The four lane slugs themselves: `merge-remote-main`, `pull-request`, `pull-request-and-merge`, `remote-branch-only`. They are vocabulary rather than a runtime. So the other three non-goals in this issue survive the supersession intact, and the scope section is unaffected. The five call sites still need cutting, and cutting them is still what has to happen first. ## Sequencing this implies 1. Cut the runtime from the five call sites named in this issue. Unchanged. 2. Confirm nothing reads the ward binary on any hot path, which is acceptance criterion 1 and 2 as already written. 3. Archive the repository. Archiving before step 1 lands would make a red image build harder to fix rather than easier, since the repository goes read-only. Worth stating the order explicitly. ## One open question this creates The `.ward/ward.yaml` schema's canonical documentation lives in the repository being archived, which means the schema stays in force while its definition becomes read-only. That is survivable and it is a real seam. Whether the schema's documentation should move somewhere still-writable before the archive is a separate call, and I am not making it here. ## Related The orchestration patterns Ward formalized are inventoried in #1325, landing on PR #1326, so what it taught outlives the repository regardless of which posture this issue ends on.

coilyco-ops referenced this issue from a commit

2026-08-27 10:15:33 +00:00

fix(skills): Ward is archived after all, superseding the #1299 freeze

coilyco-ops referenced this issue from a commit

2026-08-27 10:17:15 +00:00

fix(skills): Ward is archived after all, superseding the #1299 freeze

coilyco-ops referenced this issue

2026-08-27 10:17:28 +00:00

fix(skills): Ward is archived after all, superseding the #1299 freeze #1327

coilyco-ops referenced this issue from a commit

2026-08-27 10:19:05 +00:00

fix(skills): Ward is archived after all, superseding the #1299 freeze (#1327)

coilyco-ops referenced this issue from a commit

2026-08-27 10:25:46 +00:00

docs(ward): write the surviving .ward/ward.yaml schema into a writable repo

coilyco-ops referenced this issue

2026-08-27 10:26:04 +00:00

docs(ward): write the surviving .ward/ward.yaml schema into a writable repo #1328

coilyco-ops commented

2026-08-27 10:28:04 +00:00

Author

Owner

The schema-documentation seam is closed

The open question I left above is answered. PR #1328 landed the surviving .ward/ward.yaml contract into docs/ward-specs.md, which is writable, already the AOS-side Ward boundary page, and already linked from AGENTS.md. Archiving ward no longer takes the schema's only documentation with it.

Read before writing, so the doc records what is true rather than what Ward's page said. Three findings worth surfacing here, because each one changes what the archive costs:

capabilities: is a live key that Ward never documented. agentic-os-kai/scripts/pull-capabilities.py reads it to pull capability skills down into a single leaf repo, and coilyco-gaming/galaxy-gen declares it today. Copying Ward's page verbatim would have lost the one key anything actually reads.
catalog.description and catalog.dependsOn have no code reader on this host. Declared in nearly every repo, read by nothing I could find. Recorded as an honest gap rather than dressed up as a live input.
Two different files share the name. A root ward.yaml carrying tailnet.shortcut is fetched over the Forgejo API by infrastructure/scripts/generate-caddy-shortcuts.py, with coily.yaml and config.yml as migration fallbacks. Separate path, schema, and consumer from .ward/ward.yaml. Only pull-capabilities.py accepts both.

Also corrected in the same PR: this repository's own .ward/ward.yaml claimed it survived because check_catalog_block pinned its path. No such validator exists, and catalog-trifecta dropped the requirement fleet-wide under coilysiren/inbox#385.

What this issue still needs

Nothing changed about the scope section. The five call sites still need cutting, and that still happens before the archive. The sequencing comment above stands.

#1328 - the schema, landed.
#1326 and #1327 - the orchestration patterns Ward formalized, inventoried in tooling-agent-orchestration.
The follow-up filed alongside this comment, on whether 15 repositories should keep declaring a file no validator reads.

## The schema-documentation seam is closed The open question I left above is answered. PR #1328 landed the surviving `.ward/ward.yaml` contract into [`docs/ward-specs.md`](docs/ward-specs.md), which is writable, already the AOS-side Ward boundary page, and already linked from AGENTS.md. **Archiving ward no longer takes the schema's only documentation with it.** Read before writing, so the doc records what is true rather than what Ward's page said. Three findings worth surfacing here, because each one changes what the archive costs: * **`capabilities:` is a live key that Ward never documented.** `agentic-os-kai/scripts/pull-capabilities.py` reads it to pull capability skills down into a single leaf repo, and `coilyco-gaming/galaxy-gen` declares it today. Copying Ward's page verbatim would have lost the one key anything actually reads. * **`catalog.description` and `catalog.dependsOn` have no code reader on this host.** Declared in nearly every repo, read by nothing I could find. Recorded as an honest gap rather than dressed up as a live input. * **Two different files share the name.** A root `ward.yaml` carrying `tailnet.shortcut` is fetched over the Forgejo API by `infrastructure/scripts/generate-caddy-shortcuts.py`, with `coily.yaml` and `config.yml` as migration fallbacks. Separate path, schema, and consumer from `.ward/ward.yaml`. Only `pull-capabilities.py` accepts both. Also corrected in the same PR: this repository's own `.ward/ward.yaml` claimed it survived because `check_catalog_block` pinned its path. No such validator exists, and `catalog-trifecta` dropped the requirement fleet-wide under `coilysiren/inbox#385`. ## What this issue still needs Nothing changed about the scope section. The five call sites still need cutting, and that still happens before the archive. The sequencing comment above stands. ## Related * #1328 - the schema, landed. * #1326 and #1327 - the orchestration patterns Ward formalized, inventoried in `tooling-agent-orchestration`. * The follow-up filed alongside this comment, on whether 15 repositories should keep declaring a file no validator reads.

coilyco-ops referenced this issue

2026-08-27 10:28:25 +00:00

Decide whether 15 repos keep declaring .ward/ward.yaml, now that no validator reads it #1329

coilyco-ops referenced this issue

2026-08-28 18:00:04 +00:00

ci / ward-doctor fails on every open pull request while passing on main, blocking the merge lane #1343

coilyco-ops referenced this issue

2026-08-28 18:06:07 +00:00

ci / ward-doctor fails on every open pull request while passing on main, blocking the merge lane #1343

coilyco-ops referenced this issue

2026-08-28 18:15:12 +00:00

chore(ci): cut Ward's runtime out of AOS CI, since the repository is archived #1345