perf: add parallel processing to ListChanges and ListSpecs

[connerohnesorge]

Summary

Optimizes spectr list -I startup performance by adding parallel processing to change and spec listing operations.

Before: Sequential file I/O for each change/spec (O(m × n) complexity)
After: Concurrent goroutine processing (linear speedup on multi-core systems)

Changes

• Add parallel processing to ListChanges() and ListSpecs() using goroutines and channels
• Extract processChange() and processSpec() helper methods to reduce function complexity
• Maintain original ordering using indexed result collection
• Fix lint violations (return nil instead of empty slices)

Performance Impact

In repos with many changes, this provides immediate speedup:

• 100 changes × 5 specs each = 500+ file operations now run concurrently
• Speedup scales with number of CPU cores available

Testing

• ✅ All tests pass (go test ./...)
• ✅ Race detector clean (go test -race ./internal/list/...)
• ✅ Lint passes (nix develop -c lint)
• ✅ Output verified identical to sequential version

🤖 Generated with Claude Code

Summary by CodeRabbit

• Performance Improvements
  • Listing operations for changes and specifications are now processed concurrently, improving retrieval speed while maintaining consistent result ordering and error resilience.

[coderabbitai]

Walkthrough

Changes introduce parallel processing to ListChanges and ListSpecs functions using worker pools. Adds unexported helper functions processChange and processSpec for single-item processing, concurrent result collection via channels, and preserves original input ordering in returned slices.

Changes

Cohort / File(s)

Summary

Parallel Processing Infrastructure internal/list/lister.go

Introduces concurrent processing for both ListChanges and ListSpecs using sync.WaitGroup and result channels. Adds unexported helper functions processChange() and processSpec() that extract title, compute counts (deltas, tasks, requirements), and handle fallback defaults. New result types (changeResult, specResult) maintain ordering by input index. Imports sync package. Refactors both methods to use discovery service queries followed by parallel worker pool execution.

Sequence Diagram(s)

sequenceDiagram
    participant Caller
    participant ListChanges/ListSpecs
    participant Discovery
    participant WorkerPool
    participant Parsers
    participant ResultCollector

    Caller->>ListChanges/ListSpecs: ListChanges/ListSpecs()
    ListChanges/ListSpecs->>Discovery: GetActiveChanges/GetSpecs(projectPath)
    Discovery-->>ListChanges/ListSpecs: IDs []string
    
    Note over ListChanges/ListSpecs: Create WaitGroup<br/>& results channel
    
    par Parallel Processing
        loop For each ID
            ListChanges/ListSpecs->>WorkerPool: processChange/processSpec(ID, index)
            WorkerPool->>Parsers: ExtractTitle()<br/>CountDeltas/Tasks/Requirements()
            Parsers-->>WorkerPool: computed values
            WorkerPool->>ResultCollector: send result{ID, index, info}
        end
    end
    
    ResultCollector->>ListChanges/ListSpecs: all results collected
    ListChanges/ListSpecs->>ListChanges/ListSpecs: sort by original index
    ListChanges/ListSpecs-->>Caller: ordered slice of Info

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: adding parallel processing to ListChanges and ListSpecs functions.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch perf/parallel-list-processing

Important

Action Needed: IP Allowlist Update

If your organization protects your Git platform with IP whitelisting, please add the new CodeRabbit IP address to your allowlist:

• ✨ 136.113.208.247/32 (new)
• 34.170.211.100/32
• 35.222.179.152/32

Failure to add the new IP will result in interrupted reviews.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}