GitHub GH-600: Prepare agent architecture and SDLC processes Practice Questions

A configurable auto-approval timeout with on-call notification enables human intervention without indefinitely blocking the pipeline — reviewers can act quickly when needed, and delivery proceeds automatically when no issues are flagged. A '/reject' command mechanism gives reviewers an active, low-friction way to halt execution asynchronously without requiring synchronous presence. A 'dead man's switch' (explicit '/approve' required within a window) is another valid pattern that defaults to safe blocking but doesn't require 24/7 coverage if the window is reasonable. A mandatory synchronous approval with no timeout directly contradicts the requirement not to block delivery for hours. Persisting the plan to a GitHub Release is useful for archiving but does not by itself provide an intervention mechanism. Skipping validation eliminates a critical safety gate and is directly contrary to the goal.

Producing a structured plan artifact before execution creates an inspectable record of what the agent intends to do, enabling human reviewers to assess risk before any side effects occur. It also enforces the architectural boundary between planning (reasoning) and execution (action), a core SDLC integration principle. It does not eliminate the need for testing — plans can be incorrect or incomplete. It does not guarantee plan correctness; human review is required precisely because plans can be wrong. Token caching is unrelated to this workflow design. Allowing the agent to self-approve defeats the purpose of the approval gate.

If the agent silently revises its plan mid-execution, the approved plan artifact no longer matches what was actually done, breaking the audit trail and making traceability impossible. Additionally, humans approved a plan that described different actions than were executed — they have implicitly 'approved' unapproved actions, creating a compliance and governance gap. Runner minute overuse is a cost concern unrelated to plan divergence. Context window exhaustion is a technical performance concern, not a governance risk introduced by silent replanning. GitHub Actions has no native mechanism to detect plan divergence automatically — that assertion is a misconception.

The agent performs high-impact actions — assigning work to humans and writing code — without any approval gate between planning (triage/labeling) and execution (code generation). This is the anti-pattern of overly broad action scope without human checkpoints at action boundaries, which risks cascading unintended consequences. Insufficient observability and failure to log are also concerns in agentic systems, but neither is the primary anti-pattern illustrated — the scenario does not mention logging gaps. Underutilization of structured output relates to plan format, not to the autonomous action boundary problem described.

Requiring the agent to open a PR with a machine-readable plan, enforced by branch protection required-reviewer rules and blocked auto-merge, gives the agent autonomy to prepare changes while guaranteeing a human approval gate before merge — the correct balance. Committing directly to main with a retrospective notification provides no pre-merge oversight. Disabling branch protection eliminates the control plane entirely and weekly log audits are reactive, not preventive. A confidence-score bypass is a common misconception; model confidence is not a reliable proxy for correctness or safety and bypasses the oversight requirement.