frontier-plan-opencode-executor

Frontier Plan OpenCode Executor

Core Principle

The frontier plan is a strong hypothesis, not ground truth.

Execute the intent of the plan step by step, but validate every instruction against the actual repository before editing code. Frontier AI plans frequently fail on: nonexistent file names, invented imports, unavailable libraries, patterns that don't match the repo, missing tests, idealized architecture, and breaking internal APIs.

Never batch large changes. Never skip verification. Never hide uncertainty. Never perform destructive actions without explicit approval.

When to Use

• You receive a detailed, multi-step implementation plan written by a frontier AI
• The plan has 3+ distinct steps with specific file paths and code patterns
• You are using a non-frontier coding model that benefits from execution discipline
• The plan carries risk of conflicting with the actual codebase

Do NOT use for:

• Single-file changes or trivial fixes
• Plans with only 1-2 simple steps
• Plans you wrote yourself during the same session
• Rapid iteration where the user wants speed over safety

Core Workflow

0. PREFLIGHT: Establish Repository Baseline

Before touching any file, understand the repo state and detect pre-existing failures.

1. git status --short          # Is the repo clean?
2. Inspect package.json         # Available scripts, dependencies
3. Inspect AGENTS.md, README.md # Project conventions, commands
4. Detect available verification commands from package.json scripts
5. Run the cheapest baseline verification if available (lint or typecheck)

If baseline already fails:

• Record the failure explicitly: exact command, exit status, and short error summary
• Do NOT attempt broad cleanup or fix unrelated issues
• Continue only if the planned change can be isolated from the existing failure
• Do not attribute pre-existing failures to your implementation

Dangerous state detection:

• If git status shows uncommitted changes unrelated to the plan, warn the user
• If lockfiles are modified, warn the user
• If the repo is in a conflicted/rebasing state, stop and ask