Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

feat: caller-selected Backend Jobs and bounded subjektiv consolidation (T-704)

Browse Source
This commit is contained in:
Hare
2026-10-06 19:45:37 +09:00
parent 6f9621ca2e
commit d12cdc9106
36 changed files with 4085 additions and 291 deletions
Download Patch File Download Diff File Expand all files Collapse all files
resources/profiles/subjektiv-memory-consolidation.dcdl
+2 -2
View File
@@ -3,13 +3,13 @@ import "./base.dcdl" // {
description = "Delegated subject Memory staging consolidation profile.";
scope = "workspace_read";
model = { ref = "codex-oauth/gpt-5.6-luna"; };
engine = { reasoning = "medium"; };
engine = { reasoning = "medium"; instruction = "internal.subjektiv_memory_consolidation_system"; };
web = { enabled = false; };
feature = {
task = { enabled = false; };
memory = { enabled = false; staging_tools = false; };
subjektiv = { enabled = true; extraction = { enabled = false; }; };
subjektiv = { enabled = true; consolidation_tools = true; extraction = { enabled = false; }; };
web = { enabled = false; };
image = { enabled = false; };
sub_worker = { enabled = false; };
resources/prompts/internal/subjektiv_memory_consolidation_system.md
+5 -2
View File
@@ -1,6 +1,6 @@
# Memory staging consolidater
You are the delegated internal Memory staging consolidater for one subject.
You are the Backend Job 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.
@@ -26,7 +26,10 @@ Rules:
- `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 generation is a separate clean-context Host lifecycle that runs once after this consolidation turn commits. `surface_dirty: true` means confirmed Memory changed; never treat later surface generation failure as failure of an already returned committed decision.
- For a Backend Job, finish candidate decisions before calling `SubmitBackendJobResult` with `{result:{subject_id,candidate_ids}}`, using exactly the subject_id and complete ordered candidate_ids batch supplied by the immutable Job input. Every batch candidate must have a durable disposition; do not omit candidates or include newly arriving ones. Do not supply `surface`; the result tool awaits clean-context Host surface generation and fills its actual outcome before submission. Only an accepted structured result completes a Job; final prose is not success.
- `surface_dirty: true` means confirmed Memory changed. Surface failure never rolls back an already committed candidate decision; partial application survives cancellation and failure. After a definitive result rejection, correct the immutable subject/batch fields or retry to rebuild a stale surface. After any successful or ambiguous result response (including transport errors), retry only the identical input; do not rebuild or change an outcome that may already have been accepted.
- A surface failure notification is not proof of a persisted failed marker. The Host must reject a mismatched failure acknowledgement, including when an existing ready surface was preserved. No result is submitted in that case; confirmed candidate decisions remain intact.
- Legacy non-Job consolidation retains its separate post-commit Host surface lifecycle.
- 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.