From e4087a7dc133fe8c8523ca585b1841ff2b0be2d9 Mon Sep 17 00:00:00 2001 From: Claude Sonnet 5 Date: Sat, 4 Jul 2026 04:08:41 +0000 Subject: feat(story): add StoryOrchestrator -- 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 Claude-Session: https://claude.ai/code/session_01V1moSNCJRcP6kykA4tyUSs --- internal/cli/serve.go | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'internal/cli') diff --git a/internal/cli/serve.go b/internal/cli/serve.go index 656ee66..7ee8d49 100644 --- a/internal/cli/serve.go +++ b/internal/cli/serve.go @@ -265,6 +265,20 @@ func serve(addr, basePath string) error { } go sch.Run(ctx, cfg.Scheduler.PollInterval()) + // Story orchestrator (internal/scheduler.StoryOrchestrator, Phase 7b): + // drives stories through Builder -> Evaluators -> Arbitration -> + // REVIEW_READY as their root/evaluator/arbitration tasks reach COMPLETED + // (always via human/chatbot accept, since these are all top-level + // tasks — see that type's doc comment for why this is poll-based rather + // than hooked into executor.Pool.handleRunResult). Also `serve`-only, + // same reasoning as the scheduler above. + storyOrch := &scheduler.StoryOrchestrator{ + Store: store, + Pool: pool, + Logger: logger, + } + go storyOrch.Run(ctx, scheduler.DefaultStoryPollInterval) + httpSrv := &http.Server{ Addr: addr, Handler: srv.Handler(), -- cgit v1.2.3