feat(memory-core): record terminal task outcomes for dreaming feedback#75140
feat(memory-core): record terminal task outcomes for dreaming feedback#75140keane-751892 wants to merge 1 commit into
Conversation
Add a plugin-sdk seam (task-events) that lets plugins subscribe to the task registry's lifecycle events without owning the singleton observer that tests rely on. Multiple listeners can register in parallel and exceptions inside one listener are swallowed so they cannot break the emit path. Wire memory-core to the seam: when a task transitions into a terminal state (succeeded, failed, timed_out, cancelled, lost), append a JSONL outcome record to <workspace>/memory/.dreams/task-outcomes.jsonl with status, runtime, agent, label, durationMs, and a short summary. Dreaming can pick these up later as candidate "what worked / what failed" entries, closing the missing task -> memory feedback loop. The task-outcomes.jsonl path keeps the new data isolated from the existing MemoryHostEvent log, so the shared schema stays untouched. Thanks @keane-751892
|
Thanks for the contribution. I reviewed the branch, and this PR is not a good landing base for OpenClaw. Close as low-signal unmergeable: the task-to-memory feedback idea is useful, but the branch promotes raw task records into a public SDK, adds noncanonical JSONL runtime storage, leaks listener lifecycle ownership, is conflicting, and lacks real behavior proof, so most of the diff would need replacement rather than polish. So I’m closing this PR rather than keeping an unmergeable branch open. A new narrow PR that carries only the useful part is welcome. Review detailsBest possible solution: Close this branch and ask for a new narrow PR only after maintainers approve a scoped task-lifecycle event contract and a canonical persistence path using plugin state or the safe memory event journal. Do we have a high-confidence way to reproduce the issue? No current-main bug reproduction applies because this is a feature PR. The PR-introduced blockers are high-confidence from source inspection of the raw SDK export, direct JSONL append path, and discarded unsubscribe function. Is this the best way to solve the issue? No. A task-to-memory feedback loop is plausible, but this implementation is not the best shape until the public event scope, privacy boundary, persistence owner, listener lifecycle, and proof path are redesigned. Security review: Security review needs attention: Security review needs attention because the diff exposes raw task lifecycle data through a public SDK path and writes workspace outcome records without the existing safe append helper.
AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 6de357ad4772. |
|
This pull request has been automatically marked as stale due to inactivity. |
|
ClawSweeper applied the proposed close for this PR.
|
Summary
Adds a plugin-sdk seam (
openclaw/plugin-sdk/task-events) that lets plugins subscribe to the task registry's lifecycle events without owning the singleton observer that tests rely on. Multiple listeners can register in parallel viaaddTaskRegistryEventListener(listener), which returns an unsubscribe function. Listener exceptions are swallowed so one consumer cannot break the registry's notification path.Wires memory-core to the seam: when a task transitions into a terminal state (
succeeded,failed,timed_out,cancelled,lost), append a JSONL outcome record to<workspace>/memory/.dreams/task-outcomes.jsonlwith status, runtime, agent, label, durationMs, and a short summary. Dreaming can pick these up later as candidate "what worked / what failed" entries, closing the missing task → memory feedback loop.The
task-outcomes.jsonlpath keeps the new data isolated from the existingMemoryHostEventlog so the shared schema stays untouched.Files changed
src/tasks/task-registry.store.ts— multi-listener registry helpers (`addTaskRegistryEventListener`, `hasAdditionalTaskRegistryEventListeners`, `notifyAdditionalTaskRegistryEventListeners`)src/tasks/task-registry.ts— emit path now also fans out to the additional listener setsrc/plugin-sdk/task-events.ts— new SDK facade (re-exports types andaddTaskRegistryEventListener)scripts/lib/plugin-sdk-entrypoints.json+package.json+ regenerateddocs/.generated/plugin-sdk-api-baseline.sha256— register the new subpathextensions/memory-core/src/task-outcome-recorder.ts+ tests — terminal-transition recorder writing JSONL eventsextensions/memory-core/index.ts— wireregisterTaskOutcomeRecorderinto the plugin'sregister(api)passTest plan
pnpm test extensions/memory-core/src/task-outcome-recorder.test.ts— 9 tests covering shouldRecord, summarizeOutcome, buildOutcomeRecord, and JSON-serializable outputpnpm check:changed— typecheck (core + extensions) and tests green; lint shows only the unrelated pre-existingdoctor-state-integrity.ts:875warningNotes for review
resolveAgentWorkspaceDiris already exposed viaopenclaw/plugin-sdk/memory-core-host-engine-foundation, so memory-core can resolve a workspace fromtask.agentIdwithout needing a new SDK seam.resolveDefaultAgentId(api.config). If neither is available, it silently does nothing (best-effort) rather than blocking the registry.🤖 Generated with Claude Code