Add read-only bridge verbs backed by infrastructure's coordination hub #834

New issue

Closed

opened 2026-07-09 18:07:00 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

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

Member

Follow-up to coilyco-flight-deck/infrastructure#489.

ward#823 correctly identifies the need for a GitHub <=> Forgejo command hub, but the fleet-specific hub state should live in infrastructure, not in ward. This issue is the ward-side consumer surface once the infrastructure registry/status slice exists.

Depends on

This work depends on the infrastructure hub defining and publishing a machine-readable source for:

repo -> authoritative side
repo -> mirror target(s)
repo -> tracker authority
current mirror status and last-sync age

That should land by reframing and implementing the first slice of coilyco-flight-deck/infrastructure#475.

What ward should add

Read-only bridge verbs first:

ward ops bridge authoritative-side <owner/repo>
ward ops bridge mirror-status [owner/repo]
ward ops bridge divergent-refs [owner/repo]
ward ops bridge stale-syncs
ward ops bridge map-issue <ref>

Constraints

ward must consume infrastructure-published bridge facts, not grow its own parallel repo-mapping table or scheduler
default to read-only output
explicit writes like carry-pr stay deferred until the status path is proven
the surface must respect per-repo authority, including coilysiren/* moving GitHub-authoritative under ward#830

Acceptance

a read-only ward ops bridge ... surface exists for the commands above
the implementation clearly separates forge access from tracker access, so ward#827 can later plug a non-forge tracker into the same user-facing surface
docs name infrastructure as the state owner and ward as the command surface

Filed by ward agent advisor cross-repo fan-out from coilyco-flight-deck/infrastructure#489 (part 1 of 2, ward#424).

— Codex, via ward agent

Follow-up to `coilyco-flight-deck/infrastructure#489`. `ward#823` correctly identifies the need for a GitHub <=> Forgejo command hub, but the fleet-specific hub state should live in infrastructure, not in ward. This issue is the **ward-side consumer surface** once the infrastructure registry/status slice exists. ## Depends on This work depends on the infrastructure hub defining and publishing a machine-readable source for: - repo -> authoritative side - repo -> mirror target(s) - repo -> tracker authority - current mirror status and last-sync age That should land by reframing and implementing the first slice of `coilyco-flight-deck/infrastructure#475`. ## What ward should add Read-only bridge verbs first: - `ward ops bridge authoritative-side <owner/repo>` - `ward ops bridge mirror-status [owner/repo]` - `ward ops bridge divergent-refs [owner/repo]` - `ward ops bridge stale-syncs` - `ward ops bridge map-issue <ref>` ## Constraints - ward must **consume** infrastructure-published bridge facts, not grow its own parallel repo-mapping table or scheduler - default to read-only output - explicit writes like `carry-pr` stay deferred until the status path is proven - the surface must respect per-repo authority, including `coilysiren/*` moving GitHub-authoritative under `ward#830` ## Acceptance - a read-only `ward ops bridge ...` surface exists for the commands above - the implementation clearly separates forge access from tracker access, so `ward#827` can later plug a non-forge tracker into the same user-facing surface - docs name infrastructure as the state owner and ward as the command surface --- Filed by `ward agent advisor` cross-repo fan-out from coilyco-flight-deck/infrastructure#489 (part 1 of 2, ward#424).  — Codex, via `ward agent`

coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure

2026-07-09 18:07:02 +00:00

Make infrastructure the GitHub <=> Forgejo coordination hub #489

coilyco-ops added the

headless

labels

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

coilyco-ops commented

2026-07-09 22:44:30 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-09T22:44: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#834 · branch issue-834 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-834 · ward v0.540.0 · dispatched 2026-07-09T22:44: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.540.0).

— Codex, via ward agent

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

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

2026-07-09 23:53:54 +00:00

Add read-only bridge verbs backed by infrastructure's coordination hub #891