docs: separate public manual from internal project documentation

2026-09-15 10:26:35 +02:00
parent 6a4634dcf1
commit 043ffdfad6
26 changed files with 859 additions and 238 deletions
@@ -0,0 +1,50 @@
+# Use and administer Memory
+
+Memory stores reusable knowledge for a workspace. It is separate from Evidence sources
+and from the saved documents of an individual session.
+
+| Card family | Purpose |
+| --- | --- |
+| Domain clarification | Define a term or interpretation, with its scope. |
+| SQL rule | Explain how to construct SQL and why. |
+| Solved question | Retain an approved question and SQL as a consultative example. |
+| Explained error | Record a correction and its rationale. |
+
+## Browse and edit
+
+Open **Administration → Memory management** and select the workspace. Administration
+requires the appropriate permissions. You can search, filter, open a card's complete
+content, edit it, manage its dependencies and links, or explicitly confirm deletion.
+
+Browsing and editing require the PostgreSQL archive but do not require an active session
+or a working DWH or search index. Cards retain their identity and origin when edited;
+there is no editorial revision history. Deleting a card also removes its links and
+dependencies, not the other cards or the workspace's Evidence.
+
+Links connect cards in the same workspace. Record scope and physical dependencies
+carefully so knowledge is not applied to unrelated databases, tables or columns.
+
+## Saved content and search availability
+
+Saving a card and updating its search index are different outcomes. **Saved, index update
+incomplete** means the content is already in the archive but is not ready for recall.
+Use **Pending index updates** to retry. Do not create a duplicate card to work around an
+indexing failure. A restart does not discard the pending operation.
+
+Qdrant is a rebuildable search projection, not the authoritative archive. Rebuilding it
+does not recover deleted cards from old sessions or vector payloads. Back up the
+authoritative installation data before maintenance.
+
+After a successful physical schema synchronization, cards dependent on removed database
+objects can be deleted. Workspace-wide cards and unrelated dependencies remain. Review
+the synchronization result and any pending cleanup before starting another synchronization.
+
+## Memory in a reviewed session
+
+The workflow proposes relevant clarifications, rules and examples. A search result is
+not approval: the reviewer decides whether it applies. At the final Memory review,
+select the additions or updates worth retaining, edit their content and scope, or decline
+them all. Finalizing a session does not silently approve every proposed card.
+
+Approved SQL is read-only at that final review. To change the solution, return to SQL
+review. See the [workflow guide](../skills.md) and [user guide](../guida-utente.md).