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. --- project_claudomator_builder_prompt_decomposition_bias.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 project_claudomator_builder_prompt_decomposition_bias.md (limited to 'project_claudomator_builder_prompt_decomposition_bias.md') diff --git a/project_claudomator_builder_prompt_decomposition_bias.md b/project_claudomator_builder_prompt_decomposition_bias.md new file mode 100644 index 0000000..fe3712b --- /dev/null +++ b/project_claudomator_builder_prompt_decomposition_bias.md @@ -0,0 +1,14 @@ +--- +name: claudomator-builder-prompt-decomposition-bias +description: "Retro item — consider revising the builder role's system prompt to bias toward decomposition more readily, based on the diagram story's real-world run" +metadata: + node_type: memory + type: project + originSessionId: 560b9055-7a3f-483e-b1a0-1a4c70419390 +--- + +User raised (2026-07-11, during the diagram story's live dogfooding run) that `builder`'s seeded system prompt (`internal/storage.builderRoleConfigJSON`, piece 5) should maybe be revised to promote decomposition via `spawn_subtask` more readily -- "whenever feasible" -- rather than its current, more balanced framing. Not yet implemented; captured for later consideration. + +**Why:** The diagram story's root task chose to implement directly (one big commit, 273 lines) rather than decompose into focused subtasks (e.g. one per entry point researched, one for drawing). That single evaluator pass then had to catch every issue in the whole diagram at once, and it did catch real factual errors (`evaluator_correctness` flagged 3 wrong data-flow claims) -- but the review that would have naturally resulted from decomposing (each subtask getting its own dedicated 4-evaluator pass, more focused and more likely to catch depth-specific errors) never happened, since nothing was actually split. The current prompt's guidance is deliberately conservative: "Implement directly when cohesive... Decompose when bundling would blur unrelated concerns... Don't decompose for its own sake... every additional layer adds cost." This real run suggests that balance may be tilted too far toward direct implementation, at least for the kind of broad research-and-synthesis work the diagram task was. + +**How to apply:** If revisiting `builderRoleConfigJSON`'s `system_prompt` in `internal/storage/seed.go`, consider whether "decompose whenever feasible" (a stronger default bias toward splitting, accepting the latency/cost tradeoff more often) produces better-reviewed output than the current "decompose only when it clearly blurs concerns" framing -- weighed against the also-real cost concern the current prompt already states (every layer of decomposition adds a full evaluator-and-arbitration cycle's worth of latency and cost, and see [[claudomator-workspace-disk-leak]]/[[claudomator-claude-md-staleness]] for how much operational friction this session's dogfooding run alone surfaced). This is a real trade-off, not an obviously-correct change -- treat it as a hypothesis to test (e.g. re-run a similar story after the change and compare evaluator findings), not a given. -- cgit v1.2.3