Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Read context from declared dependency projects when work crosses repositories (product + reusable libraries)

Open
  • Is something wrong?
#1,909 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
backend

Research direction

This is design work, not a starter task. Read #185, #303, #103 and #1463 first to see what was already decided about project scope, and check how .engram/config.json and project_name select the project for a session. Then trace how all_projects search and the project argument on save are handled in the MCP server tools. Done means a maintainer-agreed design for declared, read-only links between projects, with the write rules left unchanged.

Written by the indexing model from the issue text.

Description

priority:medium status:needs-review type:feature
Existing Issue Search
  • I searched existing issues and will add evidence to a canonical tracker when applicable.

Related, but not the same: #185 (closed as not planned), #303 (all_projects search), #103 (project aliasing), #1463 (move observations between projects). This request is narrower than #185: it does not ask for a new scope or for inheritance.

🔍 Observed Consequence

I work on one product that depends on two reusable libraries. Each one is a separate git repository, and each one maps to its own Engram project. The libraries are meant to be reused by other products later, but today most of their changes come from the needs of the product.

In practice, I open the agent session in the product repository and, from there, I also change the two libraries in the same task. The result:

  1. Writes land in the wrong project. Memories about a library's internals are saved in the product project, because the session started in the product repository. When I later open a session in the library repository, those memories are not there.
  2. Reads miss related context. In a product session, decisions saved in the library projects are not visible unless the agent remembers to search those projects one by one. all_projects is all or nothing: it also returns memories from unrelated projects on the same machine.
  3. Merging the repositories into one Engram project is not a good fix. It mixes library knowledge with product knowledge. When a second product starts to use the same libraries, the library memories are buried in the first product's project.
💡 Desired Outcome

From a product repository, the agent sees the memories of the product and of the libraries it depends on, and only those, without me listing the projects in agent instructions.

Memories about a library stay in that library's project, even when the change was made from a session that started in the product repository. Each library project stays product-agnostic, so the next product that uses the library gets its memories and not the first product's.

Constraints that I think matter, to stay inside Engram's isolation model:

  • The relation between projects is explicit and opt-in, declared by the user. Nothing is inferred.
  • Crossing the boundary is read-only. Write rules stay as they are today, unless the user or the agent targets a project on purpose.
  • No new scope.
📦 Affected Area

MCP Server (tools, transport)

Release Context

3.3.2

🔄 Workarounds and Constraints
  • One shared project (.engram/config.json with the same project_name in every repository). It works for reads, but it mixes library and product knowledge (see point 3).
  • Agent instructions that tell the agent to search three projects and to pass an explicit project when it saves. This depends on the agent following the instructions every time. Nothing enforces it, and the default write goes to the session's project.
  • all_projects search. It finds the memories, but with noise from unrelated projects.
📎 Additional Context

The same pattern appears with any "product + shared libraries" setup that is split across repositories: one developer, several repositories, and changes that cross repository boundaries in a single task.

Dominant language
Go
Stars
7.1k
Forks
729
Avg merge
9h 11m
Merged PRs (30d)
359

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Gentleman-Programming/engram

All issues in Gentleman-Programming/engram

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.