2a73adc2 · zzmq.dev@gmail.com/zz
Commit
2a73adc2fc3391d2575a3397c8b12c51466a1ebb
Decomposition: split a work Ask into independent sub-Asks (Stage 7) New runDecomposeWorkAsk (agent/scriptedWork.ts): claims the Ask, one model call splits its description into independent sub-tasks (same plain-text/fenced-block parsing convention as the rest of the file), posts each as its own fresh "work" Ask into its own new sibling Lane (lane_propose with this Lane as origin), records each one on the parent Lane's own related_lanes (the first real populator of that field -- new engine/lane.ts addRelatedLane + agent/tools.ts's lane_add_related tool, the inverse of lane_propose's origin_lane/ origin_repo), then answers the original Ask complete. Triggered by payload.decompose, set via `zz repo ask --decompose` (threaded through webApp.ts's doPostAsk/handleApiPostAsk) and picked up by zz work's autonomous loop instead of the normal contributor flow (cli/commands/work.ts's dispatch) -- not wired into --assist, which stays a human-in-the-loop single-ask flow. lane_add_related takes its own origin_repo parameter rather than reusing `repo`, matching lane_propose's own origin_repo convention: a remote tool call's `repo` field gets rewritten server-side to the DO's internal artifacts_name before execute() ever runs (handleApiCallTool), so reusing it would have silently stored that internal name into the origin pointer instead of the real slug. Verified live against the deployed Worker: posted a decomposable ask, ran runDecomposeWorkAsk directly against it, confirmed 3 sub-lanes created with fresh "work" asks and correct related_lanes entries (real slugs, not internal DO names) on the parent lane. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Q8tksS4bucUkJguqksSVYR
Troy Howard <thoward37@gmail.com> -- 2026-10-13T20:26:29.000Z