phase-pr and ci-gate write the ci_pending card from two hand-copied definitions

claude commented

2026-09-16 09:02:00 +00:00

Member

Found while working IW-566.

The ci_pending review-state card is written from two places that must agree, and nothing makes them agree.

CiGate.markPending (core/commands/CiGate.scala:254-268) is private, so PhasePr.handOffWait cannot call it. The --no-wait path therefore copies the same five fields by hand. Both writers must set the same status, the same display text and the same clearCiWaitStarted, or BatchImplement.decideOutcome maps one of them to the wrong outcome — and a test passing against one writer proves nothing about the other.

PROPOSED FIX. Extract one builder for the ci_pending card shape and have both CiGate and PhasePr call it, so the card contract has a single definition.

WHILE THERE. PhasePr.handOffWait and the pre-existing PhasePr.handOver differ by one word but sit at different points in the lifecycle — handOver after the wait, handOffWait before it. Renaming the latter to deferCiWait would stop the two reading as variants of one thing.

Found while working IW-566. The `ci_pending` review-state card is written from two places that must agree, and nothing makes them agree. `CiGate.markPending` (`core/commands/CiGate.scala:254-268`) is `private`, so `PhasePr.handOffWait` cannot call it. The `--no-wait` path therefore copies the same five fields by hand. Both writers must set the same status, the same display text and the same `clearCiWaitStarted`, or `BatchImplement.decideOutcome` maps one of them to the wrong outcome — and a test passing against one writer proves nothing about the other. PROPOSED FIX. Extract one builder for the `ci_pending` card shape and have both `CiGate` and `PhasePr` call it, so the card contract has a single definition. WHILE THERE. `PhasePr.handOffWait` and the pre-existing `PhasePr.handOver` differ by one word but sit at different points in the lifecycle — `handOver` after the wait, `handOffWait` before it. Renaming the latter to `deferCiWait` would stop the two reading as variants of one thing.

mph referenced this issue from a commit

2026-09-16 09:03:38 +00:00

workflow(IW-566): review packet, release notes, follow-ups filed

claude referenced this issue

2026-09-16 09:04:01 +00:00

IW-566: phase-pr --no-wait — open the pull request, leave the CI wait to the caller #571

claude referenced this issue

2026-09-21 14:50:30 +00:00

ReviewStateUpdater clears ci_wait_started and ci_wait_sha with two flags that every caller must set together #595

claude referenced this issue

2026-09-21 19:32:19 +00:00

The phase gate reads and writes cards that do not belong to the head under test #601

claude referenced this issue

2026-09-22 06:25:45 +00:00

A re-run of phase-pr on a green phase writes ci_pending but keeps the old ci_gated_sha #608

claude commented

2026-09-22 06:25:50 +00:00

Author

Member

Found during IW-601 phase 2 (composition review): the same two writers also duplicate the ci_failed card. PhasePr.stop/reportRed and CiGateCommand.stop/reportRed build the same ci_failed update and red report in two copies (PhasePr.scala:553-590, CiGateCommand.scala:282-313). The single-builder fix should cover this card too.

Found during IW-601 phase 2 (composition review): the same two writers also duplicate the `ci_failed` card. `PhasePr.stop`/`reportRed` and `CiGateCommand.stop`/`reportRed` build the same `ci_failed` update and red report in two copies (`PhasePr.scala:553-590`, `CiGateCommand.scala:282-313`). The single-builder fix should cover this card too.

mph referenced this issue from a commit

2026-09-22 13:34:13 +00:00

workflow: Triage lessons for IW-601

claude commented

2026-10-15 21:16:42 +00:00

Author

Member

Intake: agent-ready
Workflow: waterfall
Reason: all gates passed
Analysis: project-management/issues/IW-568/analysis.md on branch IW-568

Intake: agent-ready Workflow: waterfall Reason: all gates passed Analysis: project-management/issues/IW-568/analysis.md on branch IW-568

claude added the

agent-ready

label

2026-10-15 21:16:42 +00:00

claude commented

2026-10-15 21:28:24 +00:00

Author

Member

Implement: needs-human
Reason: batch-implement exit 1 — the kanon plugin did not compile against this worktree's iw-cli core, so no phase ran

batch-implement stopped before it wrote batch-implement.log. The lines below are its console output. The installed kanon plugin (lib/batch/ForgeCatchUp.scala:143) expects Either[String, …] from tracker.fetchPullRequestForBranch. iw-cli main (#778–#780) changed the tracker port to return Either[TrackerError, …]. This failure is not specific to this issue: every batch-implement in iw-cli fails the same way until the plugin follows the port change.

[error] /home/mph/.local/share/iw/plugins/kanon/lib/batch/ForgeCatchUp.scala:143:7
[error] Found:    Either[iw.core.model.TrackerError, Option[batch.ForgeState]]
[error] Required: Either[String, Option[batch.ForgeState]]
Compilation failed

Implement: needs-human Reason: batch-implement exit 1 — the kanon plugin did not compile against this worktree's iw-cli core, so no phase ran `batch-implement` stopped before it wrote `batch-implement.log`. The lines below are its console output. The installed kanon plugin (`lib/batch/ForgeCatchUp.scala:143`) expects `Either[String, …]` from `tracker.fetchPullRequestForBranch`. iw-cli `main` (#778–#780) changed the tracker port to return `Either[TrackerError, …]`. This failure is not specific to this issue: every `batch-implement` in iw-cli fails the same way until the plugin follows the port change. ``` [error] /home/mph/.local/share/iw/plugins/kanon/lib/batch/ForgeCatchUp.scala:143:7 [error] Found: Either[iw.core.model.TrackerError, Option[batch.ForgeState]] [error] Required: Either[String, Option[batch.ForgeState]] Compilation failed ```

claude added

needs-human

and removed

agent-ready

labels

2026-10-15 21:28:24 +00:00

claude commented

2026-10-16 17:10:35 +00:00

Author

Member

Release: the implement loop failed this issue for a reason outside it. The kanon plugin did not compile against iw-cli main, because the tracker port now returns TrackerError (iw-cli #778). The plugin fix is dev-docs #484, and iw-cli 0.22.1 carries the core change. The issue goes back to the implement loop.

claude added

agent-ready

and removed

needs-human

labels

2026-10-16 17:10:35 +00:00

Rows
Columns

phase-pr and ci-gate write the ci_pending card from two hand-copied definitions #568