From a6d58e009efcc06e7b5221d75ebed36533786dce Mon Sep 17 00:00:00 2001 From: Claude Code Date: Sat, 15 Aug 2026 18:06:00 +0000 Subject: Merge titanium's diverged memory tree into the shared history Titanium and tungsten had grown two separate, unreconciled memory sets for the same -workspace scope. Ports over 18 titanium-only entries (12 claudomator files, the fork-scope-creep lesson, the doot Google Tasks OAuth limitation, the default-subagent-driven-execution preference, scout's Facebook priority, Hawaii GIS endpoints), merges two true duplicates into their existing tungsten files rather than keeping parallel copies (the migration-rename incident -- same 022->023 rename, same commit, titanium's version added the confirmed-safe-to-patch-prod-directly carve-out tungsten's didn't have; the APK build OOM note, folded into project_doot_widget_build.md as a RAM-constrained-host fallback), and marks doot_future_task_scheduling_ideas.md as historical now that all four of its backlog items (budgets, labels/projects, buckets, chains) are built. --- feedback_claudomator_task_board_accept_workflow.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 feedback_claudomator_task_board_accept_workflow.md (limited to 'feedback_claudomator_task_board_accept_workflow.md') diff --git a/feedback_claudomator_task_board_accept_workflow.md b/feedback_claudomator_task_board_accept_workflow.md new file mode 100644 index 0000000..0d2f0c4 --- /dev/null +++ b/feedback_claudomator_task_board_accept_workflow.md @@ -0,0 +1,14 @@ +--- +name: claudomator-task-board-accept-workflow +description: "SDD dispatch workflow never calls accept_task after a reviewed/merged claudomator task — board fills up with READY tasks that look unfinished even though they're done" +metadata: + node_type: memory + type: feedback + originSessionId: 560b9055-7a3f-483e-b1a0-1a4c70419390 +--- + +This session's subagent-driven-development loop (dispatch a claudomator task → implementer commits+pushes → review the diff via a separate local Agent subagent → update the progress ledger) never calls `mcp__claudomator__accept_task` on the claudomator task itself once review comes back APPROVE. The claudomator task board's own review/accept mechanism and this session's out-of-band local-subagent review process were two disconnected tracks — so every successfully-reviewed-and-merged piece this session (pieces 1 through 4b-3, all their retries) sat at READY on the task board indefinitely, looking like unactioned work even though it was actually done. User flagged this directly: "the task board is filling up with artifacts from your runs — we need to clean those up and also tighten the workflow so they're accurate end to end." + +**Why:** The local-subagent review step (dispatching a fresh Agent to read a git diff and verdict APPROVE/REJECT) is a code-quality gate this session invented on top of claudomator's own task lifecycle; nothing in that invented process closes the loop back to claudomator's actual `READY → COMPLETED` state transition. + +**How to apply:** Once a local review subagent returns APPROVE for a claudomator-dispatched task, call `accept_task` on that claudomator task ID as part of the same step that updates the progress ledger — before moving to the next piece, not as a later cleanup pass. Also: mass-accepting/deleting a batch of already-stale tasks after the fact is a distinct, higher-blast-radius action (the auto-mode classifier denied a bulk-accept attempt mid-batch on 2026-07-10, correctly — see [[claudomator-workspace-disk-leak]] session for context) and needs explicit user sign-off, unlike accepting one task immediately after its own review completes. -- cgit v1.2.3