coilyco-flight-deck/agentic-os

Fork 0

Make aos ward bundle usable as global WARD_CONFIG_REF #399

New issue

Closed

opened 2026-07-10 02:06:49 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-07-10 02:06:49 +00:00

Member

Kai hit warded init blockers that resolve to one atomic aos-side rollout: the aos .ward bundle must satisfy ward's current smart-default schema, then host shells should export it globally so ward does not fall back to the neutral embedded default.

Observed failures:

warded director --driver codex --repo coilysiren/inbox
ward: ward agent director --harness codex: refusing untrusted owner "coilysiren" (allowed: example-owner)

warded director --driver codex
ward: ward agent director --harness codex: refusing untrusted owner "coilyco-flight-deck" (allowed: example-owner)

Those first two are the neutral ward default: no WARD_CONFIG_REF is set, so trusted owners are example-owner only.

With the intended bundle selected explicitly:

WARD_CONFIG_REF=forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@main//.ward warded director --driver codex --repo coilysiren/inbox
ward: ward agent: smart defaults: missing top-level `repo-authority` block (fail-closed)

Root facts from the current check:

/substrate/agentic-os/.ward/ward-kdl.defaults.kdl has smart-defaults, but no top-level repo-authority block.
ward's current parser requires both top-level blocks.
ward's own current example/baked defaults already show the expected shape:

repo-authority default=forgejo {
    trusted-owner coilysiren
    trusted-owner coilyco-bridge
    trusted-owner coilyco-flight-deck
    trusted-owner coilyco-gaming
    repo "coilysiren/*" forge=github
    repo "coilyco-bridge/*" forge=forgejo
    repo "coilyco-flight-deck/*" forge=forgejo
    repo "coilyco-gaming/*" forge=forgejo
}

Scope:

Add the required repo-authority block to aos .ward/ward-kdl.defaults.kdl with the coilyco trusted-owner set and forge routing.
Add a host-shell export for WARD_CONFIG_REF=forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@main//.ward in the appropriate aos shell setup path, likely shell/common.sh, so new shells no longer fall back to ward's neutral example-owner embedded default.
Update docs/tests for the ward-specs bundle and shell env behavior.
Keep the rollout atomic: do not add the global env export without making the bundle parse successfully first.

Acceptance:

WARD_CONFIG_REF=forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@main//.ward warded director --driver codex --repo coilysiren/inbox --print no longer fails with missing repo-authority.
A new aos-managed shell has WARD_CONFIG_REF set to the aos .ward bundle.
Unqualified warded director --driver codex --repo coilysiren/inbox --print no longer reports allowed owner example-owner on Kai's aos-managed host shell.
Existing ward-specs tests pass, and a test or doc check covers that the aos bundle includes repo-authority.

Related ward context: ward#920, ward#876/#907.

Kai hit warded init blockers that resolve to one atomic aos-side rollout: the aos `.ward` bundle must satisfy ward's current smart-default schema, then host shells should export it globally so ward does not fall back to the neutral embedded default. Observed failures: ```text warded director --driver codex --repo coilysiren/inbox ward: ward agent director --harness codex: refusing untrusted owner "coilysiren" (allowed: example-owner) warded director --driver codex ward: ward agent director --harness codex: refusing untrusted owner "coilyco-flight-deck" (allowed: example-owner) ``` Those first two are the neutral ward default: no `WARD_CONFIG_REF` is set, so trusted owners are `example-owner` only. With the intended bundle selected explicitly: ```text WARD_CONFIG_REF=forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@main//.ward warded director --driver codex --repo coilysiren/inbox ward: ward agent: smart defaults: missing top-level `repo-authority` block (fail-closed) ``` Root facts from the current check: * `/substrate/agentic-os/.ward/ward-kdl.defaults.kdl` has `smart-defaults`, but no top-level `repo-authority` block. * ward's current parser requires both top-level blocks. * ward's own current example/baked defaults already show the expected shape: ```kdl repo-authority default=forgejo { trusted-owner coilysiren trusted-owner coilyco-bridge trusted-owner coilyco-flight-deck trusted-owner coilyco-gaming repo "coilysiren/*" forge=github repo "coilyco-bridge/*" forge=forgejo repo "coilyco-flight-deck/*" forge=forgejo repo "coilyco-gaming/*" forge=forgejo } ``` Scope: * Add the required `repo-authority` block to aos `.ward/ward-kdl.defaults.kdl` with the coilyco trusted-owner set and forge routing. * Add a host-shell export for `WARD_CONFIG_REF=forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@main//.ward` in the appropriate aos shell setup path, likely `shell/common.sh`, so new shells no longer fall back to ward's neutral `example-owner` embedded default. * Update docs/tests for the ward-specs bundle and shell env behavior. * Keep the rollout atomic: do not add the global env export without making the bundle parse successfully first. Acceptance: * `WARD_CONFIG_REF=forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@main//.ward warded director --driver codex --repo coilysiren/inbox --print` no longer fails with missing `repo-authority`. * A new aos-managed shell has `WARD_CONFIG_REF` set to the aos `.ward` bundle. * Unqualified `warded director --driver codex --repo coilysiren/inbox --print` no longer reports allowed owner `example-owner` on Kai's aos-managed host shell. * Existing ward-specs tests pass, and a test or doc check covers that the aos bundle includes `repo-authority`. Related ward context: ward#920, ward#876/#907.

coilyco-ops added the

headless

labels

2026-07-10 02:06:57 +00:00

coilyco-ops commented

2026-07-10 02:11:30 +00:00

Author

Member

Additional evidence: this also explains brokered dispatches that forward but never reserve.

Host-side reproduction:

ward agent engineer coilyco-flight-deck/ward#927 --harness codex --ward-version v0.543.0
ward agent: resolved issue ref coilyco-flight-deck/ward#927 -> coilyco-flight-deck/ward#927
ward: ward agent engineer --harness codex: refusing untrusted owner "coilyco-flight-deck" (allowed: example-owner). This build dispatches only for its configured trusted owners - see docs/agent-trust-gate.md

That is the same missing-global-WARD_CONFIG_REF path: host ward falls back to the neutral embedded default and trusts only example-owner.

With the intended config ref set:

WARD_CONFIG_REF=forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@main//.ward ward agent engineer coilyco-flight-deck/ward#927 --harness codex --ward-version v0.543.0
ward: ward agent: smart defaults: missing top-level `repo-authority` block (fail-closed)

So this blocks both direct host dispatch and director-surface broker forwarding. The broker is not a separate failure here. It shells through host ward and hits the same unusable config bundle before reservation.

Additional evidence: this also explains brokered dispatches that forward but never reserve. Host-side reproduction: ```text ward agent engineer coilyco-flight-deck/ward#927 --harness codex --ward-version v0.543.0 ward agent: resolved issue ref coilyco-flight-deck/ward#927 -> coilyco-flight-deck/ward#927 ward: ward agent engineer --harness codex: refusing untrusted owner "coilyco-flight-deck" (allowed: example-owner). This build dispatches only for its configured trusted owners - see docs/agent-trust-gate.md ``` That is the same missing-global-`WARD_CONFIG_REF` path: host ward falls back to the neutral embedded default and trusts only `example-owner`. With the intended config ref set: ```text WARD_CONFIG_REF=forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@main//.ward ward agent engineer coilyco-flight-deck/ward#927 --harness codex --ward-version v0.543.0 ward: ward agent: smart defaults: missing top-level `repo-authority` block (fail-closed) ``` So this blocks both direct host dispatch and director-surface broker forwarding. The broker is not a separate failure here. It shells through host ward and hits the same unusable config bundle before reservation.

coilyco-ops commented

2026-07-10 02:15:23 +00:00

Author

Member

Kai patched the bundle side by hand on agentic-os main.

Verified on a fresh /scratch clone:

.ward/ward-kdl.defaults.kdl now includes the required top-level repo-authority block with the coilyco trusted-owner set and forge routing.
shell/common.sh on origin/main still does not export WARD_CONFIG_REF.

So the explicit-env path should no longer fail with missing repo-authority, but new shells will still fall back to ward's neutral example-owner default until the shell export lands.

Still needed:

export WARD_CONFIG_REF="forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@main//.ward"

Place that beside WARD_LOCKDOWN_ROOT in shell/common.sh, inside the _SIREN_SHELL_ENV block.

Kai patched the bundle side by hand on `agentic-os` main. Verified on a fresh `/scratch` clone: * `.ward/ward-kdl.defaults.kdl` now includes the required top-level `repo-authority` block with the coilyco trusted-owner set and forge routing. * `shell/common.sh` on `origin/main` still does **not** export `WARD_CONFIG_REF`. So the explicit-env path should no longer fail with missing `repo-authority`, but new shells will still fall back to ward's neutral `example-owner` default until the shell export lands. Still needed: ```bash export WARD_CONFIG_REF="forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@main//.ward" ``` Place that beside `WARD_LOCKDOWN_ROOT` in `shell/common.sh`, inside the `_SIREN_SHELL_ENV` block.

coilysiren referenced this issue from coilyco-flight-deck/ward

2026-07-10 04:03:12 +00:00

ward release race condition #935

coilyco-ops commented

2026-07-10 04:49:35 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-agentic-os-399 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T04:49:34Z). 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/agentic-os#399 · branch issue-399 · harness codex · workflow direct-main
Run: engineer-codex-agentic-os-399 · ward v0.555.0 · dispatched 2026-07-10T04:49:34Z
Comment thread: 2 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T02:11:30Z), @coilyco-ops (2026-07-10T02:15:23Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-agentic-os-399` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T04:49:34Z). 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/agentic-os#399` · branch `issue-399` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-agentic-os-399` · ward `v0.555.0` · dispatched `2026-07-10T04:49:34Z` - **Comment thread:** 2 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T02:11:30Z), @coilyco-ops (2026-07-10T02:15:23Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.555.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-10 05:01:14 +00:00

docs: pin ward bundle contract

coilyco-ops closed this issue

2026-07-10 05:01:14 +00:00

coilyco-ops commented

2026-07-10 05:03:50 +00:00

Author

Member

WARD-OUTCOME: done

details

workflow: direct-main; review summary: skipped, per ~/.ward/config.yaml default
in-container review gate: skipped because review gate skipped by ~/.ward/config.yaml default
retrospective: the implementation was mostly a contract-sync job. the stale bundle validator was the real blocker, not the ward bundle content.
confidence: high
surprises: the repo already had the shell export and bundle files, but the validator still lagged the current defaults.
follow-ups: none

WARD-OUTCOME: done <details><summary>details</summary> workflow: direct-main; review summary: skipped, per `~/.ward/config.yaml` default in-container review gate: skipped because review gate skipped by `~/.ward/config.yaml` default retrospective: the implementation was mostly a contract-sync job. the stale bundle validator was the real blocker, not the ward bundle content. confidence: high surprises: the repo already had the shell export and bundle files, but the validator still lagged the current defaults. follow-ups: none </details>

coilysiren referenced this issue from coilyco-flight-deck/ward

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283