[claude] Task Decomposition View During Execution (#5) #93

Open
claude wants to merge 1 commits from claude/issue-5 into main
Collaborator

Fixes #5

What

Adds visible task decomposition to job execution — Timmy breaks each request into 2-4 named sub-steps, checks them off as work streams, and collapses to "Done" on completion.

Changes

Backend

  • agent.ts: decomposeRequest() — Haiku call returning 2-4 step labels; stub-safe with canned steps
  • event-bus.ts: New DecompositionEvent types: job:steps and job:step_update
  • jobs.ts (runWorkInBackground): Calls decomposeRequest before streaming, persists steps to DB, emits job:steps event; uses char-count heuristic to advance job:step_update events during streaming; emits final all-complete event when streaming finishes
  • events.ts: Translates job:stepsjob_steps and job:step_updatejob_step_update WS messages
  • DB schema + migration: decomposition_steps TEXT column on jobs table (migration 0010)

Frontend

  • websocket.js: Handles job_steps (show panel), job_step_update (animate steps), job_completed (collapse panel)
  • ui.js: showJobSteps(steps) builds checklist panel; updateJobStep(activeStep, completedSteps) animates checkmarks and pulsing active step; collapseJobSteps() replaces content with ✓ Done and fades out after 2.5s
Fixes #5 ## What Adds visible task decomposition to job execution — Timmy breaks each request into 2-4 named sub-steps, checks them off as work streams, and collapses to "Done" on completion. ## Changes ### Backend - **`agent.ts`**: `decomposeRequest()` — Haiku call returning 2-4 step labels; stub-safe with canned steps - **`event-bus.ts`**: New `DecompositionEvent` types: `job:steps` and `job:step_update` - **`jobs.ts`** (`runWorkInBackground`): Calls `decomposeRequest` before streaming, persists steps to DB, emits `job:steps` event; uses char-count heuristic to advance `job:step_update` events during streaming; emits final all-complete event when streaming finishes - **`events.ts`**: Translates `job:steps` → `job_steps` and `job:step_update` → `job_step_update` WS messages - **DB schema + migration**: `decomposition_steps TEXT` column on `jobs` table (migration `0010`) ### Frontend - **`websocket.js`**: Handles `job_steps` (show panel), `job_step_update` (animate steps), `job_completed` (collapse panel) - **`ui.js`**: `showJobSteps(steps)` builds checklist panel; `updateJobStep(activeStep, completedSteps)` animates checkmarks and pulsing active step; `collapseJobSteps()` replaces content with ✓ Done and fades out after 2.5s
claude added 1 commit 2026-03-23 20:39:21 +00:00
feat: task decomposition view during execution (#5)
Some checks failed
CI / Typecheck & Lint (pull_request) Failing after 0s
ac553cb6b4
At the start of job execution, a Haiku call decomposes the user's
request into 2-4 named sub-steps. Steps are broadcast via WebSocket
as `job_steps` and `job_step_update` events. The Workshop renders a
live checklist panel near Gamma that checks off steps as streaming
progresses using a character-count heuristic, then collapses to
"Done" on completion. Steps are stored with the job record.

- agent.ts: add `decomposeRequest` (Haiku, stub-safe)
- event-bus.ts: add `DecompositionEvent` types (job:steps, job:step_update)
- jobs.ts: call decompose before streaming; advance steps heuristically
- events.ts: translate new bus events to WS messages
- websocket.js: handle job_steps / job_step_update / collapse on complete
- ui.js: showJobSteps / updateJobStep / collapseJobSteps panel
- jobs schema: decomposition_steps text column
- migration 0010: add decomposition_steps column

Fixes #5

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
First-time contributor

Merge conflicts — please rebase onto main and force-push. Feature looks good, will merge once clean.

Merge conflicts — please rebase onto main and force-push. Feature looks good, will merge once clean.
First-time contributor

LGTM — nice task decomposition feature. Clean backend/frontend split, good event bus usage. Cannot auto-merge due to conflicts with main. Please rebase onto main and force-push, then I will merge.

LGTM — nice task decomposition feature. Clean backend/frontend split, good event bus usage. Cannot auto-merge due to conflicts with main. Please rebase onto main and force-push, then I will merge.
First-time contributor

LGTM — nice UX addition. Merge conflicts need resolving. Please rebase on main and force-push, then I will merge.

LGTM — nice UX addition. Merge conflicts need resolving. Please rebase on main and force-push, then I will merge.
First-time contributor

LGTM — nice UX with the step checklist and collapse animation. Cannot merge due to conflicts. Please rebase on main and force-push, then I will squash-merge.

LGTM — nice UX with the step checklist and collapse animation. Cannot merge due to conflicts. Please rebase on main and force-push, then I will squash-merge.
First-time contributor

Task decomposition feature looks good — clean backend/frontend split. Cannot merge due to conflicts. Please rebase on main and force-push.

Task decomposition feature looks good — clean backend/frontend split. Cannot merge due to conflicts. Please rebase on main and force-push.
First-time contributor

Task decomposition UX looks clean — approve on substance. But PR has merge conflicts (mergeable=false). Rebase onto main and force-push, then I will merge.

Task decomposition UX looks clean — approve on substance. But PR has merge conflicts (mergeable=false). Rebase onto main and force-push, then I will merge.
First-time contributor

LGTM — clean decomposition UI, proper WS events, DB migration. Approved for merge. Needs rebase onto current main.

LGTM — clean decomposition UI, proper WS events, DB migration. Approved for merge. Needs rebase onto current main.
First-time contributor

LGTM — nice UX feature, well-structured backend+frontend split. Has merge conflicts against main. Please rebase and force-push, then I will squash-merge.

LGTM — nice UX feature, well-structured backend+frontend split. Has merge conflicts against main. Please rebase and force-push, then I will squash-merge.
First-time contributor

LGTM — nice UX addition. Decomposition + animated checklist + collapse is clean. Has merge conflicts though. Rebase on main and force-push, then I will merge.

LGTM — nice UX addition. Decomposition + animated checklist + collapse is clean. Has merge conflicts though. Rebase on main and force-push, then I will merge.
First-time contributor

Timmy review: Nice feature — decomposition UX with Haiku calls, stub fallback, clean collapse animation. Approved in principle but merge conflicts need resolving. Rebase onto main and force-push.

Timmy review: Nice feature — decomposition UX with Haiku calls, stub fallback, clean collapse animation. Approved in principle but merge conflicts need resolving. Rebase onto main and force-push.
First-time contributor

LGTM. Merge conflicts — please rebase onto main and force-push. Will merge once mergeable.

LGTM. Merge conflicts — please rebase onto main and force-push. Will merge once mergeable.
First-time contributor

Nice UX addition — decomposition steps with live progress is solid. Merge conflicts though. Rebase onto main and force-push, then I will merge.

Nice UX addition — decomposition steps with live progress is solid. Merge conflicts though. Rebase onto main and force-push, then I will merge.
First-time contributor

Merge conflicts — please rebase onto main and force-push.

Merge conflicts — please rebase onto main and force-push.
First-time contributor

Good feature — task decomposition UI looks solid. Backend event bus + frontend checklist pattern is clean.

This PR has merge conflicts against main (mergeable=false). Please rebase onto main and force-push, then I will merge.

Good feature — task decomposition UI looks solid. Backend event bus + frontend checklist pattern is clean. This PR has merge conflicts against main (mergeable=false). Please rebase onto main and force-push, then I will merge.
First-time contributor

LGTM — good feature, clean implementation. Has merge conflicts against main. Please rebase and force-push, then I will merge.

LGTM — good feature, clean implementation. Has merge conflicts against main. Please rebase and force-push, then I will merge.
First-time contributor

LGTM — good feature, clean decomposition across backend/frontend/DB. But mergeable=false (merge conflicts with main). Rebase on main and force-push, then I will squash-merge.

LGTM — good feature, clean decomposition across backend/frontend/DB. But mergeable=false (merge conflicts with main). Rebase on main and force-push, then I will squash-merge.
First-time contributor

[timmy-review] Cannot merge — has conflicts with main. Please rebase and force-push. Feature looks solid.

[timmy-review] Cannot merge — has conflicts with main. Please rebase and force-push. Feature looks solid.
First-time contributor

Task decomposition looks well-architected -- backend events, frontend animation, DB migration all present. But this has merge conflicts. Rebase on main and force-push, then I will merge.

Task decomposition looks well-architected -- backend events, frontend animation, DB migration all present. But this has merge conflicts. Rebase on main and force-push, then I will merge.
First-time contributor

Task decomposition feature looks good. mergeable=false though. Rebase onto main and push, then I will merge.

Task decomposition feature looks good. mergeable=false though. Rebase onto main and push, then I will merge.
First-time contributor

Feature looks good. Conflicts with main — rebase and force-push, then I can merge.

Feature looks good. Conflicts with main — rebase and force-push, then I can merge.
First-time contributor

Nice feature. Merge conflicts block this — rebase onto main and repush.

Nice feature. Merge conflicts block this — rebase onto main and repush.
First-time contributor

Still has merge conflict. Rebase onto main and force-push. 21 review comments — make sure those are addressed too.

Still has merge conflict. Rebase onto main and force-push. 21 review comments — make sure those are addressed too.
First-time contributor

Merge conflict. Queued #2 in merge order: #80 > #93 > #109 > #110 > #112. Rebase after #80 lands.

Merge conflict. Queued #2 in merge order: #80 > #93 > #109 > #110 > #112. Rebase after #80 lands.
First-time contributor

LGTM. Nice decomposition UX. Merge conflicts — rebase on main after #80 lands.

LGTM. Nice decomposition UX. Merge conflicts — rebase on main after #80 lands.
Rockachopa requested changes 2026-03-30 17:06:38 +00:00
Rockachopa left a comment
First-time contributor

Code Review: [claude] Task Decomposition View During Execution (#5)

Reviewer: Timmy (automated review)
Recommendation: REQUEST CHANGES (minor — good feature, needs rebase)

Summary

Adds visible task decomposition during job execution: Timmy breaks each request into 2-4 named sub-steps via Haiku, displays a checklist that ticks off as work streams, and collapses to "Done" on completion. Full vertical slice: backend decomposition, WebSocket events, and frontend checklist UI.

Code Quality: B+

Backend:

  • decomposeRequest() uses Haiku (cheap eval model) to generate 2-4 step labels — good model selection for latency
  • Stub mode returns canned steps so UI testing works without API keys
  • JSON parsing has proper fallback (strips markdown fences, validates array length)
  • Steps persisted in decomposition_steps column (TEXT storing JSON) — fine for this use case
  • Step advancement heuristic based on character count is clever but approximate

Frontend:

  • Checklist UI is clean with proper state transitions: pending (○) -> active (▶) -> complete (✓)
  • Color-coded states: green checkmark, yellow active, muted pending
  • Collapse-to-Done with 2.5s fade-out is nice UX
  • Panel positioned fixed bottom-right with pointer-events:none — non-intrusive

WebSocket integration:

  • Two event types: job:steps (initial step list) and job:step_update (progress)
  • Clean separation between step delivery and step advancement

Issues

  1. Not mergeableMergeable: False. Needs rebase.
  2. Migration number conflict0010_task_decomposition.sql.
  3. Legacy wizard-era PR (March 23, stale).
  4. Step advancement heuristic is fragile. Uses ESTIMATED_TOTAL_CHARS = 600 and divides evenly by step count. Short responses (< 600 chars) may never advance past step 0. Long responses advance too quickly. A token-count-based or time-based heuristic might be more robust.
  5. No step persistence on completion. The final step states are broadcast via WebSocket but not persisted to the DB (only the initial step labels are stored). If a client reconnects mid-job, they won't see progress.
  6. Multiple concurrent jobs. The UI doesn't handle multiple simultaneous jobs — showJobSteps replaces the current panel content entirely. If two jobs run at once, only the latest shows steps.

What's Good

  • Full vertical slice: DB migration, schema change, agent method, job runner integration, event bus, WebSocket handler, and frontend UI
  • Graceful degradation: if decomposition fails, job continues without steps
  • Clean code structure throughout — well-commented sections

Verdict

Solid feature with a clear UX benefit. The step advancement heuristic is the main weakness. Needs rebase and migration renumber.

## Code Review: [claude] Task Decomposition View During Execution (#5) **Reviewer:** Timmy (automated review) **Recommendation:** REQUEST CHANGES (minor — good feature, needs rebase) ### Summary Adds visible task decomposition during job execution: Timmy breaks each request into 2-4 named sub-steps via Haiku, displays a checklist that ticks off as work streams, and collapses to "Done" on completion. Full vertical slice: backend decomposition, WebSocket events, and frontend checklist UI. ### Code Quality: B+ **Backend:** - `decomposeRequest()` uses Haiku (cheap eval model) to generate 2-4 step labels — good model selection for latency - Stub mode returns canned steps so UI testing works without API keys - JSON parsing has proper fallback (strips markdown fences, validates array length) - Steps persisted in `decomposition_steps` column (TEXT storing JSON) — fine for this use case - Step advancement heuristic based on character count is clever but approximate **Frontend:** - Checklist UI is clean with proper state transitions: pending (○) -> active (▶) -> complete (✓) - Color-coded states: green checkmark, yellow active, muted pending - Collapse-to-Done with 2.5s fade-out is nice UX - Panel positioned fixed bottom-right with pointer-events:none — non-intrusive **WebSocket integration:** - Two event types: `job:steps` (initial step list) and `job:step_update` (progress) - Clean separation between step delivery and step advancement ### Issues 1. **Not mergeable** — `Mergeable: False`. Needs rebase. 2. **Migration number conflict** — `0010_task_decomposition.sql`. 3. **Legacy wizard-era PR** (March 23, stale). 4. **Step advancement heuristic is fragile.** Uses `ESTIMATED_TOTAL_CHARS = 600` and divides evenly by step count. Short responses (< 600 chars) may never advance past step 0. Long responses advance too quickly. A token-count-based or time-based heuristic might be more robust. 5. **No step persistence on completion.** The final step states are broadcast via WebSocket but not persisted to the DB (only the initial step labels are stored). If a client reconnects mid-job, they won't see progress. 6. **Multiple concurrent jobs.** The UI doesn't handle multiple simultaneous jobs — `showJobSteps` replaces the current panel content entirely. If two jobs run at once, only the latest shows steps. ### What's Good - Full vertical slice: DB migration, schema change, agent method, job runner integration, event bus, WebSocket handler, and frontend UI - Graceful degradation: if decomposition fails, job continues without steps - Clean code structure throughout — well-commented sections ### Verdict Solid feature with a clear UX benefit. The step advancement heuristic is the main weakness. Needs rebase and migration renumber.
First-time contributor

Ezra review: Agent-generated PR from claude. Appears to be from Replit Timmy Tower sessions. Alexander — merge or close at your discretion.

Ezra review: Agent-generated PR from claude. Appears to be from Replit Timmy Tower sessions. Alexander — merge or close at your discretion.
Some checks failed
CI / Typecheck & Lint (pull_request) Failing after 0s
This pull request has changes conflicting with the target branch.
  • artifacts/api-server/src/lib/event-bus.ts
  • artifacts/api-server/src/routes/events.ts
  • the-matrix/js/ui.js
  • the-matrix/js/websocket.js
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin claude/issue-5:claude/issue-5
git checkout claude/issue-5
Sign in to join this conversation.
No Reviewers
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: replit/timmy-tower#93