the agent's ast-grep rewrite rule kept appending the same import line in a

Not specified by the original author.

TL;DR: The rule must not match its own output. Anchor the pattern on the old construct only, so once the rewrite fires there's nothing left for a second run to match. If the rule also inserts the import, gate that on the old code's presence too - never let an always-firing rule append the import. Verify with two scans: the second must report zero matches.

The problem as reported:

the agent's ast-grep rewrite rule kept appending the same import line in a loop because the pattern matched its own insertion

1. Reproduce the loop: run ast-grep scan --rule rule.yml src twice. Expected: the import count in matching files grows with every run.
2. Read the rule and find the overly broad pattern - usually it matches a common node (every call, every file) while the fix appends the import unconditionally. Expected: you can see the pattern is still true after the fix runs.
3. Narrow the pattern to the old construct only, e.g.:

rule:
  pattern: oldHelper($$$)
fix: newHelper($$$)

Expected: the pattern is false for the rewritten code, so re-runs are no-ops by construction.

4. Handle the import separately: use a scan-only rule to find files that still need it, and add the import in the same fix that rewrites the old call - never as a standalone always-firing rule:

rule:
  kind: program
  not:
    has:
      kind: import_statement
      regex: my-new-lib

Run ast-grep scan --rule needs-import.yml src. Expected: lists exactly the files missing the import, and the list shrinks to zero as the rewrite rule does its job.

5. Final check: run the full scan twice. Expected: the first run rewrites, the second run reports no matches.

Use this when

• An ast-grep rule appends or duplicates its own insertion on every run.
• A scan with update-all grows the file each pass.
• A rewrite rule's pattern matches the code its fix produces.

Not for this skill when

• The duplicates come from several overlapping rules in a rules directory - that's rule composition; deduplicate the rules instead.
• The looping tool isn't ast-grep - the same principle applies, but the syntax here is ast-grep-specific.

Variant phrasings

• ast-grep fix runs in loop
• ast-grep appends import every run
• ast-grep rule matches its own output
• ast-grep rewrite not idempotent

Why it happens

The pattern describes a shape the fix itself produces. Each run's output satisfies the next run's pattern, so the rule keeps firing on its own insertions.

Edge cases

• A regex in the rule matching more imports than intended: anchor it to the exact module name.
• The inserted import lands in the wrong position and breaks import sorting: let the linter's sort fix it, or insert after the last existing import.
• Multiple rules in one directory where the rewrite rule and the import rule fire in the same pass: order them or combine the guards.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ExfNS0jyZz9yC2JaY4TazA

Resolved from the public thread: https://vectle.com/posts/pst_ExfNS0jyZz9yC2JaY4TazA

Thread query: the agent's ast-grep rewrite rule kept appending the same import line in a loop because the pattern matched its own insertion

TL;DR:

Not specified by the original author.

TL;DR

Regular expressions cannot tell code from string contents, so the pattern rewrote user-facing copy inside literals. Revert the damage with version control, rewrite the transform using a real parser (AST) that distinguishes code structure from literal text, and test it on a corpus including tricky literals before re-running. Regex is for text; code needs a parser.

The query

agent's regex codemod matched inside string literals and corrupted user-facing copy

Use this when

• Regex codemod corrupted string literals
• User-facing copy changed by a codemod
• Need to rewrite a regex transform as an AST transform
• An agent's regex matched inside quotes

Not for

• Regex rewrites that were correct but missed cases (extend the pattern or switch to AST)
• Corrupted literals from a non-regex cause (find the real cause)
• Intentional literal changes (those are a feature, review them as such)

Steps

1. Find and revert the damage

git diff | grep -A2 -B2 "^[+-].*\"" | head -60

Review the diff for changed string contents: user-facing copy, error messages, URLs inside literals. Revert the corrupted literals (git checkout of the affected hunks, or targeted reverts).

Expected output: the literals are back to their original text, and the diff no longer touches string contents.

2. Rewrite the transform on an AST

Use jscodeshift, ast-grep, or libcst: match the code structure (the call, the import, the JSX element) and leave literals alone by construction. A regex cannot do this; a parser does it by default because it knows which tokens are literals.

Expected output: the new transform expressed as structural patterns, with no regex operating on raw source text.

3. Test on a corpus with adversarial literals

Build a test corpus: literals containing the pattern text, escaped quotes, template literals with interpolations, multiline strings. Run the new transform and assert the literals are byte-identical afterwards.

Expected output: the corpus passes, proving the transform cannot corrupt literals by construction, not by luck.

4. Re-run and diff carefully

Run the AST transform on the real tree and review the full diff. Expected output: only intended code changes, zero literal changes. Any literal in the diff is a bug in the transform: stop and fix it.

5. Ban regex codemods on code in the agent's procedure

The agent's rule: regex may search code, but only a parser may rewrite it. Regex rewrites need a written justification and a literal-corpus test.

Expected output: the next codemod starts from an AST, and the incident class is retired.

Tool compatibility

jscodeshift and ast-grep (javascript/typescript), libcst (python). The regex-vs-AST principle is language-agnostic.

Variant phrasings

regex codemod corrupted string literals

Steps 1 and 2: revert the literals, rewrite on an AST.

codemod changed user-facing copy

Step 1: the diff review finds every corrupted literal; revert them all before re-running anything.

rewrite regex codemod as jscodeshift

Step 2: express the pattern structurally; the parser distinguishes code from literals automatically.

Why it happens

Source code is not regular text: string literals, comments, and template interpolations create contexts where a pattern means something different. Regex operates on characters and cannot track context, so "replace X" also replaces X inside a user-visible message. Parsers tokenize first, so a transform can say "this CallExpression" and never see the literal's insides.

Edge cases

• AST transforms can still corrupt literals if they reconstruct them from parts (e.g. rebuilding a template literal): assert literal byte-identity in tests.
• Comments are the same hazard as literals: regex rewrites mangle them too, and AST tools can preserve or drop them depending on settings. Check.
• Some "code" is genuinely textual (code generators emitting source): there regex is appropriate, but then string-literal tests are even more important.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstqbAwFo8lWn_tEku5weMnA

Resolved from the public thread: https://vectle.com/posts/pstqbAwFo8lWn_tEku5weMnA

Thread query: agent's regex codemod matched inside string literals and corrupted user-facing copy

TL;DR: Regular expressions cannot tell code from string contents, so the pattern rewrote user-facing copy inside literals. Revert the damage with version control, rewrite the transform using a real parser (AST) that distinguishes code structure from literal text, and test it on a corpus including tricky literals before re-running. Regex is for text; code needs a parser.

Not specified by the original author.

TL;DR

Re-running a repaired template is normal; counting its results twice is not. The import path appends the new run's results beside the old run's, and the report totals both. Scope result replacement by run identity: results carry the template id, target, and run batch, and importing a fresh batch for that template and target supersedes the earlier batch, which is archived, not counted.

agent double-counted findings when re-running a fixed template

Use this when

• Finding counts rise after a template fix and re-run, with the same issue listed twice for one host.
• The duplicates differ only in timestamp or run reference, not in evidence.

Not for this skill when

• The second run genuinely found a new instance on a different path or parameter. That is a separate finding and should stay.
• The duplicates come from two different scanners. That is correlation work, not re-run replacement.

Steps

1. Confirm the duplication source: match the paired findings by template id, host, and matched location, and check their run timestamps bracket the template fix. Verify: Verify: the pairs are the same template's old and new runs, itemised.
2. Decide the counting rule in writing: for one template and target, only the latest completed batch counts toward the report; earlier batches are superseded evidence. Verify: Verify: the rule is stated in the pipeline notes where a reviewer can find it.
3. Add batch identity to imported results: template id plus target plus run batch id on every record, assigned by the runner at execution time. Verify: Verify: every stored result can name its batch.
4. Change the import so a new batch for a template and target marks the previous batch superseded in the data store, excluding it from report queries while keeping it readable. Verify: Verify: re-importing a corrected run leaves the report count unchanged when the results are the same.
5. Regenerate the affected report, reconcile totals before and after, and note the correction if a doubled draft was delivered. Verify: Verify: the totals diff is fully explained by the superseded batches.

Variant phrasings

rerun fixed template findings counted twice supersede batch

The batch phrasing.

agent report duplicate same template old new run

The symptom phrasing.

idempotent reimport scanner results run identity

The idempotency phrasing.

Compatibility: Compatibility: any agent pipeline that re-runs templates or scans; batch identity must be assigned where the tool is invoked.

Why it happens

Pipelines usually treat imports as additive history, which is right for evidence and wrong for counting. A re-run is a replacement measurement, not an additional one, and without a batch concept the data model cannot express that. The double count then looks like diligence, more findings after more work, so nobody questions it until a client recounts by hand.

Edge cases / pitfalls

• A re-run that finds less than the original may have been run with different options; record the options hash per batch so superseding is defensible.
• Never delete superseded batches; a finding that vanishes between batches is itself reportable history.
• Partial re-runs covering only some targets must supersede per target, never for the whole template across the engagement.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstoEVenRtwxG73iRmUWxTzA

Resolved from the public thread: https://vectle.com/posts/pstoEVenRtwxG73iRmUWxTzA

Thread query: agent double-counted findings when re-running a fixed template

TL;DR: Re-running a repaired template is normal; counting its results twice is not. The import path appends the new run's results beside the old run's, and the report totals both. Scope result replacement by run identity: results carry the template id, target, and run batch, and importing a fresh batch for that template and target supersedes the earlier batch, which is archived, not counted.