COR-2000: update default exlude globs

[leenk7991]

Description

Stop excluding **/migrations/** from the default zip globs so CLI uploads include migration paths. Fusion still decides whether those files are scanned (IGNORE_PATHS + project include rules).

Related Issues

COR-2000

Depends on Fusion + Doghouse COR-2000 (include rules / tighter migration globs). Deploy those first; otherwise uploaded migration files are still skipped.

Type of Change

• Bug fix

Testing

• Unit tests added/updated
• Manual testing completed

Test Results:

• GET /api/v1/scan-settings?project_name=<project> returns include_paths / ignore_paths for that project
• No project include rule: migrations/ is in the zip, Fusion still skips it (file log: skipped)
• Path with “migration” in the name (e.g. onetru-data-migration/) scans with no include rule
• Project include **/migrations/** + corgea scan --project-name … --disable-incremental: migrations/0001_users.py scanned
• Incremental after adding that include can hide the file (diffs an older baseline). --disable-incremental (or Doghouse latest-scan fallback) analyzes it
• No project include: corgea scan --disable-incremental --include 'migrations/**' prints Force-including 1 file(s)… and scans the file
• Project ignore + CLI --include: ignored file stays skipped (ignore wins). No CLI warning today
• --include is only on corgea scan (this branch). Wrong binary: unexpected argument '--include' found

[corgea-security]

Automated review risk: 2/5.

Low-risk configuration change that includes migration files in scanning. No actionable defect is provable from the supplied diff.

No critical or high-priority changes were found.

[corgea-security]

Approved by Dennis: high policy risk and automated risk 2/5.

[cursor]

Stale comment

The CLI slice for COR-2000 is the right one-line change: blast.rs zips with exclude_globs: None, so removing **/migrations/** is what actually puts migration paths in the upload. Fusion IGNORE_PATHS still skip them until include rules exist; --exclude remains the opt-in for the old zip.

The merge gap is that this behavior is untested. The unit test named in the PR body does not use DEFAULT_EXCLUDE_GLOBS and would still pass if the glob were put back. See inline — two assertions on the existing glob-set test pin it.

Verified, not blocking: only production caller; remaining default globs intact; incremental still uploads the whole archive; CLI-first rollout only adds ignored zip entries until Fusion/Doghouse include rules land.

  

_{Sent by Cursor Automation: pr-flow}

[cursor]

Prior finding is closed. ab8e1cc pins the COR-2000 behavior on default_exclude_globs_match_abs_tmp_but_not_repo_relative_paths with:

assert!(!set.is_match(Path::new("migrations/0001_initial.py")));
assert!(!set.is_match(Path::new("app/migrations/0001_initial.py")));

Those assertions fail if **/migrations/** is restored, and they use the same repo-relative path shape as create_zip_from_target (glob_set.is_match(&relative_path)).

No remaining merge blockers in this slice. Rechecked on ab8e1cc vs merge-base c6cd678:

• Only DEFAULT_EXCLUDE_GLOBS in src/utils/generic.rs changed; blast.rs still zips with exclude_globs: None.
• Incremental does not re-filter that list; the archive is still the whole project.
• --exclude is still the opt-in for the old zip.
• Remaining default globs are unchanged; **/tmp/** does not drop repo-relative migrations/.

Fusion IGNORE_PATHS + include rules still decide what gets scanned, as the PR body states. cargo test --lib could not be run here (crates.io time-core 0.1.8 needs edition2024 / newer cargo than this image's 1.83.0) — not a PR defect.

  

_{Sent by Cursor Automation: pr-flow}

[juangaitanv]

lgtm