Remedy Blueprint

When a user starts Remedy, Critique constructs a blueprint — a structured execution plan that constrains what the coding agent can do. The blueprint is the mechanism that makes Remedy bounded rather than open-ended.

Blueprint structure

version: '2026-03-23'

repository    — owner, name, fullName
pullRequest   — number, title, headSha, headRef, baseSha, clone URL
review        — verdict, summary, body, strictness

execution:
  maxLoops                    — 2 (hardcoded)
  allowedWriteFiles           — explicit list of files the agent may modify
  suggestedValidationCommands — commands to run after patching
  goals                       — what the agent is trying to accomplish
  stopConditions              — when the agent must stop
  operatorInstructions        — optional human-provided guidance

findings      — structured findings from the review run
prompt        — the fully assembled system prompt

Goals

Goals are built from the review findings:

• If there are findings: up to 6 findings are mapped to goals — "Address {severity} finding \"{title}\" in {filePath}."
• If there are no findings: two cautious goals are generated:
  1. "Review the existing artifact and confirm whether a code change is necessary before editing anything."
  2. "If no safe fix is justified, stop and return a human handoff instead of making speculative edits."
• If operatorInstructions is set, a prefixed goal is prepended: "Follow this operator request: {instructions}".

Allowed write files

The write scope is derived from the review:

• If findings have file paths: allowed files = finding file paths + related test files.
• If no finding paths exist: allowed files = up to 12 evidence files + up to 12 related test files.
• All paths are deduplicated.

The agent is explicitly told it cannot modify files outside this list. If a fix requires broader changes, the agent must stop and return a human handoff.

Validation commands

Validation commands are added based on the evidence:

1. If any evidence file ends in .ts, .tsx, .js, or .jsx → npm test
2. Always: npm run lint
3. Always: npm run build

Commands are deduplicated and trimmed.

Stop conditions

Four hardcoded stop conditions:

1. Stop when all targeted findings are resolved and validation passes.
2. Stop immediately if the required fix exceeds the allowed write scope.
3. Stop after the second failed execution loop and return a human handoff.

Prompt assembly

The blueprint prompt is a single string with these sections in order:

1. Identity: "You are Remedy, the execution layer for Critique."
2. Context: Repository full name, PR number.
3. Task: "Apply the smallest safe fix that resolves the review findings without widening scope."
4. Operator instructions: Verbatim or "n/a".
5. Review summary: Verbatim or "n/a".
6. Findings list: Each finding as - [{SEVERITY}] {title} @ {filePath}:{startLine}: {summary}, or a fallback message if none.
7. Allowed write scope: Bulleted file paths.
8. Validation commands: Bulleted commands.
9. Constraints:
   • Stop after at most 2 execution loops.
   • Prefer modifying existing files over introducing new architecture.
   • If the fix requires broader repo surgery or unclear product decisions, stop and return a human handoff.
   • Do not touch unrelated files.
10. Reference review body: The full review body or "n/a".

Execution backends

The backend determines the RemedyRunnerDescriptor:

Execution lifecycle

Remedy emits events as it progresses:

sandbox-created → repo-cloned → prompt-started → patch-produced
  → validation-started → validation-passed / validation-failed
  → validation-retrying (up to maxLoops)
  → committed → pushed → completed

If something goes wrong: scope-rejected, push-failed, or halted.

Each event includes a phase, status (running / completed / failed), detail, and createdAt.

Execution result

When Remedy finishes, it produces: