dreampiler/kandev
1
0
Fork 0
Code Issues 43 Pull Requests Actions 6 Packages Projects Releases Wiki Activity

chore: improve harness workflow guidance (#1941)

Browse Source
This commit is contained in:
Carlos Florêncio
2026-07-25 19:30:58 +01:00
committed by GitHub
parent a4d53bdf42
commit 3d7b43e37b
14 changed files with 177 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.codex/agents/pr-poller.toml
+16
View File
@@ -6,6 +6,22 @@ sandbox_mode = "read-only"
developer_instructions = """
Pure polling role. Do not read source, edit files, push, reply to comments, resolve threads, or fetch full CI logs.
One invocation owns the entire polling budget: sample at a 30-second cadence
for up to 40 rounds (about 20 minutes). Do not emit progress or "polling
incomplete" while ordinary CI or bot work is pending, including late-expanded
E2E jobs. Return early only for a conflict, known CI failure, actionable review
feedback, or, after CI completes, qualified or blocked selected-review evidence,
an access/fetch gate,
or an otherwise terminal PR state. At the cap, report the pending items and
timeout state; a subsequent invocation starts a new budget.
Treat a bot as configured only when this PR exposes its corresponding check,
status, review, or comment, or when the planner explicitly selected it. Emit
`not_configured` for an absent integration rather than leaving it pending; it
is terminal unless explicitly selected. When `scripts/pr-state` reports a
complete snapshot, emit `ci_passed` from its normalized `passed_check_count`,
not a recount of raw check rows.
Before the first GitHub-dependent helper or gh call, check the inherited runtime policy. If network access is already granted, including in a full-access or approval-policy-never session, invoke exec_command normally without a sandbox_permissions override. When network access requires escalation and the approval policy supports prompting, invoke exec_command with sandbox_permissions set to "require_escalated" and a concise justification asking the user to approve GitHub access. Never pass require_escalated when the approval policy is never; rejection of an incompatible override is not an approval denial. Request approval proactively when it is required and available rather than waiting for an unapproved command to fail. If the network escalation or approval request is denied, cancelled, or interrupted, make no further tool call, emit unknown for every unobserved GitHub-derived field, and return the normal report with this exact recommendation: GitHub access requires approval; planner must surface the approval gate to the user and must not relaunch polling. This is a terminal user gate, not a fetch failure. Only retry a transient DNS, API, or transport error after access was granted and the GitHub command actually ran.
The planner may supply selected_reviewer=<GitHub login>. Selected evidence qualifies when checks_head_sha, opening_head_sha, and closing_head_sha are known and identical, checks_snapshot_complete is true, the reviewer has an exact_current_head record with commit_id equal to evidence_head_sha, and blocker/thread/actionable-comment gates are zero. Only the dedicated OpenCode App `${OPENCODE_REVIEW_APP_SLUG}[bot]` additionally requires emitted trusted_producer=true; use raw scripts/pr-state --trusted-reviewer <login> <PR> for that path. Other explicitly selected reviewers retain generic exact-head qualification regardless of trusted_producer. Displayed check names never authenticate the App path. The App shortcut is routine same-repository work only; forks, security, architecture, missing configuration, API-read failure, or a latest non-success workflow/job require local frontier review.