From 8cb291ad7cdb317ff80947278ee055b1a4925b41 Mon Sep 17 00:00:00 2001 From: Claude Sonnet 5 Date: Sat, 4 Jul 2026 05:05:36 +0000 Subject: feat(story,role): add retro ceremony -- closes the self-improvement loop (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 Claude-Session: https://claude.ai/code/session_01V1moSNCJRcP6kykA4tyUSs --- internal/executor/agentmcp.go | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) (limited to 'internal/executor/agentmcp.go') diff --git a/internal/executor/agentmcp.go b/internal/executor/agentmcp.go index c0088c5..a89c670 100644 --- a/internal/executor/agentmcp.go +++ b/internal/executor/agentmcp.go @@ -6,11 +6,13 @@ import ( "encoding/hex" "encoding/json" "errors" + "fmt" "net/http" "strings" "sync" "github.com/modelcontextprotocol/go-sdk/mcp" + "github.com/thepeterstone/claudomator/internal/role" ) // Registry maps per-task MCP bearer tokens to a built agent MCP server. A token @@ -79,6 +81,30 @@ type proposeEpicInput struct { StoryIDs []string `json:"story_ids" jsonschema:"the story IDs to group under this epic"` } +// proposeRoleConfigInput mirrors internal/role.RoleConfig's fields directly +// (same json tags) rather than defining a parallel shape, so the tool's +// input decodes straight into a role.RoleConfig with no field-by-field +// translation. See propose_role_config below. +type proposeRoleConfigInput struct { + Role string `json:"role" jsonschema:"the role name this config applies to (e.g. an existing role like builder, or a new one)"` + SystemPrompt string `json:"system_prompt,omitempty" jsonschema:"system prompt appended for tasks dispatched through this role"` + Tools []string `json:"tools,omitempty" jsonschema:"optional tool allowlist for this role"` + SandboxKind string `json:"sandbox_kind,omitempty" jsonschema:"optional sandbox kind for this role"` + DefaultBudgetUSD float64 `json:"default_budget_usd,omitempty" jsonschema:"optional estimated budget in USD, used when the scheduler considers escalating this role's tasks"` + EscalationLadder []role.Tier `json:"escalation_ladder,omitempty" jsonschema:"ordered list of escalation tiers; each has candidates (provider/model pairs), an optional selection_mode (round_robin|single), and max_retries"` +} + +func (in proposeRoleConfigInput) toRoleConfig() role.RoleConfig { + return role.RoleConfig{ + Role: in.Role, + SystemPrompt: in.SystemPrompt, + Tools: in.Tools, + SandboxKind: in.SandboxKind, + DefaultBudgetUSD: in.DefaultBudgetUSD, + EscalationLadder: in.EscalationLadder, + } +} + func textResult(text string) *mcp.CallToolResult { return &mcp.CallToolResult{Content: []mcp.Content{&mcp.TextContent{Text: text}}} } @@ -158,6 +184,17 @@ func newAgentServer(ch AgentChannel) *mcp.Server { return textResult("Proposed epic " + id), nil, nil }) + mcp.AddTool(s, &mcp.Tool{ + Name: "propose_role_config", + Description: "Propose a new draft configuration version for a role, after reflecting on what happened (e.g. during a story retro). Creates a new draft role_configs row for a human to review and activate via POST /api/roles/{role}/activate -- it never changes what is currently active.", + }, func(ctx context.Context, _ *mcp.CallToolRequest, in proposeRoleConfigInput) (*mcp.CallToolResult, any, error) { + version, err := ch.ProposeRoleConfig(ctx, in.toRoleConfig()) + if err != nil { + return nil, nil, err + } + return textResult(fmt.Sprintf("Proposed role config %s v%d (draft)", in.Role, version)), nil, nil + }) + return s } -- cgit v1.2.3