# Augment Memory Workflow

When the Augment MCP server is configured, use it as the local project memory.

## Session Start

1. Call `init_project`.
2. Call `search` with the user's task summary.
3. Read exact memories when search results identify likely governing context.

## Before Code Changes

1. Search for the file, component, command, error, or behavior being touched.
2. If the work depends on a prior decision, read and follow the relevant `SPEC`
   or `ARCH` memory.
3. If no relevant memory exists but the task creates a durable requirement or
   decision, create one before implementation.

## Memory Triggers

Call `upsert` whenever one of these durable events happens:

- A requirement, API contract, data model, or tool contract is clarified:
  use `SPEC`.
- An implementation approach, tradeoff, transport choice, persistence model, or
  architecture decision is made: use `ARCH`.
- A bug, risk, failing behavior, or blocker is discovered: use `ISSUE`.
- Follow-up work is intentionally deferred: use `TODO`.
- A meaningful implementation milestone is completed: use `WORK`.
- A test scenario, regression case, or verification rule is learned: use `SPEC`
  or `WORK`, whichever is more durable.

## Links

After creating or updating a memory:

1. Use `link` when a memory implements, depends on, blocks, parents, or relates
   to another memory.
2. Prefer linking new `WORK` notes to the `SPEC`, `ARCH`, `ISSUE`, or `TODO`
   they address.

## Generic store

When the user asks to `/augment:generic`, store as generic, promote to generic,
or import knowledgebase/notes into shared memory (skill: `augment-generic`):

1. Resolve project `.generic` via `list_projects` (or `init_project` with
   `project_name: ".generic"` if missing). Always `upsert` with that
   `project_id` — never the cwd project.
2. Chunk into one focused SPEC (facts/contracts) or ARCH (methods/tradeoffs)
   per durable claim. Never WORK/ISSUE/TODO. No whole-book dumps.
3. `search` (and `read` near `.generic/` hits) before write; update in place on
   same name/topic. Tags include origin (`source:knowledgebase`, `domain:…`).
   Provenance in the body; do not use `decoction_glean` or force multi-project
   `derived_from`.
4. For more than three memories or a whole-tree import, show a batch
   (kind/name/summary/create-vs-update) and wait for explicit approval before
   any `upsert`. Report each `.generic/...` path written.

This is intentional shared knowledge, not decoction (cross-project recurrence)
or sleep (within-project WORK fold).

## Session Finish

For almost every session that did real work (skip only pure Q&A, read-only
inspection, or trivial mechanical ops like 'commit & push'):

1. Upsert a concise `WORK` memory with what changed, key files, and verification.
2. Upsert or update `TODO` memories for known remaining work.
3. Link the final `WORK` memory to the relevant planning/decision memories.

## Guardrails

- Do not store secrets, credentials, tokens, or private keys.
- Do not store huge logs, dependency dumps, generated files, or full source files.
- Keep each memory focused; split large notes before calling `upsert`.
- Treat numeric memory IDs as local handles. Relative paths are the durable identity.
- Use returned search text directly as context; do not ask Augment to summarize.
- Default to upserting when a turn did real work; only skip pure Q&A, read-only
  inspection, or trivial mechanical ops. When unsure, upsert.
- Do not create memories for facts already obvious from the current diff, or that
  duplicate an existing memory (update that one instead).