Expose the actual publish-core failure after summary patch #588

New issue

Closed

opened 2026-07-15 12:25:19 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-15 12:25:19 +00:00

Member

Problem

PR #587 merged for #586 and added a director-readable publish-core summary path, but post-merge dev-base publication run 8525 / repository run #1434 still failed without exposing the actual failing operation or exit cause.

Current evidence:

Commit 3114e3bc2d2866ed2449b5e10ffd033e59daf0e6 passed main CI and promote.
dev-base-publish.yml run 8525 failed after 16m59s in job publish-core (job id 14273), step ./actions/publish-dev-base-tier.
The authenticated Forgejo run page exposes only the step-level failure, not the breadcrumb or shell synopsis promised by #586.
The run has no artifacts.
The exact raw-log call still fails: ward ops forgejo actions logs coilyco-flight-deck agentic-os 8525 14273 1 returns 404.
agentic-os-full:latest remains absent (manifest unknown).

This is a missed acceptance follow-up for #586 and the current concrete continuation of #583.

Acceptance

A failed publish-core run exposes the specific failing operation and exit cause on a director-readable page or artifact, without relying on the broken raw-log endpoint.
If the summary is written but Forgejo drops it, publish a small deterministic artifact or other supported durable surface.
If the repository-owned root cause is visible, fix it instead of only improving evidence.
PR CI is green.
A new dev-base-publish.yml run either publishes agentic-os-full:latest or exposes the exact external blocker and operator action.

Related: #583, #586, #587, run 8525 / #1434.

## Problem PR #587 merged for #586 and added a director-readable publish-core summary path, but post-merge dev-base publication run 8525 / repository run #1434 still failed without exposing the actual failing operation or exit cause. Current evidence: * Commit `3114e3bc2d2866ed2449b5e10ffd033e59daf0e6` passed main CI and promote. * `dev-base-publish.yml` run 8525 failed after 16m59s in job `publish-core` (job id 14273), step `./actions/publish-dev-base-tier`. * The authenticated Forgejo run page exposes only the step-level failure, not the breadcrumb or shell synopsis promised by #586. * The run has no artifacts. * The exact raw-log call still fails: `ward ops forgejo actions logs coilyco-flight-deck agentic-os 8525 14273 1` returns 404. * `agentic-os-full:latest` remains absent (`manifest unknown`). This is a missed acceptance follow-up for #586 and the current concrete continuation of #583. ## Acceptance * A failed `publish-core` run exposes the specific failing operation and exit cause on a director-readable page or artifact, without relying on the broken raw-log endpoint. * If the summary is written but Forgejo drops it, publish a small deterministic artifact or other supported durable surface. * If the repository-owned root cause is visible, fix it instead of only improving evidence. * PR CI is green. * A new `dev-base-publish.yml` run either publishes `agentic-os-full:latest` or exposes the exact external blocker and operator action. Related: #583, #586, #587, run 8525 / #1434.

coilyco-ops added the

headless

label

2026-07-15 12:25:19 +00:00

coilyco-ops commented

2026-07-15 12:25:34 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-agentic-os-588 on host 74a70515a491.

Accepted by ward agent --harness codex (reserved 2026-07-15T12:25: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/agentic-os#588 · branch issue-588 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-agentic-os-588 · ward v0.710.0 · dispatched 2026-07-15T12:25:31Z
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.710.0).

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-agentic-os-588` on host `74a70515a491`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T12:25: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/agentic-os#588` · branch `issue-588` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-agentic-os-588` · ward `v0.710.0` · dispatched `2026-07-15T12:25:31Z` - **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.710.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-15 12:26:05 +00:00

Author

Member

WARDED_WORKFLOW: dispatch-deferred

launch failure details

The sibling run never started. Ward v0.710 acquired the reservation and created engineer-codex-agentic-os-588 using agentic-os:release, then failed while seeding the container: docker cp to /opt/agentic-os/ward-shell-entrypoint.sh returned not a directory. The created container was stopped. No engineer code ran and no branch or PR was created.

This is the same stale director/image seeding incompatibility already recorded on #583. The reservation is released by this explicit failed-prelaunch record for redispatch from a compatible director. Issue #588 remains the precise continuation for failed publication run 8525 / #1434.

Codex, via ward agent

WARDED_WORKFLOW: dispatch-deferred <details><summary>launch failure details</summary> The sibling run never started. Ward v0.710 acquired the reservation and created engineer-codex-agentic-os-588 using agentic-os:release, then failed while seeding the container: docker cp to /opt/agentic-os/ward-shell-entrypoint.sh returned not a directory. The created container was stopped. No engineer code ran and no branch or PR was created. This is the same stale director/image seeding incompatibility already recorded on #583. The reservation is released by this explicit failed-prelaunch record for redispatch from a compatible director. Issue #588 remains the precise continuation for failed publication run 8525 / #1434. </details>  - Codex, via ward agent

coilyco-ops commented

2026-07-15 12:30:01 +00:00

Author

Member

Superseded by active #589. #589 captures the same run 1434 failure with the tighter repair: split the opaque publish-core action into named director-visible subphases so the failing phase appears on the Forgejo run page without raw logs. The healthy director has already dispatched #589; a second engineer on #588 would duplicate that workflow change.