Move repo authority namespace policy out of ward core

coilyco-ops commented

2026-07-09 18:59:58 +00:00

Member

Bug

PR #857 implements the right general direction, but bakes Kai-specific namespace authority directly into ward code. That violates ward's product boundary.

The bad part is not the existence of an authority resolver. The bad part is encoding namespace policy in ward proper, including personal and coilyco orgs. The issue asked for coilysiren/* to become GitHub-authoritative for Kai's personal workflow, while coilyco-flight-deck/*, coilyco-bridge/*, and coilyco-gaming/* remain Forgejo-authoritative unless overridden. That policy is deployment/fleet config, not reusable ward binary behavior.

Concrete regression in PR #857:

cmd/ward/authority.go adds hardcoded namespace policy.
The diff references coilyco-gaming/* as a special case in ward proper.
CLI/help/docs in the PR also describe coilysiren/* as if ward itself knows that namespace.

Desired shape

Keep the architectural improvement:

one central repo/tracker authority resolver
explicit URLs remain authoritative
bare owner/repo#N can resolve through policy
advisor/director/reply/QA paths stop being Forgejo-only where the resolved authority is GitHub

But move the policy data out of ward core:

Ward core should have neutral defaults only.
Namespace/repo authority mappings should come from a config source, likely the existing KDL/config bundle path or another operator-local/fleet config surface.
The coilyco defaults belong in the coilyco/aos bundle, not compiled into ward.
Docs should describe the resolver and config mechanism, not state Kai's personal namespace as a built-in product rule.

Acceptance

No hardcoded references to coilysiren, coilyco-flight-deck, coilyco-bridge, or coilyco-gaming in ward authority resolver code or generic product docs, except historical issue refs or clearly marked examples if unavoidable.
The authority resolver reads explicit config for namespace/repo policy.
The coilyco/Kai policy is represented in the correct config layer, not in ward core.
Existing tests for Forgejo and GitHub resolution still pass using fixture config.
PR #857 is either amended before merge or superseded by this corrected implementation.
ward exec test passes.

Filed from the read-only director surface after Kai caught PR #857 hardcoding personal/coilyco org policy into ward.

## Bug PR #857 implements the right general direction, but bakes Kai-specific namespace authority directly into ward code. That violates ward's product boundary. The bad part is not the existence of an authority resolver. The bad part is encoding namespace policy in ward proper, including personal and coilyco orgs. The issue asked for `coilysiren/*` to become GitHub-authoritative for Kai's personal workflow, while `coilyco-flight-deck/*`, `coilyco-bridge/*`, and `coilyco-gaming/*` remain Forgejo-authoritative unless overridden. That policy is deployment/fleet config, not reusable ward binary behavior. Concrete regression in PR #857: * `cmd/ward/authority.go` adds hardcoded namespace policy. * The diff references `coilyco-gaming/*` as a special case in ward proper. * CLI/help/docs in the PR also describe `coilysiren/*` as if ward itself knows that namespace. ## Desired shape Keep the architectural improvement: * one central repo/tracker authority resolver * explicit URLs remain authoritative * bare `owner/repo#N` can resolve through policy * advisor/director/reply/QA paths stop being Forgejo-only where the resolved authority is GitHub But move the policy data out of ward core: * Ward core should have neutral defaults only. * Namespace/repo authority mappings should come from a config source, likely the existing KDL/config bundle path or another operator-local/fleet config surface. * The coilyco defaults belong in the coilyco/aos bundle, not compiled into ward. * Docs should describe the resolver and config mechanism, not state Kai's personal namespace as a built-in product rule. ## Acceptance * No hardcoded references to `coilysiren`, `coilyco-flight-deck`, `coilyco-bridge`, or `coilyco-gaming` in ward authority resolver code or generic product docs, except historical issue refs or clearly marked examples if unavoidable. * The authority resolver reads explicit config for namespace/repo policy. * The coilyco/Kai policy is represented in the correct config layer, not in ward core. * Existing tests for Forgejo and GitHub resolution still pass using fixture config. * PR #857 is either amended before merge or superseded by this corrected implementation. * `ward exec test` passes. Filed from the read-only director surface after Kai caught PR #857 hardcoding personal/coilyco org policy into ward.

coilyco-ops added the

headless

P1

labels

2026-07-09 18:59:58 +00:00

coilyco-ops referenced this issue

2026-07-09 19:00:05 +00:00

Make coilysiren repos GitHub-authoritative #857

coilyco-ops referenced this issue

2026-07-09 19:00:06 +00:00

Make coilysiren repos GitHub-authoritative #830

coilyco-ops commented

2026-07-09 19:00:16 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-09T19:00:14Z). 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#860 · branch issue-860 · harness codex · workflow pull-request
Run: engineer-codex-ward-860 · ward v0.493.0 · dispatched 2026-07-09T19:00:14Z
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-860` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T19:00:14Z). 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#860` · branch `issue-860` · harness `codex` · workflow `pull-request` - **Run:** `engineer-codex-ward-860` · ward `v0.493.0` · dispatched `2026-07-09T19:00:14Z` - **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 19:21:05 +00:00

Move repo authority policy out of ward core #862

coilyco-ops commented

2026-07-09 19:26:36 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: pull-request; review summary: skipped (review gate skipped by ~/.ward/config.yaml default)

The agent moved repo authority policy out of ward core, pushed the branch, opened PR #862, and kept CI green after fixing the lint fallout. It felt straightforward once the config split was clear. No surprises beyond the parser complexity lint, which needed a small refactor. Follow-up: merge PR #862 when policy allows.

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) The agent moved repo authority policy out of ward core, pushed the branch, opened PR #862, and kept CI green after fixing the lint fallout. It felt straightforward once the config split was clear. No surprises beyond the parser complexity lint, which needed a small refactor. Follow-up: merge PR #862 when policy allows. </details>

coilyco-ops referenced this issue

2026-07-09 19:29:54 +00:00

Make coilysiren repos GitHub-authoritative #857

coilyco-ops commented

2026-07-09 20:12:12 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-09T20:12:10Z). 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#860 · branch issue-860 · harness codex · workflow direct-to-main
Run: engineer-codex-ward-860 · ward v0.522.0 · dispatched 2026-07-09T20:12:10Z
Comment thread: 1 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-09T19:26:36Z)
- stripped: @coilyco-ops (2026-07-09T19:00:16Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-860` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T20:12:10Z). 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#860` · branch `issue-860` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-ward-860` · ward `v0.522.0` · dispatched `2026-07-09T20:12:10Z` - **Comment thread:** 1 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-09T19:26:36Z) - stripped: @coilyco-ops (2026-07-09T19:00:16Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.522.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-09 20:23:49 +00:00

fix: keep repo authority config-backed

coilyco-ops commented

2026-07-09 20:28:28 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-09T20:28: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).

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

Resolved: coilyco-flight-deck/ward#860 · branch issue-860 · harness codex · workflow direct-to-main
Run: engineer-codex-ward-860 · ward v0.522.0 · dispatched 2026-07-09T20:28:26Z
Comment thread: 1 included in the pre-flight read, 2 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-09T19:26:36Z)
- stripped: @coilyco-ops (2026-07-09T19:00:16Z), @coilyco-ops (2026-07-09T20:12:12Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-860` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T20:28: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#860` · branch `issue-860` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-ward-860` · ward `v0.522.0` · dispatched `2026-07-09T20:28:26Z` - **Comment thread:** 1 included in the pre-flight read, 2 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-09T19:26:36Z) - stripped: @coilyco-ops (2026-07-09T19:00:16Z), @coilyco-ops (2026-07-09T20:12:12Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.522.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-09 20:43:54 +00:00

merge: integrate main for repo authority policy repair

coilyco-ops closed this issue

2026-07-09 20:45:19 +00:00

coilyco-ops commented

2026-07-09 20:46:07 +00:00

Author

Member

WARD-OUTCOME: done

details

workflow: direct-to-main; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) Merged the config-backed repo authority fix, integrated current main, and pushed the landed commit(s). It felt like merge repair rather than feature work after the first pass was already in place. Follow-up: keep an eye on PR #862 closing cleanly.

WARD-OUTCOME: done <details><summary>details</summary> workflow: direct-to-main; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) Merged the config-backed repo authority fix, integrated current main, and pushed the landed commit(s). It felt like merge repair rather than feature work after the first pass was already in place. Follow-up: keep an eye on PR #862 closing cleanly. </details>

coilyco-ops referenced this issue

2026-07-09 21:07:59 +00:00

Move repo authority policy out of ward core #862

coilysiren referenced this issue

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

Rows
Columns

Move repo authority namespace policy out of ward core #860

Bug

Desired shape

Acceptance