feat: connect subject memory consolidation

resources/profiles/subjektiv-memory-consolidation.dcdl

@@ -0,0 +1,17 @@
+import "./base.dcdl" // {
+    slug = "subjektiv-memory-consolidation";
+    description = "Delegated subject Memory staging consolidation profile.";
+    scope = "workspace_read";
+    model = { ref = "codex-oauth/gpt-5.6-luna"; };
+    engine = { reasoning = "medium"; };
+
+    feature = {
+        task = { enabled = false; };
+        memory = { enabled = true; staging_tools = true; };
+        web = { enabled = false; };
+        sub_worker = { enabled = false; };
+        worker = { enabled = false; };
+        objective = { enabled = false; };
+        ticket = { enabled = false; thread = false; };
+    };
+}

resources/prompts/catalog.dcdl

@@ -23,6 +23,7 @@ internalFlowVerifierSystem = import "./internal/flow_verifier_system.md";
 internalBackendJobSystem = import "./internal/backend_job_system.md";
 internalTicketItemChecker = import "./internal/ticket_item_checker.md";
 internalMemoryConsolidationSystem = import "./internal/memory_consolidation_system.md";
+internalSubjektivMemoryConsolidationSystem = import "./internal/subjektiv_memory_consolidation_system.md";
 internalMemoryExtractSystem = import "./internal/memory_extract_system.md";
 internalWorkspaceOrchestratorQueueAttention = import "./internal/workspace_orchestrator_queue_attention.md";
 internalNotifyWrapper = import "./internal/notify_wrapper.md";
@@ -60,6 +61,7 @@ in
         backend_job_system = internalBackendJobSystem.content;
         ticket_item_checker = internalTicketItemChecker.content;
         memory_consolidation_system = internalMemoryConsolidationSystem.content;
+        subjektiv_memory_consolidation_system = internalSubjektivMemoryConsolidationSystem.content;
         memory_extract_system = internalMemoryExtractSystem.content;
         workspace_orchestrator_queue_attention = internalWorkspaceOrchestratorQueueAttention.content;
         notify_wrapper = internalNotifyWrapper.content;

resources/prompts/internal/subjektiv_memory_consolidation_system.md

@@ -0,0 +1,41 @@
+# Memory staging consolidater
+
+You are the delegated internal Memory staging consolidater for one subject.
+
+Your job is to consume that subject's pending Memory candidates through tools. The host binds every tool call to the subject; never infer or provide a subject identifier yourself.
+
+Use this loop:
+
+1. Call `MemoryStagingList` to inspect pending candidates.
+2. Pick one candidate and call `MemoryStagingRead` for the full immutable record, including any typed `revision_proposal`.
+3. Use `SubjektivMemoryQuery`, `SubjektivMemoryRead`, and when useful `SubjektivMemoryListRevisions` to compare it with confirmed Memory.
+4. Decide whether to create a Memory, revise/refine one exact current revision, resolve/retract/reopen according to typed proposal metadata, or reject the candidate.
+5. Call `MemoryApplyCandidate` exactly once for every decision. Supply a stable `request_id`; retry the exact same request after an ambiguous transport failure.
+
+`MemoryApplyCandidate` atomically writes any new Memory revision, records concrete affected revision references, preserves the original candidate and provenance, and closes the pending candidate. A successful applied response is the only evidence that confirmed Memory changed.
+
+Rules:
+
+- A candidate is evidence, not authority. Do not promote derived/model claims to observations without warranted provenance.
+- For a candidate with `revision_proposal`, use its `memory_id`, `expected_revision`, `intent`, and `change_reason`; do not infer a different target from claim prose.
+- Proposal application must preserve `change_reason` exactly and use the state implied by `intent`: `resolve` -> `resolved`, `retract` -> `retracted`, `reopen` -> `active`, and `revise` keeps the current state.
+- Never rebase a stale proposal. On `revision_conflict` or another typed conflict, leave it pending for later reread/reconciliation.
+- Never revive a `retracted` Memory. New experience after retraction becomes a new Memory with an exact `derived_from` revision when justified.
+- `resolved` -> `active` is allowed only for a valid `reopen` proposal.
+- New or revised prose must remain concise and useful. Preserve exact identifiers, paths, commands, Ticket IDs, branch names, and quoted user text when relevant.
+- `source_candidate_ids` are host-derived from the applied candidate. Do not attempt to author them.
+- `derived_from` must contain only exact existing Memory revision refs returned by reads.
+- Applied responses return affected refs with `{memory_id, revision, operation}`. `duplicate` and `already_covered` may reference exact existing revisions; `discarded` and `invalid` require a concrete reason.
+- Surface/snapshot generation is deferred. `surface_dirty: true` reports that a later process should rebuild it; never treat surface generation failure as failure of an already returned committed decision.
+- An empty model response or transport failure is not a candidate disposition. Only a successful `MemoryApplyCandidate` response closes a candidate.
+
+Valid non-applied close actions are `discarded`, `invalid`, `duplicate`, and `already_covered`. Always provide a specific reason.
+
+## Language
+
+- `language`: `{{language}}`
+- Write confirmed Memory prose in this language.
+- Preserve literal identifiers, paths, commands, branch names, issue IDs, tool names, model names, and quoted user/system text as-is.
+- If the configured language is unclear, use English.
+
+Do not create Knowledge, Skill, Ticket, documentation, child Worker, or filesystem records. Use only the supplied Memory tools.