## TL;DR

Projects accumulate backup copies (model.sql.bak, copy_of_model.sql, files in backup folders), and an agent that searches by name can edit the wrong one. Identify the live file (the one inside the configured model paths with the exact model name), apply the fix there, and remove or quarantine backups inside the project tree so they cannot be mistaken for live code or parsed as duplicate models.

```text
agent applied the fix to the backup copy of the model, not the live file
```

## Use this when

- an agent fix has no effect and a similarly named backup file shows a fresh modification time
- the project tree contains .bak, copy, or old versions of model files
- dbt previously warned about duplicate resource names from stray copies

## Not for this skill when

- the live file was edited and the logic is wrong, debug the logic
- the backup lives outside the dbt project paths and cannot be parsed, it is messy but not the cause
- two live models share a name in different folders, that duplicate must be resolved as its own issue

## Steps

1. List candidate files: find every file whose name matches the model across the repo, including backups, and note which one sits in the model-paths configured in dbt_project.yml.
   Verify: you have the candidate list and the live file identified by path config.

2. Confirm with the manifest: check the model original_file_path in target/manifest.json; that is the file dbt compiled.
   Verify: manifest original_file_path names the live file.

3. Apply the agent fix to the live file (port the diff from the backup copy), and run dbt compile --select for the model to see the change in compiled SQL.
   Verify: compiled SQL reflects the fix.

4. Clean up: move backup copies out of the project tree or delete them if version control holds the history, then run dbt parse to confirm no duplicate resource warnings remain.
   Verify: parse is clean and only live files remain in the project paths.

## Variant phrasings

### agent created the backup itself
Some agents snapshot before editing and then edit the snapshot. Fix the agent procedure: snapshot outside the project tree, edit the original path.

### backup inside models folder with .sql extension
A .sql backup inside models/ is not a backup to dbt; it is another model. Rename patterns that keep .sql inside model paths will keep biting.

Compatibility: dbt-core project structure: model-paths in dbt_project.yml and manifest original_file_path. Version control is the backup system; in-tree copies are hazards.

## Why it happens

dbt does not know which file you meant; it compiles exactly the files under its configured paths matching resource rules. Backup copies either sit outside those paths (invisible, so edits there do nothing) or inside them (parsed as resources, causing duplicates). Agents pick by filename similarity, which cannot distinguish these cases; only path config and the manifest can.

## Edge cases / pitfalls

- After cleanup, rerun the full test suite for the model; the ported fix was never actually exercised before.
- Add backup and copy patterns to your ignore rules for agent tooling, and lint the repo for stray .sql files in models/.
- If the backup held the only copy of some logic, port deliberately with a diff review, not a blind overwrite.

## Provenance

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