Idea: Runtime-Compatible Review Monitoring for Implement Feature

[alemar11]

Summary

Make Implement Feature's pending PR-review lifecycle depend only on runtime capabilities that are formally exposed to agents, without silently assuming Goal pause/resume or task-targeted heartbeat APIs.

Problem or Opportunity

The current runtime gate requires first-class Goal active -> paused -> active transitions and heartbeat automation that can wake the exact root task. In the currently exposed App tool surface, Goal updates support only terminal completion or blocking, and no matching heartbeat automation is available. As a result, otherwise valid Feature Spec execution stops as unsupported-runtime before authorization and intake.

Proposed Direction

Explore a supported monitoring contract that preserves the same root, worker task, managed worktree, claim, and PR-revision identity while a mandatory Codex review remains pending. The direction may use formally exposed pause/wake primitives or a safe fallback, but it must not pretend that due_at alone schedules work or imitate suspension with blocked, replacement Goals/tasks, raw RPC, or unmanaged cron.

Expected Value

Allow Implement Feature to handle asynchronous PR-review delays safely on the App runtime that agents can actually control, while preventing duplicate polling, abandoned ownership, and false merge-ready results.

Known Context and Constraints

• This concerns a review that remains pending after the fixed active-wait deadline, not actionable review findings; findings return the worker to fix, validate, push, and request a new current-revision review.
• Monitoring must preserve task, worktree, claim, and revision identity across suspension or continuation.
• Pending review monitoring is nonterminal and must not be recorded as the terminal merge handoff.
• The workflow must not merge or enqueue a pull request.
• Missing runtime capability must remain explicit; the workflow must not claim a durable wake mechanism that it cannot prove.

Open Questions

• Can the App expose first-class targeted Goal pause/resume and heartbeat create/view/update/delete operations to agents?
• If those APIs remain unavailable, which controller stays active and how is the next review check triggered durably?
• Should a verified manual-resume path be supported, or should the workflow continue to return unsupported-runtime?
• Can claim retention remain safe during a potentially long pending-review interval without an automated heartbeat?

Source

• Repository discussion on 2026-07-18 about the Implement Feature review-monitoring runtime gate.
• skills/implement-feature/SKILL.md
• skills/implement-feature/references/review-monitoring.md
• skills/implement-feature/references/codex-review-closeout.md