Remove consumer guardfile filename assumptions from ward config-source loading #1049

New issue

Closed

opened 2026-07-10 17:23:11 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-10 17:23:11 +00:00

Member

Problem

Commit 60133a84ea53e41c9eb9aacaa3dde711258396f8 changed cmd/ward/configsource.go so the upstream ward WARD_CONFIG_REF consumer selects the coilyco bundle ops surface by a hard-coded guardfile member name:

bundleForgejoGuardfilePath = "guardfile.forgejo.kdl"

That commit was trying to avoid loading guardfile.forgejo.write.kdl, which is a role-facing tier that inherits another guardfile and cannot be byte-parsed as a standalone ops surface. The immediate failure mode makes sense, but the fix puts a consumer bundle file path into upstream ward's runtime contract.

This violates the intended layer split:

aos owns the coilyco deployment bundle and its exact guardfile layout.
ward owns the neutral product and consumes a configured WARD_CONFIG_REF bundle generically.
ward should not need to know that the coilyco bundle has a compatibility monolith named guardfile.forgejo.kdl.

Do

Remove consumer-specific guardfile filename assumptions from upstream ward's config-source selection.
Add an explicit bundle-level entrypoint or metadata field for the ops Forgejo surface, or derive it from neutral bundle metadata rather than from a coilyco filename constant.
Keep role-facing guardfile bindings in roles.kdl separate from the ops CLI surface entrypoint.
Move any coilyco-specific file names into aos bundle metadata or test fixtures, not product code.
Update tests so upstream ward can prove the generic entrypoint path without depending on the coilyco .ward source layout.

Acceptance

Upstream ward code does not hard-code coilyco/aos consumer guardfile member names such as guardfile.forgejo.kdl as product constants.
A WARD_CONFIG_REF bundle can declare or otherwise expose the Forgejo ops surface entrypoint generically.
The coilyco aos bundle still mounts ward ops forgejo with real values.
Role guardfiles that inherit other role tiers are not byte-parsed as standalone ops surfaces.
Tests cover a neutral fixture bundle and the coilyco compatibility path without treating the coilyco filename as the upstream default.

Related: ward#1009, aos#332, commit 60133a84ea53e41c9eb9aacaa3dde711258396f8.

## Problem Commit `60133a84ea53e41c9eb9aacaa3dde711258396f8` changed `cmd/ward/configsource.go` so the upstream ward `WARD_CONFIG_REF` consumer selects the coilyco bundle ops surface by a hard-coded guardfile member name: ```go bundleForgejoGuardfilePath = "guardfile.forgejo.kdl" ``` That commit was trying to avoid loading `guardfile.forgejo.write.kdl`, which is a role-facing tier that inherits another guardfile and cannot be byte-parsed as a standalone ops surface. The immediate failure mode makes sense, but the fix puts a consumer bundle file path into upstream ward's runtime contract. This violates the intended layer split: * aos owns the coilyco deployment bundle and its exact guardfile layout. * ward owns the neutral product and consumes a configured `WARD_CONFIG_REF` bundle generically. * ward should not need to know that the coilyco bundle has a compatibility monolith named `guardfile.forgejo.kdl`. ## Do * Remove consumer-specific guardfile filename assumptions from upstream ward's config-source selection. * Add an explicit bundle-level entrypoint or metadata field for the ops Forgejo surface, or derive it from neutral bundle metadata rather than from a coilyco filename constant. * Keep role-facing guardfile bindings in `roles.kdl` separate from the ops CLI surface entrypoint. * Move any coilyco-specific file names into aos bundle metadata or test fixtures, not product code. * Update tests so upstream ward can prove the generic entrypoint path without depending on the coilyco `.ward` source layout. ## Acceptance * Upstream ward code does not hard-code coilyco/aos consumer guardfile member names such as `guardfile.forgejo.kdl` as product constants. * A `WARD_CONFIG_REF` bundle can declare or otherwise expose the Forgejo ops surface entrypoint generically. * The coilyco aos bundle still mounts `ward ops forgejo` with real values. * Role guardfiles that inherit other role tiers are not byte-parsed as standalone ops surfaces. * Tests cover a neutral fixture bundle and the coilyco compatibility path without treating the coilyco filename as the upstream default. Related: ward#1009, aos#332, commit `60133a84ea53e41c9eb9aacaa3dde711258396f8`.

coilyco-ops added the

headless

labels

2026-07-10 17:23:11 +00:00

coilyco-ops commented

2026-07-10 17:23:24 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T17:23:23Z). 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#1049 · branch issue-1049 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-1049 · ward v0.584.0 · dispatched 2026-07-10T17:23:23Z
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.584.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-1049` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T17:23:23Z). 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#1049` · branch `issue-1049` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-1049` · ward `v0.584.0` · dispatched `2026-07-10T17:23:23Z` - **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.584.0). </details> </details>  — Codex, via `ward agent`

~~coilyco-ops referenced this issue 2026-07-10 17:36:20 +00:00~~

Fix forgejo bundle metadata selection #1058

coilyco-ops commented

2026-07-10 17:40:07 +00:00

Author

Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skipped: review gate skipped by ~/.ward/config.yaml default
felt: straightforward after the cache-key fix
confidence: high
surprise: Forgejo's config-bundle cache needed TTL=0 in the live-ref test to avoid stale checkout reuse
follow-ups: none

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skipped: review gate skipped by ~/.ward/config.yaml default felt: straightforward after the cache-key fix confidence: high surprise: Forgejo's config-bundle cache needed TTL=0 in the live-ref test to avoid stale checkout reuse follow-ups: none </details>

~~coilyco-ops referenced this issue 2026-07-10 17:46:47 +00:00~~

Fix forgejo bundle metadata selection #1058

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

2026-07-10 20:30:05 +00:00

Fix forgejo bundle metadata selection #1058