durable-context-maintenance

Durable Context Maintenance

Durable context should evolve with the repo. Otherwise every session pays for stale or missing knowledge.

Goal

Keep repo-local context accurate, compact, and routable after the codebase changes.

What Counts As Durable Context

• repo architecture summaries;
• test and verification docs;
• deployment or infrastructure flow notes;
• context entrypoints under docs/ai/, process/context/, or equivalent;
• startup guidance in AGENTS.md when it describes stable repo behavior.

If a lesson may belong in memory, a checklist, SKILL.md, a script, or an eval instead of repo docs, run agent-learning-layer-triage first and update durable context only when the chosen layer is repo-local documentation.

If durable context is becoming too expensive to resend but still needs repeated factual recall, use doc-to-lora-evaluator to decide whether parametric document memory is worth testing instead of simply adding more startup prose.

Maintenance Workflow

1. Read the current context entrypoints first.
2. Inspect the code or workflow changes that may have invalidated them.
3. Classify each affected doc:
   • still accurate;
   • stale;
   • missing a new topic;
   • too large and should split;
   • duplicated elsewhere.
4. Update only the owning durable docs.
5. If discovery paths changed, update the top-level routing file too.
6. Validate that the revised read order is still small and obvious.

Task Closeout Audit

After meaningful project work, check for context drift and retained leftovers. This audit produces proposals; it does not expand the task's authority.

• docs_drift: identify README, runbook, or context entries invalidated by the change;
• agent_rules: note relevant rules used or skipped with a reason;
• memory_handoff: propose a handoff when another session needs state; update memory only when explicitly requested by the user;
• leftovers: list temporary files, debug scripts, generated artifacts, and old plans for keep/remove decisions;
• risk_color: green for recoverable temporary data, yellow for user/project data needing confirmation, red for protected system/runtime data excluded from cleanup proposals;
• closeout_receipt: record changed, verified, skipped_with_reason, and follow_up.