infraweaver 0.3.10 → 0.3.12

package/src/mcp/terraform/verifySites.ts

@@ -0,0 +1,106 @@
+/**
+ * Which findings a fix resolved where its rule still fires elsewhere in the file.
+ *
+ * terraform_verify_remediation keys a finding on (scanner, rule, file), so a
+ * rule fixed on one resource but still firing on another in the same file read
+ * as unfixed for both: AWSGoat's open-egress fix on two of four security groups
+ * verified as 0 of 5. Counting by resource instead risks the opposite error —
+ * a fix that moves the defect onto a new resource would look resolved — so a
+ * finding counts as resolved at its own site only when ALL of these hold:
+ *
+ *   - it was placed on a resource when it was reported;
+ *   - that resource is still declared in the file (a renamed or deleted one
+ *     proves nothing);
+ *   - the rule no longer fires on it;
+ *   - every place the rule still fires in the file is a resource it already
+ *     fired on before the fix (no new site, and no finding outside a resource).
+ *
+ * Anything else keeps the file-level answer, which under-claims and never
+ * over-claims.
+ */
+
+import { readFileSync } from "node:fs";
+import { join } from "node:path";
+import type { ScanSession } from "#app/mcp/terraform/scanSession";
+import { resourceAddressAt } from "#app/mcp/terraform/suppressions";
+import { type Concern, concernKeyOf } from "#app/mcp/terraform/types";
+
+/** A reader that returns each file under `cwd` once, or null when unreadable. */
+export function fileReader(cwd: string): (file: string) => string | null {
+  const cache = new Map<string, string | null>();
+  return (file) => {
+    if (!cache.has(file)) {
+      let text: string | null;
+      try {
+        text = readFileSync(join(cwd, file), "utf8");
+      } catch {
+        text = null;
+      }
+      cache.set(file, text);
+    }
+    return cache.get(file) ?? null;
+  };
+}
+
+/** The resource a concern sits in, read from the file as it is now. */
+export function siteOf(c: Concern, read: (file: string) => string | null): string | null {
+  const text = read(c.location.file);
+  return text === null ? null : resourceAddressAt(text, c.location.line);
+}
+
+/** Remember where each reported concern sat, and the first sites per key. */
+export function recordConcernSites(session: ScanSession, concerns: Concern[], cwd: string): void {
+  const read = fileReader(cwd);
+  session.siteById ??= new Map();
+  session.firstSitesByKey ??= new Map();
+  const first = session.firstSitesByKey;
+  const fresh = new Map<string, Set<string | null>>();
+  for (const c of concerns) {
+    const site = siteOf(c, read);
+    session.siteById.set(c.id, site);
+    const key = concernKeyOf(c);
+    if (first.has(key)) continue;
+    const sites = fresh.get(key) ?? new Set();
+    sites.add(site);
+    fresh.set(key, sites);
+  }
+  for (const [key, sites] of fresh) first.set(key, sites);
+}
+
+export interface SiteRequest {
+  id: string;
+  /** the (scanner, rule, file) key */
+  key: string;
+  /** the resource address the finding sat in when reported, or null */
+  site: string | null;
+  file: string | undefined;
+}
+
+export function resolvedAtSite(params: {
+  requested: readonly SiteRequest[];
+  /** every finding the re-scan reports, with the resource it sits in */
+  current: readonly { key: string; site: string | null }[];
+  /** per key, the resources the rule fired on in the first scan of the run */
+  firstSites: ReadonlyMap<string, ReadonlySet<string | null>>;
+  /** the resource addresses a file declares now */
+  declared: (file: string) => ReadonlySet<string>;
+}): string[] {
+  const firingByKey = new Map<string, (string | null)[]>();
+  for (const c of params.current) {
+    const list = firingByKey.get(c.key) ?? [];
+    list.push(c.site);
+    firingByKey.set(c.key, list);
+  }
+  const out: string[] = [];
+  for (const r of params.requested) {
+    if (r.site === null || r.file === undefined) continue;
+    const firing = firingByKey.get(r.key) ?? [];
+    const known = params.firstSites.get(r.key);
+    if (known === undefined) continue;
+    if (firing.some((s) => s === null || !known.has(s))) continue;
+    if (firing.includes(r.site)) continue;
+    if (!params.declared(r.file).has(r.site)) continue;
+    out.push(r.id);
+  }
+  return out;
+}

package/src/modes/refactor.ts

@@ -18,6 +18,8 @@ This mode standardises STRUCTURE while preserving BEHAVIOUR — the equivalence
    - \`${t("terraform_normalization_candidates")}\` → in-place idiomatic cleanups that change SYNTAX, not behaviour (redundant whole-string \`"\${expr}"\` interpolation; legacy HCL0.11 map-argument block syntax like \`vars {\` on a \`template_file\`). These relocate NOTHING — zero \`moved {}\` blocks — and are proven by the same equivalence check.
    - \`${t("terraform_consolidation_candidates")}\` → the SAME resource shape declared in several root directories (\`env/dev\` + \`env/staging\` + \`env/prod\`), with the single parameterised module they could all call already derived: which attributes are identical (module content) and which differ (per-environment inputs). A member root of a group will ALSO show up as a zero-candidate cluster in \`${t("module_extraction_candidates")}\` — prefer the consolidation, which does that work once for every environment instead of once per environment. Its \`near_groups\` are the opposite case: roots recognisably the same stack that DIFFER (one carries a resource the other does not), where folding them together is a design decision this mode has no basis for. Do NOT extract a near-group root's shared resources into a module on its own either — a module one twin calls and the other does not widens exactly the drift the near-group reports. Leave those roots alone and name the near-group and its \`differences\` in your report.
 
+   **A result marked \`report_only\` is an observation, not work.** The repository is a module other configurations call (\`report_only_reason\` says why), and restructuring it is churn for every caller: name those candidates in your \`${t("report_progress")}\` summary and open no PR for them. \`examples/\` roots are left out of every candidate list unless the operator set \`refactor_examples\`.
+
    **Before picking, check the interface.** \`${t("module_extraction_candidates")}\` reports \`unmapped_attributes\` per candidate and a top-level \`partial_interfaces\` list: arguments the raw resources SET that the target module does not. Adopting such a module DROPS them silently — and the equivalence check cannot catch it, because once the argument is gone it is absent from both sides. Two of these are unrecoverable rather than merely wrong (\`object_lock_enabled\` cannot be set after creation; \`force_destroy\` changes deletion semantics). So: **decline the candidate, or extend the module to expose the argument and say so in the PR body.** Deleting the argument to make the shapes match is never the fix. A candidate whose \`unmapped_attributes\` is \`null\` was NOT checked — the module is external and its code is not in this repo — which is not the same as clean.
 
    Pick the highest-value refactor across ALL THREE detectors. Only when they ALL come back empty — or all that remains is a cluster in a near-group root — is there genuinely nothing to do: call \`${t("report_progress")}\` with an ACCURATE message — e.g. "No behaviour-preserving refactor found: no extraction clusters and no idiomatic-normalisation candidates." — and **stop**. Two anti-patterns to avoid in that message: (i) never call a repo "already idiomatic" while normalisation candidates remain; (ii) when what's left is behaviour-CHANGING modernisation — a deprecated-resource swap (\`aws_launch_configuration\`→\`aws_launch_template\`, \`aws_elb\`→\`aws_lb\`, \`template_file\`→\`templatefile()\`) — do NOT report "nothing to refactor": that is real work, but it ALTERS the resource set, so it belongs to Remediate. Say so explicitly rather than implying the code is clean.

package/src/modes/refresh-remediation.ts

@@ -26,7 +26,7 @@ This mode keeps already-open ${PRODUCT_NAME} remediation PRs healthy. A remediat
    - **resolved-on-base? → close it**: look for a group in step 3's scan whose \`id\` equals the PR's \`group_id\` (for a by-rule/batch PR, match on the concern ids it covered). If **no** current group/concern corresponds, the concern was already fixed on the base (a human fix, or a base change removed the file) — the PR is redundant. Call \`${t("close_pull_request")}\` with a one-line \`comment\` explaining it's resolved on the base. Do not push anything for this PR.
    - **still present → re-derive the fix on the current base**:
      - **read WHY the CI failed, before changing anything** (\`checks_failing\` PRs only): when step 2 gave the PR a \`failing_check_suite_id\`, call \`${t("get_check_suite_logs")}\` with that id FIRST. Re-deriving without reading the failure is exactly how attempt 2 and attempt 3 become identical repeats of attempt 1 — same fix, same red check, three times, until the retry cap escalates a PR nobody learned anything about. Use the returned \`failed_steps\` and log excerpt to decide what to do DIFFERENTLY this attempt. If the log shows the failure is not ours — a broken base, a missing credential, an unrelated flaky job — do not spend an attempt re-deriving: add \`needs-human\` (\`${t("add_labels")}\`), post ONE comment naming the failing step, and move on. Record the cause in the PR body/comment you write below, so the next attempt and any human start from what you found. When the id is absent, or the tool reports no failed runs, say so in the comment and continue with the plain re-derive rather than guessing.
-     - **branch**: recreate the remediation branch at the current base HEAD via \`${t("git")}\` (\`git checkout -B remediate/<id>\`) — \`-B\` force-resets it to the just-scanned base so the diff is only your fix.
+     - **branch**: recreate the remediation branch at the current base HEAD via \`${t("git")}\` (\`git({ command: "checkout", args: ["-B", <the PR's branch>] })\`, the \`branch\` step 2 returned) — \`-B\` force-resets it to the just-scanned base so the diff is only your fix.
      - **fix → validate → plan → keep tests consistent → prove it**: apply the minimal fix for that group exactly as in **Remediate** step 4 (same \`${t("terraform_validate")}\`, \`${t("terraform_plan")}\`, \`${t("terraform_module_tests")}\`, and \`${t("terraform_verify_remediation")}\` gates, and the same guardrails — never open/keep a PR whose validate didn't pass, abandon a group that would destroy a stateful resource, etc.).
      - **force-update the PR branch**: \`${t("push_branch")}\` with \`force: true\` (the PR already exists; force-updating its branch refreshes it in place — do NOT open a second PR). The Terraform-only / secret / destroy guardrails still run at push time.
      - **refresh the body**: \`${t("update_pull_request_body")}\` rebuilt from the fresh \`${t("terraform_verify_remediation")}\` result (the Remediation PR format below), and add a one-line note that it was rebased onto the current base (\`<short-sha>\`) on this run.

package/src/modes/remediate-and-refactor.ts

@@ -20,7 +20,7 @@ This mode composes the **Remediate** and **Refactor** verbs into a single run. I
    - **commit the fix** (\`git add\` only the changed \`*.tf\`/\`*.tfvars\`, a \`fix(tf): …\` message). Do NOT push yet. This committed state is the refactor's equivalence BASELINE.
 
 3. **REFACTOR (phase 2) — modularise on top of the committed fix**: follow the **Refactor** mode's flow:
-   - \`${t("module_extraction_candidates")}\` / \`${t("terraform_normalization_candidates")}\` → pick one behaviour-preserving refactor. Respect a pinned \`refactor_source\` if one was supplied (it constrains which module source you may use; the behaviour-altering b.4 path is only available when the operator pinned \`third-party\`).
+   - \`${t("module_extraction_candidates")}\` / \`${t("terraform_normalization_candidates")}\` → pick one behaviour-preserving refactor; a result marked \`report_only\` (the repository is a module others call) is named in the summary, never proposed. Respect a pinned \`refactor_source\` if one was supplied (it constrains which module source you may use; the behaviour-altering b.4 path is only available when the operator pinned \`third-party\`).
    - resolve the module source, wire the \`module\` call against its real interface (\`${t("terraform_module_interface")}\` for a local module dir, \`${t("terraform_module_lookup")}\` for a registry-sourced one), and emit a \`moved {}\` block for EVERY relocated address (\`${t("terraform_generate_moved")}\`).
    - \`terraform fmt\` + \`${t("terraform_validate")}\`, then — **with the refactor edits still UNCOMMITTED** — call \`${t("terraform_equivalence_check")}\`. In this mode it diffs the working tree against the COMMITTED fix (not the run-start commit), so it measures only the refactor. It must return \`equivalent: true\` (zero uncovered moves, resource set + arguments preserved, validate + fmt clean) before you proceed; \`${t("push_branch")}\` hard-blocks an unproven one — and, once this run has added a \`moved {}\` block, it also hard-blocks a push that never ran the check at all, so abandoning the refactor means REVERTING its edits rather than leaving them in with the fix. If it can't be proven equivalent, abandon the refactor and ship the fix alone.
    - **document the module (only when the \`docs\` input is enabled)**: after the equivalence check passes, call \`${t("terraform_module_docs")}\` for the module you created/adopted (pass the relocated addresses as \`moves\`). Do not hand-write docs — the tool builds from the interface, moved blocks, and equivalence verdict.

package/src/modes/remediate.ts

@@ -34,8 +34,8 @@ export function remediateMode(t: ToolRef): Mode {
 
 4. **for the chosen group**:
    - **base branch**: this run's base branch is resolved deterministically — \`${t("create_pull_request")}\` targets the \`base_branch\` input if set, else the branch the run started on, else the repository's default branch (\`main\`, or \`master\`). You do not choose it; just **omit** the \`base\` argument when opening the PR (below) and it is filled in.
-   - **idempotency**: the remediation branch is \`remediate/<group-id>\`. Before doing anything, check whether that branch or an open PR for it already exists (\`${t("git")}\` / \`${t("get_pull_request")}\`). If one exists, update it rather than opening a duplicate.
-   - **branch**: create \`remediate/<group-id>\` from the **current HEAD** (the checkout that was just scanned) via \`${t("git")}\` (\`git checkout -b remediate/<group-id>\`). Do NOT switch to a different base first — branching from the scanned checkout keeps the PR diff to exactly your fix.
+   - **idempotency**: the remediation branch is the group's \`branch\` (\`remediate/<group-id>\`, with a \`--<base>\` suffix when the PR targets a non-default branch) — use it exactly, never a name of your own. Before doing anything, check whether that branch or an open PR for it already exists (\`${t("git")}\` / \`${t("get_pull_request")}\`). If one exists, update it rather than opening a duplicate.
+   - **branch**: create the group's \`branch\` from the **current HEAD** (the checkout that was just scanned) via \`${t("git")}\` (\`git({ command: "checkout", args: ["-b", <branch>] })\`). Do NOT switch to a different base first — branching from the scanned checkout keeps the PR diff to exactly your fix.
    - **honest refusal (decide BEFORE fixing)**: if the group's concerns appear in the scan's \`refusal_candidates\` (the fix needs a human decision — narrowing an IAM wildcard, a KMS key policy, a real ingress CIDR), do **not** guess a fix that could break the stack. Instead open a structured issue (\`${t("create_issue")}\`) describing the concern, why it isn't auto-fixed, and what a human should do, and skip the PR for that group. A proven fix or an honest refusal — never a guessed, unverifiable PR.
    - **propose, then let me steer (when there's no single right fix)**: distinct from honest refusal (which refuses a fix a human must *decide*), this is for a finding with **2–3 genuinely distinct, defensible fixes** that differ in trade-offs, not correctness (e.g. encrypt with an AWS-managed key **vs** a customer-managed KMS key; a narrow security-group rule **vs** a prefix list **vs** a VPC endpoint). When such a fork exists **and the triggering comment did not already select a strategy**, do **not** silently pick for the reviewer: via \`${t("create_issue_comment")}\` post one short comment listing the options as **A / B / C** — each a single line (what it does + its trade-off) — and ask the reviewer to reply \`${COMMENT_COMMAND} fix #<concern-id> with strategy <A|B|C>\`. Then **skip the PR for this group** this run and note it in your final report (it resumes when the reviewer replies). When the comment **did** select one (\`fix #<id> with strategy B\`, or a bare \`strategy B\` reply on the proposal thread), apply **exactly** that strategy — don't second-guess it. Reserve this for real forks in the road; a fix with one obvious correct answer just gets made.
    - **reuse a proven fix (optional, do this BEFORE editing)**: call \`${t("terraform_fix_memory")}\`. When proven-fix memory is enabled it returns any patterns whose \`finding_type\` matches this group's concerns — each a transformation that already passed a \`✗→✓\` proof on this repo or elsewhere in the fleet, with its \`remediation_hint\` + a \`before_example\`. Use a matching pattern as your STARTING POINT (it saves you rediscovering the approach), but ADAPT it to this repo's own resources — it is a prior, never a patch to paste. You MUST still run \`${t("terraform_verify_remediation")}\` to prove \`✗→✓\` here; a pattern is never blind-applied and never substitutes for the per-target proof. Returns an empty list (never an error) when memory is off or nothing matches — then fix from first principles as usual.

package/src/utils/config/payload.ts

@@ -137,6 +137,7 @@ export const Inputs = type({
   // org-repo | author | third-party). Structured scope, not prompt text — see
   // parseRefactorSource / withRefactorSource. Gates the behaviour-altering b.4.
   "refactor_source?": type.string.or("undefined"),
+  "refactor_examples?": type.string.or("undefined"),
   "review_instructions?": type.string.or("undefined"),
   "fp_filtering_instructions?": type.string.or("undefined"),
   "remediation_instructions?": type.string.or("undefined"),
@@ -237,6 +238,7 @@ function resolveNonPromptInputs() {
     registry_token: core.getInput("registry_token") || undefined,
     registry_host: core.getInput("registry_host") || undefined,
     refactor_source: core.getInput("refactor_source") || undefined,
+    refactor_examples: core.getInput("refactor_examples") || undefined,
     review_instructions: core.getInput("review_instructions") || undefined,
     fp_filtering_instructions: core.getInput("fp_filtering_instructions") || undefined,
     remediation_instructions: core.getInput("remediation_instructions") || undefined,
@@ -690,6 +692,8 @@ export function resolvePayload(
     // Refactor mode for the b.4 consent gate. undefined → auto. Action-input/
     // trusted-dispatch only (not the untrusted repo file).
     refactorSource,
+    // opt in to refactoring `examples/` roots, which Refactor leaves alone by default
+    refactorExamples: parseBooleanInput(inputs.refactor_examples),
     // a `@infraweaver fix …` command parsed from the triggering comment
     // body (the raw prompt), scoping the run to a specific concern/severity/file.
     // null when the prompt isn't a recognised command.