greplica-update-working-memory

Update Greplica Working Memory

Update working memory with durable information learned during this coding session.

Preconditions

Run from the target repository root, a subdirectory inside it, or a non-Git folder that should have its own memory.

Do not run greplica doctor as a routine preflight. Run the needed Greplica commands directly; if one fails, use the error to decide whether greplica doctor would help diagnose installation, target detection, or embedding-provider configuration.

If greplica is missing, tell the user to run the Greplica setup prompt from the README.

If a Greplica command reports that Greplica is not installed for this repo, tell the user to run the Greplica setup prompt from the README inside this repo.

Local embeddings are the default and do not require OPENAI_API_KEY. If Greplica is configured for OpenAI and a command reports that OPENAI_API_KEY is missing, stop. Do not ask the user to paste the key into chat. Tell them to set it in their shell before launching the coding agent, or in target-root .env.local.

Gather Evidence

Use the current conversation/session context plus code evidence. Read:

• git status --short
• git diff --stat
• focused git diff for changed areas
• files touched by the session when needed to verify claims
• existing relevant memory with greplica graph context "<task or changed area>"
• code-anchor audit with greplica graph audit anchors when the installed Greplica version supports it

Use the current session as context, but verify durable code facts against files or diffs when possible.

Transcript evidence can produce useful memory, but it has different roles:

• user decisions, constraints, rejected alternatives, and future-work boundaries can become source_verified session claims.
• explored repo paths can become memory only when they explain ownership, a cross-component flow, a confusing distinction, or a location future agents would otherwise rediscover.
• tool outputs containing file paths, symbols, line numbers, or Greplica anchors are navigation clues, not proof by themselves.
• convert a transcript clue into a code_verified claim only after checking the current file/diff and adding a precise code_anchors entry.
• when a session decision, rationale, constraint, trade-off, or future-work claim points at a concrete code area, include code_anchors as navigation hints if you verified those anchors. The session source remains the evidence for the decision; the anchors tell future agents where the related code lives.
• if a transcript mentions an issue, PR, review, or comment packet, store the durable fact from the packet content, not a title-only summary.