Build local graphs for registry-supported files

[Iron-Ham]

Summary

• Replace the local graph source-file allowlist with parser-registry based filtering.
• Add bounded content detection for fallback candidates so extensionless shebang/modeline files can enter graph builds without full reads of large unknown files.
• Add regressions for Swift/Terraform graph metadata and extensionless content-detected files.

Closes #11

Test plan

• rustfmt --check crates/inspect-core/src/analyze.rs
• git diff --check --no-ext-diff
• cargo test -p inspect-core
• cargo test -p inspect-cli
• cargo build -p inspect-cli
• Reproduced Swift/Terraform inspect diff and inspect predict against a temp repo; verified graph file/entity counts, line spans, Swift dependent metadata, and caller predicted at risk.
• Reproduced extensionless Python inspect diff and inspect predict against a temp repo; verified graph file/entity counts, line spans, dependent metadata, and caller predicted at risk.

Review

• Read-only reviewer subagent found no blockers on the final diff.

[vercel]

@Iron-Ham is attempting to deploy a commit to the rs545837's projects Team on Vercel.

A member of the Team first needs to authorize it.

[inspect-review]

inspect review

Triage: 10 entities analyzed | 0 critical, 0 high, 4 medium, 6 low
Verdict: standard_review

Findings (2)

1. [low] In read_content_detection_sample, seeking to a negative offset from end will fail for files smaller than CONTENT_DETECTION_SAMPLE_BYTES. The function checks if file_len <= (CONTENT_DETECTION_SAMPLE_BYTES * 2) but then seeks to -(CONTENT_DETECTION_SAMPLE_BYTES as i64) from end, which will be negative and fail for files between CONTENT_DETECTION_SAMPLE_BYTES and CONTENT_DETECTION_SAMPLE_BYTES * 2 bytes.
2. [low] In read_content_detection_sample, seeking from end with negative offset can fail for files smaller than CONTENT_DETECTION_SAMPLE_BYTES. The function checks if file_len <= (CONTENT_DETECTION_SAMPLE_BYTES * 2) and reads the whole file, but for files between CONTENT_DETECTION_SAMPLE_BYTES and CONTENT_DETECTION_SAMPLE_BYTES * 2, it will try to seek to a negative position from the end that's beyond the file start.

---

Reviewed by inspect | Entity-level triage found 0 high-risk changes

[rs545837]

Merged #20 and #23 — the rest (#18, #19, #21, #22, #24, #25) all have merge conflicts now since they touch overlapping areas in analyze.rs and llm.rs. Could you rebase these against main? Happy to merge them once the conflicts are resolved.

[inspect-review]

inspect review

Triage: 10 entities analyzed | 0 critical, 0 high, 4 medium, 6 low
Verdict: standard_review

Findings (2)

1. [low] File I/O bug in read_content_detection_sample: seeking to negative offset will fail for files smaller than CONTENT_DETECTION_SAMPLE_BYTES. The function checks if file_len <= (CONTENT_DETECTION_SAMPLE_BYTES * 2) but then seeks to End(-(CONTENT_DETECTION_SAMPLE_BYTES as i64)) which will be negative for files between CONTENT_DETECTION_SAMPLE_BYTES and CONTENT_DETECTION_SAMPLE_BYTES * 2 bytes.
2. [low] In read_content_detection_sample, seeking to a negative offset from the end of the file will fail for files smaller than CONTENT_DETECTION_SAMPLE_BYTES but larger than CONTENT_DETECTION_SAMPLE_BYTES * 2. The function checks if file_len <= (CONTENT_DETECTION_SAMPLE_BYTES * 2) but then seeks to -(CONTENT_DETECTION_SAMPLE_BYTES as i64) from the end. For a file of size CONTENT_DETECTION_SAMPLE_BYTES * 2 + 1, it reads CONTENT_DETECTION_SAMPLE_BYTES from the start, then seeks to position CONTENT_DETECTION_SAMPLE_BYTES + 1 from the start, potentially reading overlapping or incorrect data.

---

Reviewed by inspect | Entity-level triage found 0 high-risk changes

[rs545837]

Merged #19 and #22 — this one and #21, #24, #25 need rebasing against main now. Suggest rebase order: #18 → #21 → #24 → #25 since they all touch analyze.rs.

From next time it would be great if you can tackle things under one PR, will be easier on both our end.

[inspect-review]

inspect review

Triage: 17 entities analyzed | 0 critical, 0 high, 10 medium, 7 low
Verdict: standard_review

Findings (5)

1. [low] In materialize_source_files, the recursive call passes registry parameter but the function signature in the BEFORE version doesn't have this parameter. This will cause a compilation error if any code path still uses the old signature.
2. [low] In materialize_index_source, the function now filters files using is_noise_file(path) instead of !is_source_file(path). However, is_noise_file and is_source_file are not inverse operations - a file could be neither noise nor a recognized source file. This changes the filtering logic and may incorrectly include files that were previously excluded.
3. [low] In materialize_source_files, the condition changed from Some(ObjectType::Blob) if is_source_file(&path) to Some(ObjectType::Blob) if !is_noise_file(&path). This is not a safe replacement because !is_noise_file is not equivalent to is_source_file - files that are neither noise nor recognized source files will now be processed when they shouldn't be.
4. [low] In content_detection_sample_from_bytes, when content length is exactly sample_bytes, the function returns the full content. However, sample_bytes is defined as CONTENT_DETECTION_SAMPLE_BYTES * 2, so files exactly that size will be fully read instead of sampled, which contradicts the sampling logic.
5. [low] In read_content_detection_sample, the function seeks to -(CONTENT_DETECTION_SAMPLE_BYTES as i64) from the end, but doesn't verify that the file is large enough. If the file is exactly CONTENT_DETECTION_SAMPLE_BYTES * 2 + 1 bytes, this could seek to a position that overlaps with already-read head bytes, causing duplicate data in the sample.

---

Reviewed by inspect | Entity-level triage found 0 high-risk changes