coilyco-flight-deck/ward

Fork 0

Make WARD_CONFIG_REF bundle loading independent of consumer KDL filenames #1064

New issue

Closed

opened 2026-07-10 17:46:06 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-07-10 17:46:06 +00:00

Member

Problem

PR #1058 fixes one Forgejo bundle metadata path, but it still leaves upstream ward hardcoding consumer KDL member names in the config bundle loader.

Examples visible in the PR include constants for bundle members such as:

agents.kdl
roles.kdl
defaults.kdl
repos.kdl
ward-kdl.topology.kdl
guardfile.forgejo.kdl / ops.forgejo.kdl

Ward should not know or depend on the physical file names chosen by a consumer KDL bundle.

Desired behavior

Treat a WARD_CONFIG_REF bundle as a set of KDL sources that aggregate into one logical model. Semantic KDL nodes should be discoverable regardless of whether a consumer keeps them in one file, many files, or moves settings between files.

The location of smart defaults, roles, agent roster config, repos, topology, and guard surfaces should be fully fluid between KDL files. Physical filenames are a packaging detail, not an API contract.

Acceptance

Upstream ward has no constants or logic that require consumer filenames such as agents.kdl, roles.kdl, defaults.kdl, repos.kdl, ward-kdl.topology.kdl, guardfile.forgejo.kdl, or ops.forgejo.kdl.
Bundle loading parses configured KDL sources into one logical document or equivalent merged semantic model.
Tests prove the same settings work when split across arbitrary filenames and when aggregated into one KDL file.
Duplicate or conflicting semantic nodes fail closed with an actionable diagnostic.
The fix replaces PR #1058 rather than landing its filename-specific approach.

ward#1049
ward PR #1058
aos#332

## Problem PR #1058 fixes one Forgejo bundle metadata path, but it still leaves upstream ward hardcoding consumer KDL member names in the config bundle loader. Examples visible in the PR include constants for bundle members such as: - `agents.kdl` - `roles.kdl` - `defaults.kdl` - `repos.kdl` - `ward-kdl.topology.kdl` - `guardfile.forgejo.kdl` / `ops.forgejo.kdl` Ward should not know or depend on the physical file names chosen by a consumer KDL bundle. ## Desired behavior Treat a `WARD_CONFIG_REF` bundle as a set of KDL sources that aggregate into one logical model. Semantic KDL nodes should be discoverable regardless of whether a consumer keeps them in one file, many files, or moves settings between files. The location of smart defaults, roles, agent roster config, repos, topology, and guard surfaces should be fully fluid between KDL files. Physical filenames are a packaging detail, not an API contract. ## Acceptance - Upstream ward has no constants or logic that require consumer filenames such as `agents.kdl`, `roles.kdl`, `defaults.kdl`, `repos.kdl`, `ward-kdl.topology.kdl`, `guardfile.forgejo.kdl`, or `ops.forgejo.kdl`. - Bundle loading parses configured KDL sources into one logical document or equivalent merged semantic model. - Tests prove the same settings work when split across arbitrary filenames and when aggregated into one KDL file. - Duplicate or conflicting semantic nodes fail closed with an actionable diagnostic. - The fix replaces PR #1058 rather than landing its filename-specific approach. ## Related - ward#1049 - ward PR #1058 - aos#332

coilyco-ops added the

headless

labels

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

coilyco-ops commented

2026-07-10 17:46:29 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T17:46:28Z). 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#1064 · branch issue-1064 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-1064 · ward v0.584.0 · dispatched 2026-07-10T17:46:28Z
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-1064` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T17:46:28Z). 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#1064` · branch `issue-1064` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-1064` · ward `v0.584.0` · dispatched `2026-07-10T17:46:28Z` - **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: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 18:23:12 +00:00

Make WARD_CONFIG_REF bundle loading independent of consumer KDL filenames #1071

coilyco-ops commented

2026-07-10 18:26:26 +00:00

Author

Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default
implementation: merged WARD_CONFIG_REF bundles by semantic KDL nodes, kept defaults/fleet/topology file-agnostic, and fail-closed on real conflicts.
retrospective: the only surprises were the same-root Forgejo overlay and the test-only scripts package that golangci-lint needed a stub for.
confidence: high
follow-ups: none

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default implementation: merged WARD_CONFIG_REF bundles by semantic KDL nodes, kept defaults/fleet/topology file-agnostic, and fail-closed on real conflicts. retrospective: the only surprises were the same-root Forgejo overlay and the test-only scripts package that golangci-lint needed a stub for. confidence: high follow-ups: none </details>

coilyco-ops commented

2026-07-10 23:05:26 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-1064 on host KAI-DESKTOP-TOWER.

Reserved by ward agent --harness codex (reserved 2026-07-10T23:05:26Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#1064 · branch issue-1064 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-1064 · ward v0.605.0 · dispatched 2026-07-10T23:05:26Z
Comment thread: 1 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T18:26:26Z)
- stripped: @coilyco-ops (2026-07-10T17:46:29Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-1064` on host `KAI-DESKTOP-TOWER`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T23:05:26Z). 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#1064` · branch `issue-1064` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-1064` · ward `v0.605.0` · dispatched `2026-07-10T23:05:26Z` - **Comment thread:** 1 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T18:26:26Z) - stripped: @coilyco-ops (2026-07-10T17:46:29Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.605.0). </details> </details>  — Codex, via `ward agent`

coilysiren closed this issue

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

coilyco-ops commented

2026-07-10 23:27:44 +00:00

Author

Member

WARD-OUTCOME: submitted

details

workflow: pull-request-and-merge; review summary: review gate skipped because the temporary ward default pending brokered QA
implementation: merged semantic WARD_CONFIG_REF bundle loading across arbitrary KDL sources and kept duplicate/conflict handling fail-closed.
retrospective: the stale base and the deleted manifest seam were the only real snags.
confidence: high
surprises: Forgejo merged the PR while the branch refresh was still in flight.
follow-ups: none

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate skipped because the temporary ward default pending brokered QA implementation: merged semantic WARD_CONFIG_REF bundle loading across arbitrary KDL sources and kept duplicate/conflict handling fail-closed. retrospective: the stale base and the deleted manifest seam were the only real snags. confidence: high surprises: Forgejo merged the PR while the branch refresh was still in flight. follow-ups: none </details>