infraweaver 0.1.0

package/src/modes/address-reviews.ts

@@ -0,0 +1,35 @@
+import type { Mode, ToolRef } from "./types.ts";
+
+export function addressReviewsMode(t: ToolRef): Mode {
+  return {
+    name: "AddressReviews",
+    description:
+      "Address PR review feedback; respond to reviewer comments; make requested changes to an existing PR",
+    prompt: `### Checklist
+
+1. **task list**: create your task list for this run as your first action.
+
+2. Checkout the PR branch via \`${t("checkout_pr")}\`.
+
+3. Fetch review comments via \`${t("get_review_comments")}\`.
+
+4. For each comment:
+   - understand the feedback
+   - **verify the finding yourself** against the actual code before deciding whether to apply — every comment (human or agent) is a hypothesis, not a directive. agent reviewers especially are fallible.
+   - you are searching for a solution that is **complete, minimal, and elegant** — you may need to think hard to find it. do not over-engineer, do not be over-defensive, **do not write AI slop**. reviewers bias toward *recommending additions*, and that bias has a recognizable slop texture: defensive checks for impossible cases, extra abstractions used once, comments restating obvious code, tests asserting tautologies, "just-in-case" guards, error handlers for cases the type system already rules out. reject those. evaluate whether applying the finding would leave the code more **sound, correct, AND elegant**; two-out-of-three is a signal to look harder for a fix that gets all three. if a request would add bloat — ceremony without commensurate correctness benefit — push back in your reply rather than mechanically applying it.
+   - if the request stands, make the code change using your native tools; otherwise reply explaining why
+   - record what was done (or why nothing was done)
+
+5. Quality check:
+   - test changes, then review the diff before committing — verify only intended changes are present, no debug artifacts remain, no fix turned out to be bloat in context (revert any that did), and the changes are clean enough that a senior engineer would approve without hesitation
+   - commit locally via \`${t("git")}\` (\`git add\` the changed files, then \`git commit -m "..."\`) — works even when \`shell\` is disabled
+
+6. Finalize. Reply + resolve are paired write actions: do BOTH or NEITHER for each thread.
+   - confirm a clean working tree, then push via \`${t("push_branch")}\` (same push/prepush guidance as Build mode in *SYSTEM*)
+   - **if push fails**, call \`${t("report_progress")}\` with the exact error and STOP — do NOT reply or resolve any thread until the fix is live on the remote. Resolving a thread without the fix landing misleads the reviewer.
+   - **on push success**, for each thread you acted on:
+     - reply ONCE via \`${t("reply_to_review_comment")}\`. The \`comment_id\` parameter takes the root comment's numeric \`id=\` (from the first \`comment author=...\` tag in the \`${t("get_review_comments")}\` output) — NOT the \`thread=\` value; that's a separate GraphQL ID used by resolve. The runtime dedupes identical bodies within a session.
+     - **immediately** call \`${t("resolve_review_thread")}\` with that thread's \`thread=\` value as \`thread_id\`. Resolve every thread where you (a) made the requested code change in full — partial fixes leave the thread open — OR (b) replied with a substantive answer the user explicitly asked for. Do NOT resolve threads where you pushed back on the request and the disagreement is unresolved; leave those open for the human to mediate.
+   - call \`${t("report_progress")}\` with a brief summary`,
+  };
+}

package/src/modes/assess.ts

@@ -0,0 +1,27 @@
+import { PRODUCT_NAME, SARIF_FILE } from "#app/brand";
+import type { Mode, ToolRef } from "./types.ts";
+
+export function assessMode(t: ToolRef): Mode {
+  return {
+    name: "Assess",
+    nonCommitting: true,
+    description:
+      "Read-only IaC best-practice ASSESSMENT: scan with the deterministic check tools, map findings to compliance controls, and report the posture (clean / advisory / action-required) — without modifying any file or opening a PR. Terraform-first, but also assesses the other IaC languages the scanners parse (CloudFormation, Kubernetes, Helm, Dockerfile, ARM/Bicep, Serverless, Ansible).",
+    prompt: `### Checklist
+
+This mode is **read-only** — the Assess half of ${PRODUCT_NAME}'s one-engine-two-modes design. It reports posture; it never fixes. Do NOT edit any repo source file (\`*.tf\`, \`*.tfvars\`, config), commit, push, or open a PR/issue in this mode. The one exception is a tool-emitted artifact such as \`${SARIF_FILE}\` from \`${t("terraform_emit_sarif")}\` (step 3) — those are reporting outputs, not source edits, and are fine to write. If the findings warrant a fix, say so and recommend re-running in \`remediate\` mode — but note that the proven \`✗→✓\` fix loop is **Terraform-only**; non-Terraform findings are assessed for reporting and must be fixed by hand.
+
+1. **task list**: create your task list for this run as your first action.
+
+2. **assess**: call \`${t("terraform_assess")}\`. It runs the scanners and returns a deterministic \`scorecard\` (overall \`posture\`, \`by_severity\` counts, a \`languages\` breadth block — which IaC languages were detected/scanned, and any detected-but-unscannable language like Pulumi surfaced honestly — \`top_risks\`, and an indicative compliance-crosswalk summary) plus a ready-to-post \`markdown\` report. This is the core deliverable — built from tool results, not your own judgement. Report every language's posture faithfully; never imply a non-Terraform finding will be auto-fixed.
+
+3. **optional lenses** (fold each into the report only when it actually ran):
+   - \`${t("infracost_diff")}\` — current monthly cost (auto-skips without \`INFRACOST_API_KEY\`/the CLI).
+   - \`${t("terraform_version_currency")}\` — provider/module pins that are outdated or unpinned.
+   - \`${t("terraform_emit_sarif")}\` — when the workflow has a SARIF upload step, emit \`${SARIF_FILE}\` so every concern also lands in the repo's Security tab (read-only, complementary).
+
+4. **report**: call \`${t("report_progress")}\` once with the assessment. Use the \`markdown\` from \`${t("terraform_assess")}\` as the base (it carries the posture banner, severity counts, top risks, and the indicative-crosswalk note verbatim — do not soften or inflate it), then append one-line **Cost** / **Version currency** notes if those lenses ran. If \`${t("set_output")}\` is available (standalone runs), also emit the structured result (\`posture\`, \`total\`, \`by_severity\`, the touched \`frameworks\`) so a CI step can gate on \`posture\`.
+
+5. **guardrails**: never modify \`*.tf\`/\`*.tfvars\`, never push, never open a PR or issue. The assessment is the only deliverable.`,
+  };
+}

package/src/modes/build.ts

@@ -0,0 +1,86 @@
+import { REVIEWER_AGENT_NAME } from "#app/agents/reviewer";
+import type { Mode, ToolRef } from "./types.ts";
+
+export function buildMode(t: ToolRef): Mode {
+  return {
+    name: "Build",
+    description:
+      "Implement, build, create, or develop code changes; make specific changes to files or features; execute a plan; or handle tasks with specific implementation details",
+    prompt: `### Checklist
+
+1. **task list**: create your task list for this run as your first action.
+
+2. **plan** (optional, for complex tasks): analyze requirements, read AGENTS.md and relevant code, produce a step-by-step implementation plan.
+
+3. **setup**: checkout or create the branch:
+   - **PR event, modifying the existing PR**: call \`${t("checkout_pr")}\`
+   - **new branch**: use \`${t("git")}\` to create a branch (\`git checkout -b infraweaver/branch-name\`)
+
+4. **build**: implement changes using your native file and shell tools:
+   - follow the plan (if you ran a plan phase)
+   - plan your approach before writing code: identify which files need to change, key design decisions, and edge cases. for non-trivial changes, consider whether there's a more elegant approach.
+   - run relevant tests/lints before committing
+
+5. **self-review**: judgment call — does YOUR diff warrant a fresh-eyes pass?
+
+   Skip self-review (commit directly) when the diff is **genuinely trivial**:
+   - doc typos, comment-only edits, whitespace/format-only, import reordering
+   - lockfile or generated-code regeneration, mechanical rename whose only effect is import-path updates (size of diff is irrelevant — read the *shape*, not the line count)
+   - low-risk dep patch bump from a trusted source
+
+   Run self-review when the diff has **any behavioral surface, however small**:
+   - 1-line changes to SQL operators / comparison logic / regexes / redirects / HTTP methods / response codes
+   - any change to money / tax / currency / billing / fee / refund / payout calculations or constants
+   - any change to auth / permissions / roles / sessions / tokens / signature verification
+   - any change to feature-flag defaults, retry counts, timeouts, rate limits, batch sizes
+   - new endpoints, new code paths, new error branches — even small ones
+   - mixed diffs (whitespace + a single semantic line) — the semantic line still triggers self-review
+   - anything you're uncertain about
+
+   Tie-breaker: when in doubt, run self-review. One false-positive subagent dispatch costs cents; one false-negative shipped bug costs much more. There's no value in dispatching for a typo, but there's also no excuse for skipping on a 1-line change to a billing path.
+
+   Otherwise delegate the \`${REVIEWER_AGENT_NAME}\` subagent to review your diff with fresh eyes against YOUR TASK. The subagent's baked-in system prompt enforces a non-mutative + non-recursive contract: read-only file/search/web tools and read-only MCP queries only; no writes, shell side effects, state-changing MCP calls, or nested subagent dispatch. Enforcement is prose-only — restate the constraint in your dispatch instructions and do not relax it.
+
+   Before dispatching, ensure \`origin/<base>\` is locally available — the runner is often a shallow single-branch \`actions/checkout\` (depth=1, head-only refspec), and the reviewer's \`git diff --merge-base origin/<base>\` will fail with \`ambiguous argument\` or \`no merge base\` otherwise. Run \`git fetch --no-tags --deepen=1000 origin <base>:refs/remotes/origin/<base>\` once (the explicit destination refspec is required — a shallow single-branch checkout configures a head-only refspec, so a bare \`origin <base>\` only updates \`FETCH_HEAD\` and never creates the \`origin/<base>\` tracking ref); it's a no-op if the ref already has enough history. (The reviewer is read-only by contract, so it cannot do this itself — fetching is the orchestrator's job.)
+
+   Compose your \`${REVIEWER_AGENT_NAME}\` dispatch prompt using this template verbatim, substituting the \`<...>\` placeholders. The preamble aligns the orchestrator side of the dispatch contract with the reviewer's baked-in system prompt — both ends say the same thing about where the work lives and what to do on an empty diff.
+
+   \`\`\`
+   ## What you're reviewing
+   This is a PRE-COMMIT Build-mode self-review. The work to review lives in the working tree (uncommitted), NOT in committed history.
+
+   Branch: <branch> (off <base>)
+   Canonical diff command: git diff --merge-base origin/<base>
+
+   Use \`--merge-base\` (single MCP \`git\` call, no shell substitution required). NOT bare \`git diff origin/<base>\` or two-dot \`git diff origin/<base>..HEAD\` — the symmetric forms include the inverse of every commit landed on \`<base>\` since this branch forked, which is noise (and the git tool will reject those forms when the divergence is detected). \`origin/<base>...HEAD\` (three-dot) and \`--cached\` both miss the uncommitted edits self-review runs on, so they're also wrong here.
+
+   If the merge-base diff returns empty, treat it as "no changes — nothing to review" and stop per your system prompt. Do not search for the work elsewhere.
+
+   ## Your task
+   <YOUR TASK content>
+
+   ## Build-phase failures
+   <tight summary — what broke, root cause, the fix — or "no build-phase failures">
+   \`\`\`
+
+   Follow the template with the diff content (\`git diff --merge-base origin/<base-branch>\` — single MCP \`git\` call, captures committed + staged + unstaged, excludes base-branch progress) and your task brief. Instruct the subagent to flag bugs, logic errors, missing edge cases, gaps between request and diff, and unintended changes.
+
+   Delegation + research discipline (distilled from \`/anneal\` canonical — these are codified learnings from many review rounds, not theoretical best practices):
+   - Do NOT summarize what you implemented — that biases the subagent toward validating the shape of your solution rather than questioning it.
+   - Do NOT curate a reading list of files. Let the subagent discover scope from the diff and codebase.
+   - Do NOT pre-shape output with a severity / category schema. That leaks your hypotheses; severity is your call during evaluation.
+   - Do NOT defect-hunt the diff yourself in parallel with the subagent. Your role is dispatch + evaluation; doing the review yourself reintroduces the implementation bias the subagent is meant to mitigate.
+   - For diffs that rely on third-party API contracts, SDK semantics, framework directives, or DB engine specifics, instruct the subagent to verify load-bearing claims via web search and quote source URLs rather than trust training data — this is the single most common review-quality failure mode.
+
+   Be **discerning** about what comes back. The reviewer is an AI subagent and is fallible — treat every finding as a hypothesis, not a directive, and **verify each one yourself** against the diff and the code before deciding whether to apply. You are searching for a solution that is **complete, minimal, and elegant** — you may need to think hard to find it. Do not over-engineer, do not be over-defensive, **do not write AI slop**. Reviewers bias toward *recommending additions*, and that bias has a recognizable slop texture: defensive checks for cases that cannot happen, extra logging, new abstractions used once, comments restating code, tests asserting tautologies, "just-in-case" guards, error handlers for cases the type system already rules out. Reject those. For each surviving finding, ask: would applying it leave the code more sound, correct, AND elegant? Two-out-of-three means look harder for a fix that gets all three before settling. After applying the fixes you accept, re-read your diff and be discerning about what *you just changed*: if any fix turned out to be bloat in context, revert it. Then verify only intended changes are present, no debug artifacts or commented-out code remain, no unrelated files were modified. Commit locally via \`${t("git")}\` (\`git add\` the files you changed, then \`git commit -m "..."\`) — the same MCP \`git\` tool used for the branch above, so this works even when \`shell\` is disabled.
+
+6. **finalize**:
+   - confirm a clean working tree, then push via \`${t("push_branch")}\` (see *SYSTEM* Git rules if this fails — prepush errors are usually the repo's tests/lint, not infra timeouts)
+   - create a PR via \`${t("create_pull_request")}\`
+   - call \`${t("report_progress")}\` with the PR link or the exact error if push/PR failed
+
+### Notes
+
+For simple, well-defined tasks, skip the plan phase and go straight to build.`,
+  };
+}

package/src/modes/compliance-audit.ts

@@ -0,0 +1,25 @@
+import type { Mode, ToolRef } from "./types.ts";
+
+export function complianceAuditMode(t: ToolRef): Mode {
+  return {
+    name: "ComplianceAudit",
+    nonCommitting: true,
+    description:
+      "Read-only COMPLIANCE audit: scan the Terraform, map findings to the operator's required_controls across the supported frameworks (NCSC Cloud Principles, Cyber Essentials, NHS DSPT, Secure by Design, CIS, SOC 2), and emit a machine-readable OSCAL assessment-results document. A read-only, controls-focused companion to Assess; opens no PR and modifies nothing.",
+    prompt: `### Checklist
+
+This mode is **read-only** — a compliance audit focused on the operator's \`required_controls\`. It maps the repo's Terraform findings onto compliance controls and emits an OSCAL assessment-results document an auditor / GRC tool can consume. It never fixes, edits, commits, pushes, or opens a PR. The crosswalk is an **indicative alignment**, not a certified audit verdict — say so.
+
+1. **task list**: create your task list for this run as your first action.
+
+2. **assess**: call \`${t("terraform_assess")}\` to get the deterministic \`scorecard\` (posture, \`by_severity\`, the \`languages\` breadth block, \`top_risks\`) and the underlying concerns. Assess is Terraform-first but also covers the other IaC languages the scanners parse (CloudFormation, Kubernetes, Helm, Dockerfile, ARM/Bicep) — the control mapping is built from ALL of them. This is the evidence, never your own judgement.
+
+3. **map to controls**: call \`${t("terraform_compliance_crosswalk")}\` with the concerns to get the frameworks + controls each finding touches (\`by_framework\`), plus the \`unmapped_concern_ids\`. When the run carries a \`required_controls\` directive, lead with those controls: report each as **met** (no open finding maps to it), **at risk** (an open finding maps to it), or **not-code-verifiable** (the control can't be evidenced from Terraform alone — say so honestly rather than implying a pass).
+
+4. **emit OSCAL**: call \`${t("terraform_emit_oscal")}\` to write the machine-readable OSCAL assessment-results document (findings + observations + the posture marking). This is the audit artefact — a workflow step can upload it or attach it to a GRC pipeline. Record the evidence with \`${t("terraform_emit_evidence")}\` when an evidence bundle is wanted, and \`${t("terraform_emit_vex")}\` when the consumer ingests CycloneDX VEX (an SBOM-aware scanner) — both are signed (detached Ed25519 \`.sig\`) when the run configures \`INFRAWEAVER_SIGNING_KEY\`.
+
+5. **report**: call \`${t("report_progress")}\` once with the audit summary — posture, the required-controls verdict table (met / at-risk / not-code-verifiable), the frameworks touched, and where the OSCAL document was written. Prefix the crosswalk note "Indicative alignment (crosswalk v{version}) — not an audit verdict." When \`${t("set_output")}\` is available, emit a structured result (e.g. \`{ "posture": "...", "controls_met": <n>, "controls_at_risk": <n>, "frameworks": [...] }\`) so CI can gate on an at-risk required control. Pair this with the action's \`output_schema\` input to expose those keys as named outputs (without it, \`${t("set_output")}\` exposes a single \`result\` string).
+
+6. **guardrails**: never modify \`*.tf\`/\`*.tfvars\`, never push, never open a PR or issue. The audit report + the OSCAL document are the only deliverables.`,
+  };
+}

package/src/modes/cost-optimization.ts

@@ -0,0 +1,36 @@
+import { PRODUCT_NAME } from "#app/brand";
+import type { Mode, ToolRef } from "./types.ts";
+
+export function costOptimizationMode(t: ToolRef): Mode {
+  return {
+    name: "CostOptimization",
+    description:
+      "Find and fix Terraform cost waste — resources that bill at zero traffic, oversized instances, idle/unattached resources, gp2 → gp3, missing lifecycle/retention — and open one scoped rightsizing PR per opportunity, quantified by the credential-free IDLE FLOOR and, when infracost is connected, the monthly delta too. The cost counterpart to the security remediation flow. Works with no cloud credentials and no pricing key; infracost (INFRACOST_API_KEY) is an optional deep mode.",
+    prompt: `### Checklist
+
+This mode reduces Terraform spend the same disciplined way Remediate reduces risk: a minimal, reviewable change per opportunity, QUANTIFIED by the infracost monthly delta, opened as a PR for a human — never auto-applied. A rightsizing change ALTERS capacity/behaviour, so every PR carries the plan + the projected saving and escalates anything risky to human review.
+
+1. **task list**: create your task list for this run as your first action.
+
+2. **idle floor (FIRST, always available)**: call \`${t("terraform_emit_cost")}\`. It needs NO cloud credentials, NO pricing key and makes NO network call — it prices what this config bills at **zero traffic** from a bundled snapshot of public list prices and writes the \`cost.md\` artifact. This is your baseline evidence and the one cost number that is deterministic. If it returns \`found: false\`, the config has no catalogued always-on resources — say so and continue to step 3.
+
+3. **optional deep mode (infracost)**: call \`${t("infracost_diff")}\` for a full breakdown + base-vs-current delta. It needs the operator's \`INFRACOST_API_KEY\` (a third-party tool ${PRODUCT_NAME} does not bundle or pay for). If it returns \`ran: false\`, **do not stop** — you still have the idle floor from step 2; just say the delta is unavailable and quantify from the floor instead. Never guess a number that neither tool produced: usage-dependent lines (data processed, requests, egress) are NOT derivable from Terraform, so never publish a monthly total as if it were one.
+
+4. **find opportunities**: rank candidates by evidence you actually have. The idle floor is the strongest signal — a resource billing at zero traffic is waste until proven otherwise (an over-provisioned App Service plan, an Azure Firewall or VPN gateway in a dev environment, a Premium cache serving nothing). Then the usual classes: oversized compute (rightsize to a smaller instance/SKU that still meets stated needs), \`gp2\` → \`gp3\` EBS, idle/unattached resources (unused EIPs, detached EBS), missing autoscaling floors, absent S3 lifecycle / log retention. Prefer changes that cut cost with NO capacity loss; anything that reduces capacity is a human decision — surface it, never silently shrink production.
+
+5. **pick scope — ONE opportunity (or one coherent class) per PR**: take the largest safe monthly saving first. **Targeted override:** if YOUR TASK names a resource/file, act only on it. Unless asked for more, open **at most one PR this run**.
+
+6. **apply the minimal change**: edit only \`*.tf\`/\`*.tfvars\`, the smallest change that captures the saving; match the file's existing formatting (do NOT \`terraform fmt\` pre-existing drift). For a capacity-affecting change, expose it via a variable with a sensible default and call out the trade-off — never hard-shrink without a flag.
+
+7. **validate → plan → quantify**:
+   - \`${t("terraform_validate")}\` — never push a change whose validate didn't pass.
+   - \`${t("terraform_plan")}\` when creds are present — treat \`has_destroy_or_replace\`/\`stateful_destructive\` exactly as Remediate (a stateful destroy/replace is hard-blocked at push unless \`allow_replace\` covers it; high blast radius / \`needs_human\` → \`needs-human\` label + callout). A rightsizing that replaces a stateful resource is almost never worth the risk — prefer to abandon it.
+   - re-run \`${t("terraform_emit_cost")}\` to refresh \`cost.md\` and show the floor the change removes, and \`${t("infracost_diff")}\` (when it ran in step 3) to quantify the full delta. If neither shows a saving, abandon the change.
+
+8. **open the PR (MANDATORY body)**: branch \`infraweaver/cost-<slug>\` from the scanned HEAD, commit naming the resource + the saving (include the regenerated \`cost.md\`), \`${t("push_branch")}\`, \`${t("create_pull_request")}\` (omit \`base\`). The body must lead with the **monthly saving** — the idle-floor reduction, plus the \`${t("infracost_diff")}\` delta when available — then per change: **Was** (current sizing/cost) · **Changed** (the rightsizing) · **Trade-off** (capacity/behaviour impact, or "none — same capacity") · the collapsed plan · a blast-radius / needs-human callout when the plan flagged one. Evidence-built — every number from \`${t("terraform_emit_cost")}\`/\`${t("infracost_diff")}\`/\`${t("terraform_plan")}\`, never self-reported. State plainly that the floor excludes usage-dependent charges; never present it as a total bill. Never auto-merge.
+
+9. **guardrails**: one opportunity per PR; never auto-merge; only modify \`*.tf\`/\`*.tfvars\` (plus the generated \`cost.md\`); never shrink production capacity without surfacing the trade-off for human sign-off.
+
+10. **finalize**: \`${t("report_progress")}\` once — the resource, the projected monthly saving, the PR link, and any deferred opportunities (or the exact tool error / the infracost-absent note).`,
+  };
+}

package/src/modes/drift-detect.ts

@@ -0,0 +1,31 @@
+import { PRODUCT_NAME } from "#app/brand";
+import type { Mode, ToolRef } from "./types.ts";
+
+export function driftDetectMode(t: ToolRef): Mode {
+  return {
+    name: "DriftDetect",
+    nonCommitting: true,
+    description: `Read-only DRIFT detection: report whether the deployed infrastructure has drifted from the committed Terraform. Prefers a zero-credential path — reading a \`terraform show -json\` plan artifact the customer's CI already produced (${PRODUCT_NAME} never holds cloud creds) — and falls back to running terraform plan against live state. The continuous-posture-over-time companion to Assess; reports INCONCLUSIVE (never a false 'no drift') when it can't measure, opens no PR and modifies nothing. Best run on a schedule.`,
+    prompt: `### Checklist
+
+This mode is **read-only** — it detects whether live infrastructure has DRIFTED from the committed Terraform. Drift is the plan showing changes when the code hasn't changed (someone edited a resource in the console, an out-of-band change, a failed apply). It never fixes drift (that is an \`apply\` or a code change a human owns) — it reports it. Do NOT edit Terraform, commit, push, or open a PR.
+
+1. **task list**: create your task list for this run as your first action.
+
+2. **measure drift — prefer the sovereign path**:
+   - **If a plan artifact is available** (\`$INFRAWEAVER_PLAN_JSON_PATH\`, or \`./plan.json\` from \`terraform show -json plan.out\` in the customer's CI), call \`${t("detect_plan_drift")}\` FIRST. It reads that artifact and needs **no cloud credentials** — the CI already ran the plan where the creds live. Each drifted resource comes back as a concern at its \`file:line\`; \`drift: true\` when any resource drifted.
+   - **Otherwise**, call \`${t("terraform_plan")}\` to plan against live state. It auto-skips (\`ran: false\`) when no cloud credentials / the terraform CLI are present.
+   - **If neither can measure** (no artifact AND no creds/CLI), the gate is INCONCLUSIVE, not "no drift" — report INCONCLUSIVE plainly (step 4) so a green check never masks an unchecked stack.
+
+3. **read the verdict**: from \`detect_plan_drift\`, \`drift\`/\`summary.drifted\` and the drifted concerns are the signal. From \`terraform_plan\` (when \`ran: true\`), any \`to_change\` / \`to_destroy\` / \`has_destroy_or_replace\` on a repo whose code is unchanged is drift. Distinguish:
+   - **NO DRIFT** — a clean / no-op plan (\`+0 ~0 -0\`): live state matches the code.
+   - **DRIFT** — the plan would change/replace/destroy resources to reconcile state with code. List the drifted resource addresses (from \`destructive\` / the plan summary), the \`blast_radius.tier\`, and call out any \`stateful_destructive\` entry loudly (reconciling it could destroy data). Surface a non-deterministic plan (\`idempotent: false\`) separately — a perpetual diff is config non-determinism, not true drift.
+   - **also read from \`detect_plan_drift\`**: \`noise_filtered\` (updates excluded as provider-computed churn, e.g. aws \`tags_all\` — mention the count, they are not drift); \`forgotten\` (resources this plan drops from management — the cloud object survives but drift detection goes blind to it; when \`needs_human\` is true a STATEFUL resource is leaving management: surface \`needs_human_reasons\` prominently); and \`action_invocations\` (provider actions THIS apply will run — flag any with \`declared_in_code: false\`).
+
+4. **report + gate**:
+   - call \`${t("report_progress")}\` once with the verdict — **NO DRIFT**, **DRIFT** (the drifted addresses + blast radius + any stateful/needs-human callout, with the collapsed \`plan_text\`), or **INCONCLUSIVE** (no creds / plan couldn't run — say which). Recommend the human action for drift (reconcile via the console change's reversal, an \`apply\`, or a code update) — never auto-fix it.
+   - when \`${t("set_output")}\` is available, emit a structured result (e.g. \`{ "drift": <bool>, "drifted_resources": <n>, "stateful_at_risk": <n>, "inconclusive": <bool> }\`) so a scheduled workflow can open an alert / fail a check on \`drift == true\`. Pair this with the action's \`output_schema\` input to expose those keys as named outputs (without it, \`${t("set_output")}\` exposes a single \`result\` string).
+
+5. **guardrails**: never modify \`*.tf\`/\`*.tfvars\`, never push, never open a PR. ${PRODUCT_NAME} never applies and never reconciles drift itself — the verdict is the only deliverable.`,
+  };
+}

package/src/modes/fix.ts

@@ -0,0 +1,29 @@
+import type { Mode, ToolRef } from "./types.ts";
+
+export function fixMode(t: ToolRef): Mode {
+  return {
+    name: "Fix",
+    description:
+      "Fix CI failures; debug failing tests or builds; investigate and resolve check suite failures",
+    prompt: `### Checklist
+
+1. **task list**: create your task list for this run as your first action.
+
+2. Checkout the PR branch via \`${t("checkout_pr")}\`.
+
+3. Fetch check suite logs via \`${t("get_check_suite_logs")}\`.
+
+4. **CRITICAL**: verify the failure was INTRODUCED BY THIS PR before fixing. If unrelated, abort and report.
+
+5. Diagnose and fix:
+   - read the workflow file, reproduce locally with the EXACT same commands CI runs
+   - fix the issue using your native file and shell tools
+   - verify the fix by re-running the exact CI command
+   - review the diff before committing — verify only the fix is present, no debug artifacts, no unrelated changes. the fix should be clean enough that a senior engineer would approve without hesitation.
+   - commit locally via \`${t("git")}\` (\`git add\` the changed files, then \`git commit -m "..."\`) — works even when \`shell\` is disabled
+
+6. Finalize:
+   - confirm a clean working tree, then push via \`${t("push_branch")}\` (same push/prepush guidance as Build mode in *SYSTEM*)
+   - call \`${t("report_progress")}\` with the diagnosis and fix summary (or the exact push error if push failed)`,
+  };
+}

package/src/modes/incremental-review.ts

@@ -0,0 +1,103 @@
+import { REVIEWER_AGENT_NAME } from "#app/agents/reviewer";
+import { BOT_LOGIN, PRODUCT_NAME, PRODUCT_SLUG } from "#app/brand";
+import { FINDING_VERIFICATION_PASS, REVIEW_FINDING_PRECEDENTS } from "#app/reviewQuality";
+import { PR_SUMMARY_FORMAT } from "./prFormats.ts";
+import type { Mode, ToolRef } from "./types.ts";
+
+export function incrementalReviewMode(t: ToolRef): Mode {
+  return {
+    name: "IncrementalReview",
+    nonCommitting: true,
+    description:
+      "Re-review a PR after new commits are pushed; focus on new changes since the last review",
+    prompt: `### Checklist
+
+1. **task list**: create your task list for this run as your first action.
+
+2. **checkout**: call \`${t("checkout_pr")}\` — this returns PR metadata, \`diffPath\` (full diff), \`incrementalDiffPath\` (changes since last reviewed version, if available), and (when TF declarations changed) a supplemental \`impactPath\`. read the diff TOC first and use its line ranges as your coverage checklist. only AFTER establishing scope from the diffs, use \`impactPath\` as an explicitly-incomplete list of reference leads — it never replaces raw-diff reading or establishes coverage.
+
+3. **incremental scope**: if \`incrementalDiffPath\` is present, read it to see what changed since the last review. this is a range-diff that isolates the net changes, filtering out base branch noise. if not present, fall back to reviewing the full PR diff and determine what changed since ${PRODUCT_NAME}'s most recent review.
+
+4. **prior feedback — read AND retire it**: fetch previous reviews via \`${t("list_pull_request_reviews")}\`, then call \`${t("get_review_comments")}\` on each prior ${PRODUCT_NAME} review. Each thread renders as a section whose first line is a fenced tag \`comment author=<login> id=<fullDatabaseId> review=<reviewId> thread=<graphqlId>\`; section headers carry \`[RESOLVED]\` / \`[OUTDATED]\` when relevant. For every **open, ${PRODUCT_NAME}-originated** thread, decide and act:
+
+   - **${PRODUCT_NAME}-originated** means the FIRST \`comment author=...\` tag in the section is \`author=${BOT_LOGIN}\`. The \`*\` marker on individual comments is unrelated — it flags whether a comment belongs to the queried review, not whether it is the thread root.
+   - **addressed?** read the file at the thread's anchor and judge whether the substantive concern is now resolved by the new commits. Lines being modified isn't enough: reformatting, renaming, or moving the same code elsewhere doesn't address a concern. If the comment raised multiple distinct concerns, ALL must be addressed. The \`[OUTDATED]\` tag means GitHub moved the anchor (line shift, force-push, rename) — it does NOT mean the concern was addressed; re-read the code at its new location before deciding.
+   - **if addressed**: call \`${t("reply_to_review_comment")}\` with the root tag's numeric \`id=\` as \`comment_id\` (NOT the \`thread=\` value — that's a separate GraphQL ID used only by resolve) and a one-line body (e.g. \`Addressed in <short-sha>.\`), then call \`${t("resolve_review_thread")}\` with the root tag's \`thread=\` value as \`thread_id\`. Do this BEFORE drafting the new review so the GitHub thread state aligns with the new review by the time it lands.
+   - **if uncertain or partially addressed**: leave open. False-positive resolutions erode trust faster than false negatives.
+   - **scope**: only retire ${PRODUCT_NAME}-originated threads. Threads from human reviewers belong to those humans to resolve, even if the commit happened to address them.
+   - **reaction signal**: comment tags may carry \`reactions=👍N,👎N\` — human votes on the finding. A 👎 on a ${PRODUCT_NAME}-originated root comment is the human telling you the finding was wrong or unwanted: do NOT re-raise that finding class in this review, and treat it as false-positive feedback — when a LEARNINGS file is configured, record the rejected finding class (rule/pattern + why the human rejected it, if discernible) so future reviews stop flagging it. A 👍 confirms the finding class is valued; no action needed beyond noting it. Reactions never override the addressed/unaddressed judgment for retiring threads — a 👍 on an unfixed finding does not make it addressed.
+
+   The remaining open threads feed step 8's dedup filter — anything already flagged and unchanged by the new commits should not be re-raised. The rolling PR summary snapshot is the durable record of retire activity; you don't need to surface it in the review body.
+
+5. **triage**: orient on the *incremental* changes — domain, seams, external contracts, user-facing surfaces. pull as much context as you need to render a confident review: read related files, grep for callers of changed symbols, check tests that exercise the touched paths. **you are the synthesizer.**
+
+   if the incremental changes are **genuinely trivial**, skip the fan-out entirely and jump to step 10's non-substantive path (do NOT submit a review).
+
+   "Genuinely trivial" (skip): formatting/comment tweaks, import reordering, lockfile regen, mechanical rename of import paths, whitespace-only.
+   "Looks trivial but isn't" (do NOT skip — same anti-patterns as Review mode): 1-line changes to SQL/regex/auth/billing/permissions/signature-verification code; flipping feature-flag defaults or retry/timeout constants; money/tax/HTTP-method/redirect changes; tightening or loosening a comparison operator; mixed diffs with a semantic line buried in formatting.
+   When unsure, treat as non-trivial.
+
+6. **lens dispatch — one lens per unresolved, load-bearing hypothesis (0, 1, or 2+)**.
+
+   Re-review the incremental changes yourself first. A lens is an independent pass at a *specific, falsifiable question the new commits raise that you could not confidently resolve on your own* — not a second opinion for its own sake. The default is **0 lenses**: most incremental reviews resolve fully yourself, especially thread-reply re-reviews where the user asks "did you address X?" rather than "review the diff again." After your own pass, keep only the open questions that meet ALL THREE bars:
+   - **falsifiable** — you can state in one line what evidence confirms it and what refutes it.
+   - **load-bearing** — if it resolves the wrong way, the review's verdict or a specific finding changes.
+   - **beyond your own reach** — the code alone doesn't settle it (needs an external-contract check, a cross-file trace too wide to hold confidently, or an independent adversarial read of subtle logic). "A second look to be thorough" does NOT qualify.
+
+   Dispatch **one \`${REVIEWER_AGENT_NAME}\` lens per surviving hypothesis** — **0** for most re-reviews, **1** when a single real question remains, **2+** when several do. The count follows the questions: never manufacture a hypothesis to reach two, never drop a real one to avoid dispatching alone. When you dispatch 2+, they go out together in parallel (step 7). High-stakes subsystems (auth, billing, payments, schema migration, webhooks, secrets, RBAC, multi-tenant isolation, cron/scheduling) and substantive deltas (>5 files, >200 net new lines) are where an unresolved question is most likely load-bearing — but a 1-line change to a security boundary can raise exactly one lens-worthy hypothesis, and a large mechanical delta can raise none. Size is a hint, never the gate.
+
+   Lens framing follows Review mode: themed lenses (correctness, security, etc.) and subsystem lenses (auth, billing, schema-migration, etc.) — for high-stakes domains lead with the subsystem lens.
+
+7. **fan out (only if step 6 raised ≥1 hypothesis)**: dispatch every \`${REVIEWER_AGENT_NAME}\` lens for this run **IN A SINGLE ASSISTANT TURN.** One hypothesis is a single Task block; **2+ hypotheses are MULTIPLE PARALLEL TASK TOOL_USE BLOCKS IN ONE MESSAGE.**
+
+   ⚠️  CRITICAL — WHEN YOU DISPATCH 2+ LENSES, PARALLELISM IS MANDATORY. ⚠️
+   Default tool-call behavior is **serial dispatch**: emit one Task call, await result, emit next, await, etc. With multiple lenses this collapses your fan-out into a sequential review where each lens adds N × (orchestrator-think-time + lens-execution-time) to wall time. **YOU MUST OVERRIDE THIS DEFAULT.** Emit ALL of your Task tool_use blocks in the SAME assistant message, BEFORE you read ANY result from ANY of them. (A lone lens is one block in one turn.)
+
+   ✅ Right pattern: one assistant turn with N Task tool_use blocks → wait → N results arrive together → aggregate.
+   ❌ Wrong pattern: turn 1 = Task(lens A) → turn 2 (after A's result) = Task(lens B). This is the failure mode.
+
+   You can also include your own \`read\` / \`grep\` / \`webfetch\` calls in the SAME turn as the parallel \`${REVIEWER_AGENT_NAME}\` dispatches.
+
+   if a subagent errors out, times out, or returns nothing usable, retry once with the same lens; if it still fails, proceed with partial coverage and note the missing lens in the review body. each subagent gets:
+   - **the absolute diff path(s) from step 2's \`${t("checkout_pr")}\` return, named verbatim in the dispatch prompt.** when \`incrementalDiffPath\` is present, name BOTH (\`incrementalDiffPath: /tmp/.../pr-NNN-SHA-incremental.diff\` then \`diffPath: /tmp/.../pr-NNN-SHA.diff\`) — the reviewer's baked-in prompt reads incremental first and uses full for context; when only \`diffPath\` exists, name it alone. the subagent \`read\`s those files; it must NOT re-derive via \`git diff\` (bare \`git diff origin/<base>\` is symmetric and pulls in the inverse of base-branch progress — pure noise, and the git tool rejects it), and paraphrasing ("review the new commits") sends it down that fallback, which also fails on shallow GHA checkouts. do NOT tell them to skip pre-existing issues — that suppresses regressions the new commits amplified; the "issues must be NEW" filter lives at aggregation time (step 8), not in the subagent prompt.
+   - **only one lens = one hypothesis** — state it as the falsifiable question with its scope boundary and what evidence would confirm vs refute it; never a multi-section "review for X, Y, and Z" prompt and never a vague "review for security"
+   - **a Task \`description\` set to the lens name** — the harness reads this field to label log lines so parallel runs can be told apart.
+   - if the lens touches external contracts, instruct the subagent to verify load-bearing claims via web search and quote source URLs.
+   - ask the subagent to report findings with file paths and NEW line numbers from the full PR diff so you can anchor inline comments.
+
+   delegation discipline:
+   - do NOT summarize the changes for them (biases toward validation frame)
+   - do NOT hand them a curated reading list (let them discover scope)
+   - do NOT pre-shape their output with a finding schema
+   - do NOT mention the other lenses (independence is the point)
+
+8. **aggregate, draft, self-critique**: merge findings (yours + any subagent output if you went multi-lens); de-dup overlaps; trace each finding yourself. drop praise, style preferences, speculative/unverified claims, findings about pre-existing code unrelated to the new commits, anything not actionable, and anything that re-states prior review feedback (heuristic: if the finding's root cause lives in lines the *new commits* added or modified, it's in scope; otherwise drop). also drop **bloat-shaped findings** — proposed fixes that would add defensive checks for cases that can't happen, abstractions used once, comments restating obvious code, tests asserting tautologies, or "just-in-case" guards. subagents are fallible and bias toward recommending changes; the bar for an actionable inline comment is sound + correct + elegant. recommending a change that improves only one of the three (or degrades elegance to nominally improve correctness) makes the codebase worse, not better. To compute "lines the new commits added or modified": if \`incrementalDiffPath\` from step 2 is present, use it directly. Otherwise, take the prior ${PRODUCT_NAME} review's \`commit_id\` (returned alongside each entry from \`${t("list_pull_request_reviews")}\` in step 4) and run \`git diff <prior-review-sha>...HEAD\` (three-dot merge-base form) to isolate the lines added since that review. Do NOT use the two-dot \`<prior-review-sha>..HEAD\` form — after a force-push the prior SHA may no longer be an ancestor of HEAD, and the \`git\` tool rejects the symmetric two-dot diff on divergence.
+
+   Apply the **Finding precedents** (defined after this checklist, before the body format) to every candidate — a precedent match means drop, unless you have specific evidence the precedent does not apply here.
+
+   **Hunt for non-anchored concerns before drafting.** After collecting your anchored findings, deliberately scan for concerns that have no specific line to point at — typically: deletion / cleanup plans for code the new commits replace or shadow; rollout sequencing (what happens to in-flight state during deploy / revert?); coverage gaps the new commits imply but don't add; scope questions that only the human can answer (e.g. is the legacy path going away or is this a long-term dual track?); architectural risks the new commits open up that aren't a single-line bug. On substantial incremental diffs (migrations, refactors, multi-file rewrites, version bumps that change runtime semantics), at least one such concern almost always exists; if you can't think of any, your bar is probably too high.
+
+   ${FINDING_VERIFICATION_PASS}
+
+   draft inline comments with NEW line numbers from the full PR diff — attach a \`<details>Technical details</details>\` block to any inline comment whose fix is non-trivial or has cross-file implications (see Inline technical details in the format below). every comment must be actionable, 2-3 sentences max in the visible part.
+
+9. **build the review body**: use the same default format as Review mode (preamble + optional cross-cutting \`### \` sections + optional \`### ℹ️ Nitpicks\` + optional suppressed-findings block) — scoped to the **incremental delta**, not the full PR. The "Reviewed changes" bullets describe what changed since the prior ${PRODUCT_SLUG} review (each bullet starts with a past-tense verb, e.g. \`- Extracted shared CLI runtime into a single module\`). Do NOT include a separate "Prior review feedback" checklist — that's tracked in the rolling PR summary snapshot for the next agent run, and surfacing it in the user-facing body is noise (changes that addressed prior feedback are already covered by the Reviewed-changes bullets). In some cases you may receive a complete diff for the whole PR instead of an incremental one; when this happens, determine what changed since ${PRODUCT_NAME}'s most recent review yourself before drafting bullets.
+
+10. Submit — every run must end with EXACTLY ONE of \`${t("create_pull_request_review")}\` (substantive review) or \`${t("report_progress")}\` (no-review acknowledgement). do NOT call \`create_issue_comment\` for review output.
+
+   Same callout ladder as Review mode — \`[!CAUTION]\` (red, "will break") → \`[!IMPORTANT]\` (purple, "must address before merging") → \`> ℹ️ ...\` (informational, "minor suggestions only") → \`> ✅ ...\` (green friendly, "no concerns"). Same Fix-button lever: the footer renders a Fix button on every non-approving review, so \`approved: true\` suppresses it. Wrapping mergeable feedback in \`[!IMPORTANT]\` trains users to click Fix on reviews that don't need fixing — pick the tier the author's actual next action justifies.
+
+   Follow these rules:
+   - note: the first create_pull_request_review submission may error with a one-time diff-coverage nudge listing unread TOC regions. retry the same call to proceed — optionally after reading the listed ranges. the pre-flight will not block again this session.
+   - IF NO NEW ISSUES, NON-SUBSTANTIVE CHANGES ONLY (trivial formatting, import reordering, comment tweaks): do NOT submit a review. Instead call \`${t("report_progress")}\` with a 1-2 sentence note explaining no review was warranted (e.g. "No new issues. Changes since last review are formatting-only."). this leaves a visible signal that the run completed.
+   - ELSE IF NEW CRITICAL ISSUES (blocks merge — bugs, security, data loss, broken core flows): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> [!CAUTION]\\n> This PR introduces ...\`, followed by the PR summary using the default format below.
+   - ELSE IF NEW MUST-ADDRESS NON-CRITICAL FINDINGS (real consequences if shipped — incorrect behavior, missing validation, regressions the author should fix before merge): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> [!IMPORTANT]\\n> ...\`, followed by the PR summary using the default format below. Do NOT use this tier for nits, style preferences, or "consider also" suggestions.
+   - ELSE IF NEW MINOR SUGGESTIONS ONLY (single-line nits, doc/comment polish, defer-able observations, "rough edges"): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> ℹ️ No critical issues — minor suggestions inline.\\n\\n\` (vary the wording after ℹ️ to fit the review), followed by the PR summary using the default format below.
+   - ELSE IF INFORMATIONAL OBSERVATIONS (mergeable as-is, but worth surfacing — e.g. prior feedback addressed cleanly with one minor stale doc reference, or a noteworthy positive observation): call \`${t("create_pull_request_review")}\` with \`approved: true\`, NO inline comments, and the review body. body opens with \`> ✅ No new issues found.\\n\\n\` (or similar friendly green opener), followed by the PR summary using the default format below. If a point is concrete enough to anchor to a line, downgrade the whole review to "minor suggestions only" (\`approved: false\`) instead — the ✅ signals "no action needed", which contradicts an actionable anchor.
+   - ELSE IF NO NEW ISSUES, SUBSTANTIVE CHANGES (new functionality, behavior changes, or fixes to prior review feedback): call \`${t("create_pull_request_review")}\` to create a PR review. If all previous reviews have been properly addressed and no new issues were discovered, set \`approved: true\`. body opens with \`> ✅ No new issues found.\\n\\n\`, followed by the PR summary using the default format below.
+
+${REVIEW_FINDING_PRECEDENTS}
+
+${PR_SUMMARY_FORMAT}`,
+  };
+}

package/src/modes/index.ts

@@ -0,0 +1,94 @@
+// changes to mode definitions should be reflected in action.yml's `mode:` input,
+// the regenerated docs/action-inputs.md (`pnpm docs:inputs` — this repo uses pnpm),
+// and the human-facing modes reference on the website (infraweaver.dev/docs/modes —
+// infraweaver-ui src/app/[locale]/(marketing)/docs/modes/page.tsx; the [locale]
+// segment came in with next-intl, and a stale path here is exactly how the
+// generated action-inputs manifest silently missed inputs before — see the header
+// of scripts/generate-ui-inputs.ts).
+//
+// Each built-in mode lives in its own file in this directory as a
+// `(t: ToolRef) => Mode` factory; a new mode means a new file plus a wiring line
+// in the `computeModes` array below (the array order is the canonical mode
+// order, asserted by modes.test.ts). Shared pieces: ./types.ts (Mode, ToolRef)
+// and ./prFormats.ts (the PR-body format constants).
+import { type AgentId, formatMcpToolRef } from "#app/external";
+import { addressReviewsMode } from "./address-reviews.ts";
+import { assessMode } from "./assess.ts";
+import { buildMode } from "./build.ts";
+import { complianceAuditMode } from "./compliance-audit.ts";
+import { costOptimizationMode } from "./cost-optimization.ts";
+import { driftDetectMode } from "./drift-detect.ts";
+import { fixMode } from "./fix.ts";
+import { incrementalReviewMode } from "./incremental-review.ts";
+import { modernizeDeprecatedMode } from "./modernize-deprecated.ts";
+import { planMode } from "./plan.ts";
+import { policyGateMode } from "./policy-gate.ts";
+import { refactorMode } from "./refactor.ts";
+import { refreshRemediationMode } from "./refresh-remediation.ts";
+import { remediateMode } from "./remediate.ts";
+import { remediateAndRefactorMode } from "./remediate-and-refactor.ts";
+import { resolveConflictsMode } from "./resolve-conflicts.ts";
+import { reviewMode } from "./review.ts";
+import { summarizePrMode } from "./summarize-pr.ts";
+import { taskMode } from "./task.ts";
+import { terraformCodeReviewMode } from "./terraform-code-review.ts";
+import type { Mode } from "./types.ts";
+import { updateDependenciesMode } from "./update-dependencies.ts";
+
+export {
+  PR_SUMMARY_FORMAT,
+  REFACTOR_PR_FORMAT,
+  REMEDIATION_PR_FORMAT,
+} from "./prFormats.ts";
+export type { Mode, ToolRef } from "./types.ts";
+
+export function computeModes(agentId: AgentId): Mode[] {
+  const t = (toolName: string) => formatMcpToolRef(agentId, toolName);
+  return [
+    buildMode(t),
+    addressReviewsMode(t),
+    reviewMode(t),
+    incrementalReviewMode(t),
+    terraformCodeReviewMode(t),
+    summarizePrMode(t),
+    planMode(t),
+    fixMode(t),
+    resolveConflictsMode(t),
+    assessMode(t),
+    remediateMode(t),
+    refreshRemediationMode(t),
+    refactorMode(t),
+    remediateAndRefactorMode(t),
+    policyGateMode(t),
+    updateDependenciesMode(t),
+    modernizeDeprecatedMode(t),
+    costOptimizationMode(t),
+    driftDetectMode(t),
+    complianceAuditMode(t),
+    taskMode(t),
+  ];
+}
+
+export const modes: Mode[] = computeModes("opencode");
+
+/** built-in mode names in canonical casing. used to validate / canonicalize the
+ * `mode` action input so a CI run can pin a mode deterministically instead of
+ * relying on the agent's prompt-driven `select_mode` choice. mode names are
+ * agent-independent (only the embedded tool refs differ per agent), so the
+ * opencode-rendered list is the authoritative name set. */
+export const BUILTIN_MODE_NAMES: readonly string[] = modes.map((m) => m.name);
+
+/**
+ * modes that legitimately never modify the working tree. used by the post-run
+ * dirty-tree gate to suppress the "commit and push" nudge — those modes
+ * complete by submitting a review, posting a comment, or reporting a verdict,
+ * not by touching files. any leftover in the tree at end-of-run is incidental
+ * tool noise (e.g. a `node_modules/` from a stray install attempt) on an
+ * ephemeral worktree; nudging the agent to commit it would produce a spurious
+ * PR. derived from the `nonCommitting` flag each read-only mode declares in
+ * its own factory, so a new mode carries its committing-ness with it instead
+ * of needing a second edit here.
+ */
+export const NON_COMMITTING_MODES: ReadonlySet<string> = new Set(
+  modes.filter((m) => m.nonCommitting).map((m) => m.name),
+);

package/src/modes/modernize-deprecated.ts

@@ -0,0 +1,36 @@
+import { REFACTOR_PR_FORMAT } from "./prFormats.ts";
+import type { Mode, ToolRef } from "./types.ts";
+
+export function modernizeDeprecatedMode(t: ToolRef): Mode {
+  return {
+    name: "ModernizeDeprecated",
+    description:
+      "Migrate deprecated Terraform patterns to their modern equivalents (aws_launch_configuration → aws_launch_template, the template_file data source → the templatefile() function, EOL provider pins), one PR per pattern class. These ALTER the resource set, so they are proven by a reviewed plan delta (or shipped `proposed — unproven`) with a `moved {}` block wherever an address can be preserved; equivalence is never claimed.",
+    prompt: `### Checklist
+
+This mode migrates DEPRECATED Terraform patterns to modern ones. Unlike Refactor, these migrations swap a resource TYPE / data source / function and therefore ALTER the resource set — so equivalence is FALSE and must NEVER be claimed (the equivalence guard would block such a claim anyway). The proof is a reviewed plan delta when cloud credentials exist, otherwise the change ships labelled \`proposed — unproven\`. Author a \`moved {}\` block wherever an address genuinely carries over, and use \`create_before_destroy\` where a replace is unavoidable.
+
+1. **task list**: create your task list for this run as your first action.
+
+2. **detect**: find deprecated patterns. \`${t("terraform_version_currency")}\` surfaces EOL provider pins; read the Terraform for the well-known deprecated forms — \`aws_launch_configuration\` (→ \`aws_launch_template\`), \`aws_elb\` (→ \`aws_lb\`), the \`template_file\` data source / archived \`hashicorp/template\` provider (→ the built-in \`templatefile()\` function), and other documented EOL resources. Pick **one pattern class** to migrate this run.
+
+3. **pick scope — ONE pattern class per PR**: migrate every site of that single pattern (e.g. all \`aws_launch_configuration\` → \`aws_launch_template\`) in one coherent PR; do NOT mix pattern classes. **Targeted directive override:** if YOUR TASK names a pattern or files, act only on those. Unless asked for more, open **at most one PR this run**.
+
+4. **migrate (preserve behaviour as far as the new shape allows)**: rewrite each site to the modern equivalent with the **same effective configuration** (same AMI / instance type / user-data, same listener / target behaviour). Where the new resource keeps the logical address, author a \`moved {}\` block via \`${t("terraform_generate_moved")}\` so state carries over instead of a destroy/recreate; where the migration is an inherent replace (e.g. a launch config referenced by an ASG), use \`create_before_destroy\` and call it out. Only touch \`*.tf\`/\`*.tfvars\`.
+
+5. **validate**: \`${t("terraform_validate")}\` — never push a migration whose validate didn't pass. Check its \`providers\` majors and \`${t("terraform_provider_schema")}\` for the modern resource's argument shape.
+
+6. **prove via plan, never equivalence**: do NOT call \`${t("terraform_equivalence_check")}\` — this change is behaviour-altering and an equivalence claim would be false (and is hard-blocked at push). Instead:
+   - **cloud credentials present**: call \`${t("terraform_plan")}\` and attach the **reviewed plan delta**. Treat \`has_destroy_or_replace\`/\`stateful_destructive\` exactly as Remediate — a stateful destroy/replace is hard-blocked at push unless \`allow_replace\` covers it; a high \`blast_radius.tier\` or \`needs_human\` adds the \`needs-human\` label (\`${t("add_labels")}\`) + a prominent callout.
+   - **no credentials**: ship \`proposed — unproven\` — add the label, put the proposed-unproven banner unmissably at the top of the body, and state plainly that this migration ALTERS resources and the plan must be reviewed before merge.
+   - record the outcome with \`${t("terraform_emit_evidence")}\`.
+
+7. **keep module tests consistent** (if a local module changed): \`${t("terraform_module_tests")}\` — update drifting \`examples/\`/tests, never weaken an assertion.
+
+8. **open the PR (MANDATORY body)**: branch \`infraweaver/modernize-<pattern>\` from the scanned HEAD, commit naming the pattern (old → modern), \`${t("push_branch")}\`, \`${t("create_pull_request")}\` (omit \`base\`). Build the body with the **Refactor PR format** below, using the \`## Proposed change — unproven\` / \`## Reviewed plan delta\` section (NOT \`## Equivalence proof\`), naming the moved addresses and listing every migrated site. Never auto-merge.
+
+9. **finalize**: \`${t("report_progress")}\` once — which pattern class was migrated, how many sites, the proof (reviewed-plan / proposed-unproven), and the PR link (or the exact tool error).
+
+${REFACTOR_PR_FORMAT}`,
+  };
+}

package/src/modes/plan.ts

@@ -0,0 +1,21 @@
+import type { Mode, ToolRef } from "./types.ts";
+
+export function planMode(t: ToolRef): Mode {
+  return {
+    name: "Plan",
+    nonCommitting: true,
+    description:
+      "Create plans, break down tasks, outline steps, analyze requirements, understand scope of work, or provide task breakdowns",
+    prompt: `### Checklist
+
+1. **task list**: create your task list for this run as your first action.
+
+2. Analyze the task and gather context:
+   - read AGENTS.md and relevant codebase files
+   - understand the architecture and constraints
+
+3. Produce a structured, actionable plan with clear milestones.
+
+4. Call \`${t("report_progress")}\` with the plan body. Do NOT set \`target_plan_comment\` — that flag is exclusively for revising an existing plan, and \`${t("select_mode")}\` will route you to a separate PlanEdit checklist when a prior plan comment exists for this issue.`,
+  };
+}

package/src/modes/policy-gate.ts

@@ -0,0 +1,27 @@
+import type { Mode, ToolRef } from "./types.ts";
+
+export function policyGateMode(t: ToolRef): Mode {
+  return {
+    name: "PolicyGate",
+    nonCommitting: true,
+    description:
+      "Read-only policy-as-code CI gate: run the repository's own OPA/conftest Rego policies against a Terraform plan and report PASS / FAIL / INCONCLUSIVE — the policy counterpart to the Assess security gate. Opens no PR and modifies nothing.",
+    prompt: `### Checklist
+
+This mode is **read-only** — a policy-as-code gate, the conftest/OPA companion to Assess. It reports whether the repo's OWN Rego policies pass; it never fixes, edits, commits, pushes, or opens a PR.
+
+1. **task list**: create your task list for this run as your first action.
+
+2. **locate policy**: confirm the repo ships policy-as-code — a \`policy/\`, \`policies/\`, or \`.conftest\` directory of Rego. If none exists, call \`${t("report_progress")}\` with "No policy-as-code found (no policy/, policies/, or .conftest Rego) — nothing to gate." and **stop** (an absent policy set is not a failure).
+
+3. **produce a plan to evaluate**: conftest evaluates a Terraform **plan JSON**, so a plan must exist first. Call \`${t("terraform_plan")}\`. It auto-skips (\`ran: false\`) when no cloud credentials / the terraform CLI are present — in that case the gate is **INCONCLUSIVE, not passing**: report that plainly (step 5) so a green check never masks an unevaluated policy.
+
+4. **evaluate**: call \`${t("policy_check")}\`. It runs conftest against the plan JSON and returns \`passed\` plus any \`failures\`, or a skip \`code\` (\`no_target\`, \`conftest_not_installed\`, \`no_policy_dir\`) when it couldn't run — treat any skip as INCONCLUSIVE, never PASS.
+
+5. **report + gate**:
+   - call \`${t("report_progress")}\` once with the verdict: **PASS** (no failures), **FAIL** (list each \`failures\` entry — the policy, the resource, the message), or **INCONCLUSIVE** (conftest / plan / policy dir absent — say which).
+   - when \`${t("set_output")}\` is available, emit a structured result (e.g. \`{ "passed": <bool>, "violations": <n>, "inconclusive": <bool> }\`) so the workflow can fail the check on \`passed == false\`. Pair this with the action's \`output_schema\` input to make the gate enforceable.
+
+6. **guardrails**: never modify \`*.tf\`/\`*.tfvars\`, never push, never open a PR or issue. The verdict is the only deliverable.`,
+  };
+}