feat: support recursive worktree list and status - #28
patrickleet wants to merge 2 commits into
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (6)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughList and status now accept recursive options. Recursive mode discovers nested repositories and propagates discovery and status errors. Integration tests cover recursive and non-recursive results, including malformed nested Git files. ChangesRecursive worktree commands
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Feature Sequence Diagram(s)sequenceDiagram
participant Protocol
participant WorktreeDispatcher
participant handle_list
participant handle_status
participant RecursiveRepositoryDiscovery
participant git_status_summary
participant JSONResponse
Protocol->>WorktreeDispatcher: Request recursive list or status
alt List request
WorktreeDispatcher->>handle_list: Pass list arguments with recursive option
handle_list->>RecursiveRepositoryDiscovery: Discover repositories recursively
RecursiveRepositoryDiscovery-->>handle_list: Return discovered repositories
handle_list->>git_status_summary: Read repository status
git_status_summary-->>handle_list: Return status or error
handle_list->>JSONResponse: Return list result or error
else Status request
WorktreeDispatcher->>handle_status: Pass status arguments with recursive option
handle_status->>RecursiveRepositoryDiscovery: Discover repositories recursively
RecursiveRepositoryDiscovery-->>handle_status: Return discovered repositories
handle_status->>git_status_summary: Read repository status
git_status_summary-->>handle_status: Return status or error
handle_status->>JSONResponse: Return status result or error
end
Merge Risk: ⚪ Minimal · up to No confirmed issue blocks merging. The behavior when the configured worktree root is missing remains unverified. Security Architecture ReviewSecurity architecture risk: 🔵 Low · up to Recursive inventory is opt-in and reports failures rather than presenting incomplete results as clean. A malformed nested checkout can nevertheless prevent a full list from being returned. The new discovery implementation was not available for verification. Retained concerns
Security review detailsSecurity Blast Radius
Security Findings and Attack Paths
Trust Boundaries and Controls
Resilience and Maintainability Implications
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 28.57% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 7 functions across 5 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
A rabbit hops where worktrees nest Comment |
|
Addressed the docstring coverage warning in b5a0dd1 and added a public protocol regression for the previously unverified missing-root behavior: list returns an empty inventory; named status fails, in both default and recursive modes. No actionable inline comments were present. Combined with the companion API fixes in meta_cli c8c87ab: 581 workspace tests passed, Clippy with -D warnings and formatting passed. Aggregate-list failure containment remains the explicitly documented contract; named status isolates a single set. |
Change
Wire the host's existing recursive protocol option into worktree list/status, add
-r/--recursivehelp and parsing, use the new discovery API, propagate recursive observation failures, and add usage documentation and public plugin regression coverage.Merge order
Depends on the meta_cli API PR #33. Merge that first. This branch uses the new sibling path-dependency API and cannot build against the old meta_cli checkout. Release/build both updated repos together.
Why merge
Meta creates nested worktree members (for example root → open-source → atc), but legacy inventory stops at the parent worktree. This makes a successfully created child invisible to inventory consumers, including the planned ATC badge. Explicit recursive discovery supplies actual realized members without treating the configured project graph as realized checkouts.
Before / after
For a fixture with root, open-source, open-source/atc, and other/atc:
.,open-source,other/atc.,open-source,other/atc(flag ignored).,open-source,open-source/atc,other/atcExample usage (with both PRs)
Compatibility and safety
listfails when any set is broken;status NAMEisolates the selected set. Callers should impose a subprocess timeout and represent failures as unknown.Testing
Executed on macOS against both PR branches in the same Meta workspace:
cargo test --workspace: 581 passed, 0 failed, 0 ignored.cargo clippy --workspace --all-targets -- -D warnings: passed.cargo fmt --all -- --check: passed.Tracks [[tasks/harmony-1932]], prerequisite for [[tasks/harmony-1918]].
Summary by CodeRabbit
--recursive(-r) option for listing worktrees and checking their status, including repositories nested beneath other repositories.Review follow-up verification
CodeRabbit findings addressed: relative Git links resolve at the checkout; recursive discovery validates admin metadata and backlinks; fixtures use real worktrees. Added missing-root public protocol coverage and function documentation. Latest combined workspace run: 581 passed, zero failed; Clippy and formatting pass.