feat: allow extensions to declare project-scoped cache mounts

[tortmayr]

What it does

The persistent per-project package caches were hard-coded in addCacheMounts, so extensions had no way to persist their own directories — a java-dev feature, for example, re-downloads the whole Maven repository in every fresh container.

• Add a declarative caches field to extension specs (kind: sandbox and kind: mixin): each entry names a subdirectory under the enclave-managed project cache dir and a container target inside $HOME — a spec can never name a host path
• At session start, entries from the tool spec and the enabled features join the built-in list in addCacheMounts, respecting --no-cache
• Validate at load time: targets are cleaned, traversal-free, inside the container home, and must not collide with built-in cache names/targets or reserved mounts (auth stores, shell history)
• Validate across extensions at session start: identical name+target declarations dedupe; the same name with a different target — or the same target under a different name — fails with an error naming both claimants
• Surface declared caches in the capability summary and update diff shown by enclave features|tools add
• Document the caches field, including that an empty cache mount shadows image-baked content at the target (seed from feature-entrypoint.d, as node-dev does for nvm)

Fixes #82

How to test

make build && make test && make lint

• Declare a cache in a feature spec, e.g. in extensions/features/devtools/spec.yaml:

  caches:
    - name: m2
      target: .m2/repository

• Start a session and verify ~/.cache/enclave/<tool>/<project-hash>/m2 exists on the host and is mounted at ~/.m2/repository in the container; files written there survive a fresh container

• --no-cache starts the session without the mount

• Two features declaring the same name with different targets fail session start with an error naming both features

• enclave features add against an extension repo with a caches entry lists it in the capability summary

• Verified locally: make build, make test, make lint, make check-license-headers

Follow-ups

Migrate the feature-specific built-in entries (nvm, uv, pip, pnpm, yarn) into their features' specs, keeping the same name values so existing host cache directories stay valid.

Breaking changes

• This PR introduces breaking changes and has been coordinated with maintainers.

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the contribution guidelines.

[EclipseSourceAI]

Note

Autonomous AI review.

This review was done by an AI agent and therefore may contain mistakes. Feel free to ignore any comment you disagree with. A thumbs-down reaction on a comment marks it as rejected for follow-up reviews. Noting why in a reply helps, since replies are read too.

Resolving all AI comments does not lead to an automatic approval. A maintainer still needs to review and sign off on the overall architecture and design.

To get an updated review after pushing changes, a maintainer may re-request a review from this account.

Running in Eclipse Enclave, submitted via review-guard-mcp

Adds a declarative caches field to tool and feature specs so extensions can persist directories of the container home per project, replacing the hard-coded list in addCacheMounts with model.BuiltinProjectCaches plus spec-declared entries.

The approach looks sound: specs only name a cache subdirectory and a $HOME-relative target (never a host path), per-spec validation happens at load (validateAndNormalizeCaches), cross-extension conflicts are resolved at session start (projectCaches), and the new entries show up in the features|tools add capability summary and diff. Refactoring the shell-history, SSH, and home-config-file paths into model constants so they can serve as reserved targets is a reasonable side effect rather than an unrelated drive-by. Tests cover the load-time rules, the dedupe/conflict matrix, and --no-cache, and go build plus the tests for the touched packages pass here.

Worth a closer look:

• CacheTargetsOverlap reimplements util.PathWithin because model cannot import util, which suggests the helper and the built-in list belong in config.
• Feature-declared caches are keyed per tool, so a tool-independent feature cache (the motivating Maven case) is duplicated across tools in one project.
• docs/ARCHITECTURE.md still documents the cache directory as a fixed list.

Nothing blocking found in the validation logic itself. The reserved-target set covers the auth stores, shell history, SSH mount, home config files, and built-in caches, and the tool config/memory store targets are checked at session start, which closes the collisions that would otherwise surface as raw container-start errors.

[EclipseSourceAI]

Note

Autonomous AI review.

This review was done by an AI agent and therefore may contain mistakes. Feel free to ignore any comment you disagree with. A thumbs-down reaction on a comment marks it as rejected for follow-up reviews. Noting why in a reply helps, since replies are read too.

Resolving all AI comments does not lead to an automatic approval. A maintainer still needs to review and sign off on the overall architecture and design.

To get an updated review after pushing changes, a maintainer may re-request a review from this account.

Running in Eclipse Enclave, submitted via review-guard-mcp

Follow-up review. The only change since my last pass (238157f → 0e0f6e3) is the refactor addressing my earlier comments: CacheTargetsOverlap/BuiltinProjectCaches moved from model to config, the cache-mount logic moved from runtime.go into cache_mounts.go, and docs/ARCHITECTURE.md now lists nvm/ and points at extension-declared caches. I checked the diff and it's a clean move, go build and the runtime/config/model tests pass. No new issues found.

These previous comments can be resolved as they are now handled:

• move CacheTargetsOverlap/BuiltinProjectCaches into config
• split cache-mount logic into its own cache_mounts.go file
• document nvm/ and extension-declared caches in ARCHITECTURE.md

I can't resolve them myself as I would need write permission on this repository.