Skip to content

pi-memory-context injects unrelated project context and corrections from other projects #19

@JohannesKlauss

Description

@JohannesKlauss

Hey, I was wondering how I can have more control over what gets injected into the memory at the convsersation start.

I'm working on a side project and realized that pi-memory injects lessons and context from other projects (I marked unwanted stuff with ###):

## Project Context
- rise.hosting: The rise project is hosted on GitLab Use the glab CLI to interact with it. ### UNRELATED PROJECT
- rise.testing.fabricca: Always use fabricca (from @repo/prisma/testing) to create fixtures in integration tests. Never use raw prisma queries for
test setup. ### UNRELATED PROJECT
## Learned Corrections
- DON'T: When the user asks if something is possible (e.g. "Could we...?", "Is it possible to...?", "Can we...?"), do NOT implement changes
immediately. Instead: research the codebase or ecosystem to understand feasible approaches, identify trade-offs, and present options for
discussion. Wait for explicit approval before making any changes. This applies to all projects. [workflow]
## Validated Approaches
- When making visual/UI changes, always verify the result using Playwright screenshot tools before declaring it done. Never rely solely on code
review or type checking for visual correctness.
- Always run `vp check --fix` and then `vp check` before considering work complete. These commands run formatting, linting, and type checking. Fix all errors in files you created or modified. [workflow]
- Never use non-null assertions (!) in TypeScript. They are unsafe and bypass type checking. Use bounds checks, type narrowing, or throw explicit errors instead. [code-style]
- A 'Ping' is an abstract NPC action/motivation that delivers a hook or info to the PCs. In session prep, define the Ping (who, what, why) and
provide 2-3 modular bullet points on how it could organically happen in play (e.g., seen in the world, direct comms, chance meeting), rather than forcing a specific encounter. [workflow] ### UNRELATED PROJECT
- Always read `2. Mechanics/Goons.md` before generating combat stats for NPCs to align with the campaign's established threat tiers (Mook,
Lieutenant, Mini Boss). [workflow]  ### UNRELATED PROJECT
- Always verify if a file (or a similarly named file) already exists using `ls` or `find` before creating a new one to avoid duplicates,
especially for characters/NPCs where aliases might be used. [workflow]  ### UNRELATED PROJECT

Especially the project context injection is weird, because I'm in a totally different project with this session, but it still injects context from the rise project. In this case it's a bit annoying, because the project neither uses fabricca nor prisma nor is it hosted on gitlab.

The TTRPG memory entries about NPC, etc. are especially weird, because they not only are part of a different project, but I also have a completely separate total-recall path set up in that project with this .pi/settings.json:

{
  "pi-total-recall": {
    "localPath": ".pi/total-recall"
  }
}

And it created it's own memory.db, etc, so it's my understanding that it shouldn't even be part of the global memory. Is there a way to debug how/why these entries get injected?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions