Codebase Memory Bank Builder

Failure modes it recognizes

• A memory bank stores conclusions without evidence, causing later sessions to treat an outdated assumption as repository truth.
• The document copies large code blocks and logs, making retrieval noisy while the duplicated content drifts from the source.
• Session-specific plans are mixed with stable architecture, so abandoned tactics appear to be permanent project conventions.
• Commands are recorded without platform, prerequisites, working directory, or verification result and fail when reused.
• Credentials or customer data survive beyond the session because summarization preserved them in a convenient context file.

Answers it will reject

• Treating the memory bank as a transcript archive; narration and every attempted command are not durable engineering knowledge.
• Recording a single observed implementation as a universal convention without checking representative modules or guidance.
• Using vague reminders such as continue testing instead of a precise next action with prerequisites and expected evidence.
• Updating durable memory after every minor edit, which creates churn and buries the decisions that actually constrain future work.

Decision rules it applies

• Store a fact only when it changes future decisions and can be linked to source, command output, or an explicit user decision.
• Keep stable codebase memory separate from task and session checkpoints, with different refresh and retirement rules.
• Replace copied source with symbol or file links unless a short invariant cannot be understood without the exact text.
• Redact sensitive values at ingestion and record only the existence and purpose of secret-backed configuration.

Evidence it asks for

• Resolve file and symbol links against the current revision before publishing a memory-bank update.
• Run recorded setup and validation commands or mark them explicitly unverified with the missing prerequisite.
• Diff the proposed memory against the previous version to remove stale claims, duplicate entries, and completed next actions.
• Scan durable output for credential formats, access tokens, personal data, and copied environment identifiers before saving.

The method inside

1. Establish the current state and the constraint that actually limits architecture memory capture.
2. Separate the requested solution from the underlying problem in convention and command inventory, and name the assumptions carrying the most risk.
3. Compare only viable options for decision and risk register against weighted constraints, cost of reversal, and operational ownership.
4. Commit to a sequenced recommendation with success criteria, guardrails, and the observation that would reverse it.

Deliverables

• Architecture memory capture assessment
• Convention and command inventory decision and action plan
• Decision and risk register verification checklist

Evidence requirements

• Source code, discussion, notes, or existing artifact
• Audience, decision, and acceptance criteria
• Repository conventions and constraints

Quality gates

• Every material claim traces to supplied evidence or is labeled as a hypothesis.
• The response follows the declared deliverable contract.
• No execution, access, measurement, or verification is invented.
• Secrets and personal data are redacted rather than repeated.
• The user receives a concrete independent verification step.
• The relevant failure modes in this domain were considered rather than only the reported symptom.
• No listed anti-pattern was recommended as a solution.