Remove ward from default warded agent substrate #801

New issue

Closed

opened 2026-07-09 15:40:35 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 15:40:35 +00:00

Member

Problem

Inbox coilysiren/inbox#182 says ward should not be permanently embedded in warded agent substrate. Ward is the product under test, not an upstream third-party reference repo that every Ward User Alice should carry in substrate. Keeping ward mounted as agent substrate hides missing self-documentation and makes the user-facing behavior depend on Kai's development topology.

Do

Find where warded/director/engineer containers decide which substrate repos are mounted.
Remove coilyco-flight-deck/ward from the default substrate set for ordinary warded agent runs.
Preserve any explicit self-development path ward needs when the target repo is ward itself. In that case, /workspace/ward is the work surface and should provide the product docs/source.
Make ward self-documenting enough that a non-ward target does not need /substrate/ward for command discovery, workflow semantics, or container doctrine.
Update docs/tests that describe the default substrate surface.

Acceptance

A warded agent run targeting a non-ward repo no longer receives ward as a default substrate checkout.
Ward-targeted runs still have the ward repo as their target workspace and can complete normally.
Any docs formerly read from /substrate/ward by agents are available through ward's own command help or docs shipped with the target context.
Tests cover the default substrate list or the config path that builds it.
ward exec test passes.

Source: coilysiren/inbox#182

Codex, via ward agent

## Problem Inbox `coilysiren/inbox#182` says ward should not be permanently embedded in warded agent substrate. Ward is the product under test, not an upstream third-party reference repo that every Ward User Alice should carry in substrate. Keeping ward mounted as agent substrate hides missing self-documentation and makes the user-facing behavior depend on Kai's development topology. ## Do * Find where warded/director/engineer containers decide which substrate repos are mounted. * Remove `coilyco-flight-deck/ward` from the default substrate set for ordinary warded agent runs. * Preserve any explicit self-development path ward needs when the target repo is ward itself. In that case, `/workspace/ward` is the work surface and should provide the product docs/source. * Make ward self-documenting enough that a non-ward target does not need `/substrate/ward` for command discovery, workflow semantics, or container doctrine. * Update docs/tests that describe the default substrate surface. ## Acceptance * A warded agent run targeting a non-ward repo no longer receives ward as a default substrate checkout. * Ward-targeted runs still have the ward repo as their target workspace and can complete normally. * Any docs formerly read from `/substrate/ward` by agents are available through ward's own command help or docs shipped with the target context. * Tests cover the default substrate list or the config path that builds it. * `ward exec test` passes. Source: https://forgejo.coilysiren.me/coilysiren/inbox/issues/182  Codex, via `ward agent`

coilyco-ops commented

2026-07-09 15:40:44 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-801 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T15:40:42Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h 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/ward#801 · branch issue-801 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-801 · ward v0.493.0 · dispatched 2026-07-09T15:40:42Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-801` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T15:40:42Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h 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/ward#801` · branch `issue-801` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-801` · ward `v0.493.0` · dispatched `2026-07-09T15:40:42Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-09 15:46:56 +00:00

Remove ward from default warded agent substrate #802

coilyco-ops closed this issue

2026-07-09 15:49:33 +00:00

coilyco-ops commented

2026-07-09 15:49:56 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: pull-request-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default
felt: straightforward; confidence: high; surprises: Forgejo queued the check before it turned green.
follow-ups: none.

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default felt: straightforward; confidence: high; surprises: Forgejo queued the check before it turned green. follow-ups: none. </details>

coilyco-ops referenced this issue

2026-07-09 15:52:09 +00:00

Correct PR 802: move default substrate ownership to aos #805