Skip to main content
Recallium uses projects and workstreams to keep memories in the right context.

​
Projects

A project is the main organization and access boundary. Every memory belongs to exactly one project. In a coding environment, Recallium usually derives the project name from the enclosing Git repository. Opening a subdirectory still resolves to the repository project. A nested Git repository resolves independently. Use a lowercase kebab-case name, such as payments-api.

​
Map a repository to an existing project

If the repository name and Recallium project name differ, set a local Git mapping:
The mapping stays local to that clone. It is not pushed to the repository. Projects can be linked as siblings or as parent and child. Linked projects make closely related context easier to discover while each project keeps its own access boundary. Ask your agent:
Link mobile-app as a child of payments-platform in Recallium.

​
Workstreams

A workstream is a named effort inside a project. It groups the decisions, designs, fixes, and checkpoints that explain one journey. Examples:
  • oauth-migration
  • checkout-reliability
  • public-api-v2
A workstream has a lifecycle:

​
When to create a workstream

Create a workstream when the work will produce durable decisions or checkpoints. A tiny mechanical edit usually does not need one. Ask your agent:
Start a Recallium workstream called oauth-migration for this effort.
Your agent uses the returned slug when it saves each memory. Later, another session can load the workstream and see its design, decisions, constraints, and recent progress together.

​
Projects, workstreams, and tasks

These records serve different purposes: A task can link to the memories that explain it. Completing a task changes its status; it does not replace the workstream history.
Use workstream names you would recognize six months from now. Prefer the feature or outcome over a ticket number alone.