Adds `cw account extract [--email <email>]` subcommand to the accountCommand
group. Reads directly from the local Claude config via extractCurrentClaudeAccount()
without requiring a server connection. Supports optional email verification,
outputting JSON with email, configJson (stringified), and credentials fields.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Adds the addAccountByToken procedure to accountProcedures(), which
accepts an email and raw OAuth token, stores the token as claudeAiOauth
credentials, and upserts the account (create or updateAccountAuth based
on findByEmail). Covers the four scenarios with unit tests: new account,
existing account, empty email, and empty token validation errors.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Task dispatch computed baseBranch as the phase branch name but never
ensured it existed in the git clone. When phases weren't dispatched
through the PhaseDispatchManager (which creates branches), the
git worktree add failed with "fatal: invalid reference".
Now DefaultDispatchManager calls ensureBranch for both the initiative
and phase branches before spawning, matching what PhaseDispatchManager
already does.
Blocked tasks (from spawn failures) were a dead-end with no way to
recover. Add retryBlockedTask to DispatchManager that resets status
to pending and re-queues, a tRPC mutation that also kicks dispatchNext,
and a Retry button in the task slide-over when status is blocked.
agent:output is high-frequency streaming data that was included in
ALL_EVENT_TYPES and AGENT_EVENT_TYPES, causing every onEvent/onAgentUpdate
SSE subscription to register a listener. With multiple subscriptions per
browser tab plus reconnections, this exceeded the 100 listener limit.
The dedicated onAgentOutput subscription handles output streaming already.
Bonus: stops useLiveUpdates from refetching listAgents on every output chunk.
Prevents two bugs in the resumeForCommit flow:
1. Agent navigated to main repo instead of worktree due to relative paths
in commit prompt — now uses absolute paths from getDirtyWorktreePaths
2. git add -A staged unrelated files (screenshots, other agents' work) —
now uses git add -u to only stage tracked modified files
Task-level approval (requiresApproval, mergeRequiresApproval,
pending_approval status) was redundant with executionMode
(yolo vs review_per_phase) and blocked the orchestrator's
phase completion flow. Tasks now complete directly;
phase-level review via executionMode is the right granularity.
Removed: schema columns (left in DB, removed from Drizzle),
TaskPendingApprovalEvent, approveTask/listPendingApprovals
procedures, findPendingApproval repository method, and all
frontend approval UI.
When all phases complete, the initiative now transitions to
pending_review status instead of silently stopping. The user
reviews the full initiative diff and chooses:
- Push Branch: push cw/<name> to remote for PR workflows
- Merge & Push: merge into default branch and push
Changes:
- Schema: Add pending_review to initiative status enum
- BranchManager: Add pushBranch port + SimpleGit adapter
- Events: initiative:pending_review, initiative:review_approved
- Orchestrator: checkInitiativeCompletion + approveInitiative
- tRPC: getInitiativeReviewDiff, getInitiativeReviewCommits,
getInitiativeCommitDiff, approveInitiativeReview
- Frontend: InitiativeReview component in ReviewTab
- Subscriptions: Add initiative events + missing preview/conversation
event types and subscription procedures
- Add getActiveRefineAgent to spawn mutation optimistic updates and
live event invalidation rules so the refine panel reflects agent
state immediately without manual refresh
- Accept optional instruction param in buildRefinePrompt() and inject
it as <user_instruction> block so the agent knows what to focus on
- Pass input.instruction through in architect router spawn call
Wrap agentManager.spawn() in try/catch — on failure, block the task
instead of crashing the entire dispatch cycle. Move phase status update
to after branch creation succeeds — on branch failure, block the phase
and skip task queuing. Fix statement-breakpoint markers in migration
0020 to use separate lines.
Containerize Codewalkers with a multi-stage Docker build (Node + Caddy) and
add a seed script that populates the database with a demo initiative, 3 phases,
9 tasks, 3 agents with JSONL log output, a root page, review comments, and a
git repo with real branch diffs for the review tab.
Run project-specific initialization commands (DB migrations, fixture
loading, etc.) automatically after containers are healthy, before the
preview is marked ready. Configured via per-service `seed` arrays in
.cw-preview.yml.
Refactor preview deployments to use a single shared Caddy gateway container
with subdomain routing (<previewId>.localhost:<port>) instead of one Caddy
sidecar and one port per preview. Adds dev/preview modes, git worktree
support for branch checkouts, and auto-start on phase:pending_review.
- Add GatewayManager for shared Caddy lifecycle + Caddyfile generation
- Add git worktree helpers for preview mode branch checkouts
- Add dev mode: volume-mount + dev server image instead of build
- Remove per-preview Caddy sidecar and port publishing
- Use shared cw-preview-net Docker network with container name DNS
- Auto-start previews when phase enters pending_review
- Delete unused PreviewPanel.tsx
- Update all tests (40 pass), docs, events, CLI, tRPC, frontend
- Add PhaseChangesRequestedEvent to event bus
- Add requestChangesOnPhase() to ExecutionOrchestrator: reads unresolved
comments, creates revision task (category='review'), resets phase to
in_progress, queues task for dispatch
- Expand merge-skip and branch routing to include 'review' category so
revision tasks work directly on the phase branch
- Add requestPhaseChanges tRPC procedure (reads comments from DB)
- Wire frontend: mutation replaces stub handler, window.prompt for
optional summary, loading state on button
- Track worktree removal success in autoCleanupAfterCompletion() instead of
always returning removed:true when removeAgentWorktrees() throws
- Add removeAgentBranches() call to auto-cleanup path (agent/* branches were
never cleaned after completion)
- Add filesystem cleanup (worktrees, branches, logs) to dismiss() to prevent
resource leaks until next server restart
- Add BranchManager.listCommits() and diffCommit() for commit-level navigation
- Add getPhaseReviewCommits and getCommitDiff tRPC procedures
- New ReviewHeader: consolidated toolbar with phase selector pills, branch info,
stats, integrated preview controls, and approve/reject actions
- New CommitNav: horizontal commit strip with "All changes" + individual commits,
each showing hash, message, and change stats
- Slim down ReviewSidebar: file list only with dimming for out-of-scope files
when viewing a single commit
- ReviewTab orchestrates all pieces in a single bordered card layout
commitRetryCount was being deleted in cleanupAgentState(), which runs
before tryAutoCleanup() checks the count. This reset the counter to 0
on every cycle, making MAX_COMMIT_RETRIES=1 dead code. Agents would
retry commits forever.
Move commitRetryCount cleanup to stop()/delete() only, letting
tryAutoCleanup() manage it during the retry lifecycle.
The orchestrator's agent:stopped listener only called scheduleDispatch(),
never marking the agent's assigned task as completed. Tasks stayed
in_progress forever after their agent finished.
Now handleAgentStopped() calls dispatchManager.completeTask() before
scheduling new dispatches, respecting requiresApproval and skipping
manual (user_requested) stops.
ExecutionOrchestrator now listens for phase:queued and agent:stopped
events to drive the dispatch cycle, closing the gap between queueing
phases (Execute button) and actually spawning agents. Coalesced
scheduling prevents reentrancy with synchronous EventEmitter.
Replace readFileSync/writeFileSync/mkdirSync with async equivalents from
fs/promises in default-credential-manager.ts and usage.ts to stop blocking
the Node.js event loop during credential read/write operations.
readFrontmatterFile, readFrontmatterDir, readSummary, readPhaseFiles,
readTaskFiles, readDecisionFiles, and readPageFiles all used readFileSync
and readdirSync which block the Node.js event loop during agent completion
handling. Converted to async using readFile/readdir from fs/promises and
added await at all call sites in output-handler.ts.
Removes blocking readFileSync, writeFileSync, and mkdirSync calls from the
agent spawn hot path, replacing them with async fs/promises equivalents to
avoid stalling the Node.js event loop during credential operations.
writeInputFiles, spawnDetached, and diagnostic writes now use
fs/promises (mkdir, writeFile) instead of mkdirSync/writeFileSync.
File writes in writeInputFiles are batched with Promise.all.
openSync/closeSync for child process stdio FDs remain sync as
spawn() requires the FDs immediately.
sendChatMessage was awaiting the full agentManager.spawn() which
includes worktree creation, ~50 writeFileSync calls for input files,
credential setup, and process spawning. This blocked the Node.js event
loop long enough to cause ECONNREFUSED on the SSE connection.
Now the mutation returns immediately after storing the user message
and creating the task. The heavy spawn work runs in a detached promise.
On failure, a system message is stored so the UI can display the error.
Agents were bulk-reading all context task files (39 files) because
filenames are opaque IDs and there was no way to find phase-relevant
tasks without reading every file. Now writeInputFiles generates a
context/index.json with tasksByPhase mapping phaseId to task metadata
(file, id, name, status). Prompt updated to direct agents to read
the index first.
Agents were reading all contextFiles (38 tasks + 8 phases) upfront,
wasting massive context window. Updated INPUT_FILES and SESSION_STARTUP
prompts to clearly distinguish assignment files (read all) from context
files (read only when needed).
Add findByProjectId to InitiativeRepository using a subquery on the
initiative_projects junction table. Extend the listInitiatives tRPC
procedure to accept an optional projectId filter that composes with
the existing status filter. Add a project dropdown to the initiatives
page alongside the status filter.
Pass targetId to buildChatPrompt and add <scope> block that clearly
distinguishes primary target files from context files. Context entities
may be modified when necessary (e.g. dependency links) but the agent
is instructed to focus changes on the primary target.
Added retry:true flag to sendChatMessage input. Server skips storing
the user message when retry is set. Frontend uses a dedicated
retryLastMessage function that skips the optimistic message add.
The createContext call manually enumerates every field rather than
spreading, so the new repo was silently dropped even though it existed
on the options object.
The repo was created in container.ts but silently dropped because
TrpcAdapterOptions (which derives ServerContextDeps) was missing the
field. This caused 500 errors on all chat session procedures.
Each execute agent has significant startup cost (context loading, codebase
exploration, baseline tests). The previous sizing guidance (sweet spot
<150 lines, 1-3 files, merge at <20 lines) produced tasks too small to
justify that overhead.
New guidance targets cohesive feature units: 200-500 lines across 3-6
files as the sweet spot, merge threshold at <100 lines, and explicit
instruction to bundle related changes (validation + route + tests = one
task, not three).
The Execution tab's PipelinePhaseGroup was using sortByPriorityAndQueueTime
which ignores task dependencies entirely. Tasks now sort topologically via
topologicalSortPhases, matching the Plan tab's TaskGraph behavior.
- Add listInitiativeTaskDependencies tRPC procedure (bulk fetch)
- Fetch task deps in PipelineTab, group by phase, pass through
- Replace priority sort with topological sort in PipelinePhaseGroup
- Show "blocked by N" count on PipelineTaskCard
Introduces a chat loop where users send instructions to an agent that
applies changes (create/update/delete phases, tasks, pages) and stays
alive for follow-up messages. Includes schema + migration, repository
layer, chat prompt, file-io action field extension, output handler chat
mode, revert support for deletes, tRPC procedures, events, frontend
slide-over UI with inline changeset display and revert, and docs.
The auto-spawned agent on initiative creation was using discuss mode
(Q&A) when it should use refine mode (expand content). Now:
- Description seeds root page as tiptap content (split on double newlines)
- Spawns refine agent with the populated page in inputContext
- getActiveRefineAgent broadened to also surface discuss agents (for
CLI-spawned discuss agents)
- RefineAgentPanel shows mode-appropriate label for discuss vs refine
The discuss agent spawned on initiative creation received only the
initiative in its inputContext, missing the task that carries the user's
description. The agent started without knowing what to discuss.
Auto-spawned discuss/plan/refine agents were invisible because:
1. listInitiatives only filtered for mode='detail' agents
2. deriveInitiativeActivity returned 'idle' for zero phases before
checking for active agents
Broadened agent filter to all architect modes (discuss, plan, detail,
refine), moved active agent check before zero-phases early return, and
added 'discussing'/'refining' activity states with pulsing indicators.
Prompt changes in detail.ts invalidated the old cassette hashes.
Re-recorded all 4 cassettes with updated prompt content. Replay
verified passing in 12s.
Detail agents define task dependencies in YAML frontmatter but they were
silently dropped — never written to the task_dependencies table. This
caused all tasks to dispatch in parallel regardless of intended ordering,
and the frontend showed no dependency information.
- Add fileIdToDbId mapping and second-pass dependency creation in
output-handler.ts (mirrors existing phase dependency pattern)
- Add task_dependency to changeset entry entityType enum
- Add listPhaseTaskDependencies tRPC procedure for batch querying
- Wire blockedBy in PhaseDetailPanel and PhaseWithTasks from real data
- Clarify dependency semantics in detail prompt
Execution agents were spawning blind — no input files, no knowledge of
what predecessor tasks accomplished. This adds three capabilities:
1. summary column on tasks table — completeTask() reads the finishing
agent's result.message and stores it on the task record
2. dispatchNext() gathers full initiative context (initiative, phase,
sibling tasks, pages) and passes it as inputContext so agents get
.cw/input/task.md, initiative.md, phase.md, and context directories
3. context/tasks/*.md files now include the summary field in frontmatter
so dependent agents can see what prior agents accomplished
