feat(mount): by-state aliases + lazy GitHub materialization (issue #106 PR 3)

[khaliqgant]

Summary

Wave 3 of issue #106 mount layout improvements (stacked on PRs #115, #116, #117):

• by-state alias segment added to internal/mountfuse/layout.go with LayoutMarkdown + anchor-test coverage.
• Lazy GitHub materialization: mountfuse.LazyMaterializeCache (Mark/Wait/Resolve/Forget), FuseClient.LazyMaterialize delegation, and mountsync.LazyReposSkipsEagerFetchOfIssuesOnStartup gating with subtree-guard test.
• New tests: TestLazyMaterializeFiresOnceOnRepoStat, TestLazyMaterializeRetriesAfterError, TestLazyMaterializeNoOpWhenRemoteDoesNotImplement, TestFuseAliasByStateResolves, TestLazyReposOffStillFetchesIssues, TestIsUnderLazyGithubRepoSubtree.

Stack

This is the top of the wave-3 stack. Merge order: #115 → #116 → #117 → this.

Test plan

• go test ./internal/mountfuse/... ./internal/mountsync/... passes
• CodeRabbit review

[coderabbitai]

Warning

Rate limit exceeded

@khaliqgant has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 2 minutes and 30 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8a62e2cd-306f-4ebf-8b6a-ba041ca6f177

📥 Commits

Reviewing files that changed from the base of the PR and between 2fdc209 and 5a435fb.

📒 Files selected for processing (10)

• README.md
• internal/mountfuse/cache.go
• internal/mountfuse/client.go
• internal/mountfuse/dir.go
• internal/mountfuse/fs.go
• internal/mountfuse/fuse_test.go
• internal/mountfuse/layout.go
• internal/mountfuse/layout_test.go
• internal/mountsync/syncer.go
• internal/mountsync/syncer_test.go

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/106-mount-state-views-and-lazy-gh

---

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

[devin-ai-integration]

Devin Review found 1 potential issue.

View 5 additional findings in Devin Review.

[devin-ai-integration]

🔴 applyRemoteSnapshot deletes previously-tracked lazy-repo files during full pull

When lazyRepos is enabled, pullRemoteFullExport (internal/mountsync/syncer.go:1592) and pullRemoteFullTree (internal/mountsync/syncer.go:1647) both filter out files under github/repos/<owner>/<repo>/... from the remoteFiles map. However, applyRemoteSnapshot at lines 1709-1715 iterates all tracked state files and calls applyRemoteDelete for any path absent from remoteFiles. This means if a daemon previously tracked GitHub repo files (e.g., ran with LazyRepos: false), and is then restarted with LazyRepos: true, the next full pull will treat those tracked files as "deleted remotely" and remove them from disk and tracking state — even though they still exist on the server. The applyRemoteDelete function (internal/mountsync/syncer.go:2002-2031) deletes the local file if the hash matches and unconditionally removes the tracking entry.

(Refers to lines 1709-1715)

---

Was this helpful? React with 👍 or 👎 to provide feedback.