# Reusable Memory during the workflow Consult rules at schema linking and SQL construction with `tht memory rules "" --session --json`. An optional `--filters '{"table":"orders","column":"id"}'` narrows the physical context. The runtime fixes database and schema. A returned card is a candidate: explain its scope and Memory ID in the existing join, CTE or SQL proposal. That gate approves the concrete use; a retrieved link is not an approval. Exemplars remain references to previous questions. ## Prepare additions and updates After a reviewer approves a reusable definition, join/calculation rule or explained correction, prepare a card citing the effective decision sequence(s) from `tht session show `. Preserve the explanation and physical dependencies. Keep query-specific choices (for example only using 2024) in the solved question. An unselected option, unexplained rejection or timeout is not a reusable source. When an error and correction state the same rule, prepare one card. Write the complete current proposal list to a temporary JSON file and run `tht memory propose --session --data `. This persists `memory_proposals.json` in the session without changing the shared archive. Reuse proposal IDs when refining their wording. The accepted shape is: ```json [ { "id": "order-grain", "source_seqs": [11], "reason": "The reviewer corrected repeated header totals; this also applies to future questions.", "card": { "family": "sql_rule", "subject": "Order totals after joining lines", "detail": "Aggregate each order once before combining it with line totals.", "scope": "Sales orders and order lines", "rationale": "A line join repeats the header amount once per line.", "concepts": ["order grain"], "dependencies": [{"database": "warehouse", "schema_name": "sales", "table": "orders", "column": "total"}], "links": [] } } ] ``` Use the actual decision numbers and schema identifiers from this session. Families are `domain_clarification`, `sql_rule`, `explained_error` and `solved_question`. Explained errors require both the corrected behavior and an approved explanation. The summary adds domain clarifications and the current approved exemplar when they are not covered by authored proposals, so author only the additions/changes needed. For an update, include `target_id` and `target_revision` from the current recalled card, explain the change in `reason`, and provide its complete resulting content. The reviewer sees the current card alongside the proposal. A conflicting manual edit requires a refreshed proposal and another review; it is not overwritten. Keep different rules with different scopes separate. Exact duplicates do not need another card. Semantic deletion belongs to Memory management. Links contain `target_id` and `meaning`. Use a current Memory ID for an existing destination or `proposal:` for another new card in the summary. The reviewer may edit/remove links; a link to a new card requires selecting that card. ## Final review At the end of F8, call `reviewer_memory_promote`. The widget permits content, scope, concept, dependency and link edits and accepts an empty selection. Approved exemplar SQL remains the session's solution; changing it requires returning to SQL review. The gate applies selected cards and links atomically in PostgreSQL and then updates Qdrant. An incomplete index update is reported and retained for explicit retry. An interrupted review is recovered from its persisted receipt rather than applied again. Once the gate reports finalization, end the session without another gate. For a Memory/Evidence conflict requiring a persistent correction, follow `archive-repair.md`. A correction already saved by that gate does not need a duplicate update in the final summary.