coilyco-flight-deck/ward

Watch

Scope the GitHub authority exception to coilysiren/coilysiren, not coilysiren/* #1520

New issue

Closed

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

coilyco-ops commented

2026-07-23 05:00:17 +00:00

Member

Observed

coilysiren/website is a conventional Forgejo-canonical repository:

Forgejo reports mirror: false, default_branch: main, and has_issues: true.
Forgejo and GitHub main were equal at a5e61a14e1edc1805307943f257c650f3e25d226 during the reproduction.
The fleet convention says Forgejo is canonical by default. Only the GitHub profile repository coilysiren/coilysiren is the documented inversion because GitHub renders its main branch.

Despite that, this dispatch:

warded engineer coilysiren/website#66

resolved the logical ref and then failed in the broker with:

github: get issue coilysiren/website#66

The website issue exists on Forgejo at coilysiren/website#66. Ward selected the wrong authority before engineer launch.

Likely cause

#1498 already records a baked/default coilysiren/* GitHub repository policy. That wildcard is too broad. It appears to encode the special profile-repo inversion as an owner-wide rule and misclassifies normal sibling repositories such as coilysiren/website.

Inspect the active config-source precedence rather than patching only one generated copy. The wrong rule may exist in source KDL, embedded/generated assets, selected runtime bundles, tests, or more than one layer.

Fix

Replace the owner-wide coilysiren/* GitHub authority override with an exact coilysiren/coilysiren match.
Keep Forgejo as the default authority for other coilysiren/* repositories, including coilysiren/website.
Regenerate or update every derived artifact needed for the active runtime to receive the correction.
Make repo-authority diagnostics identify the rule and config source that matched, so future wildcard leaks are visible without reading the binary.
Audit other special-case repository rules for owner-wide patterns that were intended to target one repository.

This is the narrow configuration correction. The broader product work to carry tracker, checkout, landing, and mirror authority independently is tracked at #1519.

Acceptance

A unit/config test proves coilysiren/coilysiren selects the GitHub git authority exception.
A sibling test proves coilysiren/website selects Forgejo and that an exact exception does not leak to the owner wildcard.
A broker-level or resolver test proves coilysiren/website#66 reads the Forgejo issue instead of attempting GitHub.
--print or equivalent diagnostics show the matched authority rule and its config-source provenance.
Existing Forgejo-only and GitHub-native repository behavior remains unchanged.
Ward validation gates pass.

Relationships

Immediate blocked lane: coilysiren/website#66
Broader split-stack authority contract: #1519
Baked fleet-config audit: #1498

## Observed `coilysiren/website` is a conventional Forgejo-canonical repository: - Forgejo reports `mirror: false`, `default_branch: main`, and `has_issues: true`. - Forgejo and GitHub `main` were equal at `a5e61a14e1edc1805307943f257c650f3e25d226` during the reproduction. - The fleet convention says Forgejo is canonical by default. Only the GitHub profile repository `coilysiren/coilysiren` is the documented inversion because GitHub renders its `main` branch. Despite that, this dispatch: ```text warded engineer coilysiren/website#66 ``` resolved the logical ref and then failed in the broker with: ```text github: get issue coilysiren/website#66 ``` The website issue exists on Forgejo at https://forgejo.coilysiren.me/coilysiren/website/issues/66. Ward selected the wrong authority before engineer launch. ## Likely cause https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/1498 already records a baked/default `coilysiren/*` GitHub repository policy. That wildcard is too broad. It appears to encode the special profile-repo inversion as an owner-wide rule and misclassifies normal sibling repositories such as `coilysiren/website`. Inspect the active config-source precedence rather than patching only one generated copy. The wrong rule may exist in source KDL, embedded/generated assets, selected runtime bundles, tests, or more than one layer. ## Fix - Replace the owner-wide `coilysiren/*` GitHub authority override with an exact `coilysiren/coilysiren` match. - Keep Forgejo as the default authority for other `coilysiren/*` repositories, including `coilysiren/website`. - Regenerate or update every derived artifact needed for the active runtime to receive the correction. - Make repo-authority diagnostics identify the rule and config source that matched, so future wildcard leaks are visible without reading the binary. - Audit other special-case repository rules for owner-wide patterns that were intended to target one repository. This is the narrow configuration correction. The broader product work to carry tracker, checkout, landing, and mirror authority independently is tracked at https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/1519. ## Acceptance - A unit/config test proves `coilysiren/coilysiren` selects the GitHub git authority exception. - A sibling test proves `coilysiren/website` selects Forgejo and that an exact exception does not leak to the owner wildcard. - A broker-level or resolver test proves `coilysiren/website#66` reads the Forgejo issue instead of attempting GitHub. - `--print` or equivalent diagnostics show the matched authority rule and its config-source provenance. - Existing Forgejo-only and GitHub-native repository behavior remains unchanged. - Ward validation gates pass. ## Relationships - Immediate blocked lane: https://forgejo.coilysiren.me/coilysiren/website/issues/66 - Broader split-stack authority contract: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/1519 - Baked fleet-config audit: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/1498

coilyco-ops added the

autonomy

headless

priority

labels

2026-07-23 05:00:17 +00:00

coilyco-ops commented

2026-07-23 05:00:35 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-ward-1520 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness codex (reserved 2026-07-23T05:00:34Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation 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#1520 · branch issue-1520 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1520 · ward v0.789.0 · dispatched 2026-07-23T05:00:29Z
Reservation: held
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.789.0).

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1520` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-23T05:00:34Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` 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#1520` · branch `issue-1520` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1520` · ward `v0.789.0` · dispatched `2026-07-23T05:00:29Z` - **Reservation:** held - **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.789.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-23 05:09:03 +00:00

Author

Member

Closing as an invalid premise discovered after dispatch. The active WARD_CONFIG_REF is the AOS bundle at 524e576, whose .ward/repos.kdl explicitly routes coilysiren/* to GitHub. Ward is following that selected policy correctly. The rule was introduced intentionally by Ward commit 7812345 (make coilysiren repos github-authoritative), whose migration contract says existing Forgejo issues must be migrated to GitHub or closed. AOS issue 399 then copied that policy into the runtime bundle. coilysiren/website still has unmigrated Forgejo issues while its GitHub issue/PR surface is disabled, so the remaining problem is migration/config reconciliation, not a Ward wildcard-resolution bug. The dispatched engineer was stopped before landing.

Closing as an invalid premise discovered after dispatch. The active `WARD_CONFIG_REF` is the AOS bundle at `524e576`, whose `.ward/repos.kdl` explicitly routes `coilysiren/*` to GitHub. Ward is following that selected policy correctly. The rule was introduced intentionally by Ward commit `7812345` (make coilysiren repos github-authoritative), whose migration contract says existing Forgejo issues must be migrated to GitHub or closed. AOS issue 399 then copied that policy into the runtime bundle. `coilysiren/website` still has unmigrated Forgejo issues while its GitHub issue/PR surface is disabled, so the remaining problem is migration/config reconciliation, not a Ward wildcard-resolution bug. The dispatched engineer was stopped before landing.

coilyco-ops closed this issue

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

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/ward#1520

No description provided.

Rows
Columns