Skip to content

fix(project): unify project resolution across clients and transports #689

Description

@j0k3r-dev-rgl

📋 Pre-flight Checks

  • I have searched existing issues and this is not a duplicate
  • I understand this issue needs status:approved before a PR can be opened

📝 Bug Description

Engram resolves the active project differently depending on the transport or first-party client. The canonical filesystem/Git/.engram/config.json detector exists in internal/project, but the complete policy for explicit selection, sessions, process defaults, store validation, global scope, and ambiguity recovery is coupled to MCP handlers.

This creates observable cross-client inconsistencies:

  • MCP applies the richest project-resolution policy.
  • HTTP treats an omitted project as global scope in multiple routes.
  • CLI search is global without a project selector, and CLI save can persist an empty project.
  • Pi native detects a project for context but does not apply it to mem_search when project is omitted.
  • Claude Code, Codex, and OpenCode duplicate simplified Git/basename detection and can diverge from .engram/config.json and canonical ambiguity handling.

🔄 Steps to Reproduce

  1. Use a repository where canonical project detection matters, such as one configured through .engram/config.json, a worktree, or an ambiguous basename.
  2. Run equivalent omitted-project operations through MCP, HTTP, CLI, and Pi native.
  3. Compare the selected scope and project used by each path.
  4. Run the Claude Code, Codex, or OpenCode adapters from the same repository.
  5. Observe that equivalent requests can resolve to different projects or to global scope depending on the transport/client.

✅ Expected Behavior

All first-party transports and clients should share one explicit project-resolution contract:

  1. An explicit project selector takes precedence.
  2. Global/all-project scope is requested explicitly with a structured selector, not a magic project name.
  3. When neither is supplied, Engram resolves the current project using one canonical policy.
  4. MCP, HTTP, CLI, Pi native, Claude Code, Codex, and OpenCode expose consistent precedence, validation, ambiguity, and error behavior.
  5. Adapters provide trusted context but do not independently reimplement Git/configuration/project detection.

❌ Actual Behavior

Resolution policy is fragmented. MCP contains policy unavailable to HTTP and CLI, Pi native search can become global despite detecting a project, and several adapters maintain their own simplified detectors. Equivalent user actions therefore have transport-dependent scope and project identity.

Operating System

Linux (Arch/Manjaro)

Engram Version

Development revision 509e676

Agent / Client

Other — cross-client: MCP, HTTP, CLI, Pi native, Claude Code, Codex, and OpenCode

📋 Relevant Logs

No single runtime error is emitted; the defect is inconsistent project selection and query scope across equivalent client operations.

💡 Additional Context

Proposed implementation boundary

  • Extract a transport-neutral resolver in Go.
  • Define explicit project, auto/current project, and all-project scope as separate structured concepts.
  • Migrate MCP first, then HTTP and CLI, followed by Pi native.
  • Thin Claude Code, Codex, and OpenCode adapters so they delegate canonical resolution rather than duplicate it.
  • Preserve compatibility intentionally and add cross-transport parity tests.

Related issues

Historical precedents include #303, #312, #280, and #345.

Acceptance criteria

  • A shared Go resolver owns precedence, validation, ambiguity, and scope semantics.
  • Omitted project and explicit all-project scope are not conflated.
  • MCP, HTTP, and CLI use the shared resolver.
  • Pi-native search and context resolve omitted projects consistently.
  • Claude Code, Codex, and OpenCode no longer own divergent project-detection policy.
  • Focused unit tests cover resolver precedence and errors.
  • Cross-transport/client tests demonstrate parity for explicit, inferred, global, configured, worktree, and ambiguous cases.
  • Compatibility and migration behavior are documented.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions