feat(memory): scope procedural memory by project

[jinliyl]

Background

ReMe currently records conversation memory into daily notes by date and identifies each source conversation with a stable session_id. Different coding projects normally produce different session IDs, so the daily layer does not need to be reorganized by project. However, a session ID alone does not preserve the project context known by coding-agent hosts such as QwenPaw, Codex, and Claude Code.

Without explicit project metadata, Auto Dream extracts changed daily notes globally and may consolidate project-specific operational experience into the same procedural-memory namespace. Similar procedures from unrelated repositories can then be merged or recalled across project boundaries.

This issue follows up on #374 with a narrower scope: preserve the existing daily/session layout and add project scoping only to procedural memory.

Proposed Changes

• Add optional project context to auto_memory and auto_memory_cc:
  • source_agent
  • project_name
  • project_path
• Normalize the project root and derive a stable, filename-safe project_id.
• Persist the project context in daily-note frontmatter while keeping the existing daily/<date>/<note>.md organization.
• Carry project context through Auto Dream extraction for procedure units.
• Store project-specific procedures under:
  • digest/procedure/projects/<project_id>/<slug>.md
• Keep existing flat procedure nodes as global procedures:
  • digest/procedure/<slug>.md
• Scope procedure deduplication and recall to the current project plus global procedures, excluding procedures from other projects.
• Update the QwenPaw, Codex, and Claude Code integrations to pass their current repository/project root when invoking memory recording.
• Preserve backward compatibility for callers that do not provide project context.

Expected Behavior

• Project-specific build steps, debugging experience, repository conventions, and runbooks remain isolated under the originating project.
• Procedures explicitly identified as reusable across projects may still be integrated into the existing global procedure namespace.
• Daily memory remains organized by date and session ID.
• digest/wiki/ remains a global knowledge namespace and does not gain project subdirectories.

Out of Scope

• Reorganizing daily notes by project.
• Adding project-specific namespaces under digest/wiki/.
• Treating project name alone as a stable identity; duplicate project names must remain distinguishable.

[chanyixialex]

Will the following three points be planned for in future versions?
Out of Scope
Reorganizing daily notes by project.
Adding project-specific namespaces under digest/wiki/.
Treating project name alone as a stable identity; duplicate project names must remain distinguishable.

[ployts]

Thanks for raising this and for detailing the proposal. Project-specific memory is a useful scenario, but we see two separate concepts here.

First, a ReMe workspace is intended to be the top-level boundary for tenant-level data ownership and isolation. If memories require hard isolation, they should generally be placed in separate workspaces.

Project-specific memory is closer to entity-targeted memory within a workspace. A project can be treated as one type of entity, alongside users, teams, repositories, agents, and other possible entities. In that model, memory can be associated with a target entity and selectively recalled for it, without making project a special storage-level concept.

Because of this, we would prefer to consider project scoping as part of a more general entity-targeted memory design rather than introduce a project-specific directory structure such as digest/procedure/projects/<project_id>/.

This broader abstraction still needs more discussion, especially around entity identity, global versus targeted memory, recall behavior, and backward compatibility. Therefore, we are not planning to implement the proposed project-specific procedure namespace at this stage. We can keep this issue as a reference and revisit it when the entity-targeted memory model becomes clearer.

[chanyixialex]

Regarding the Proposed Changes, will memory content continue to be written to the digest/procedure/.md directory? How can we determine whether it is written to the digest/procedure/ directory or the digest/procedure/projects/<project_id>/ directory?