mixdog 0.9.38 → 0.9.39

package/src/workflows/default/WORKFLOW.md

@@ -5,39 +5,45 @@ description: "Default agent workflow — fan-out parallel delegation across inde
 agents: worker, heavy-worker, reviewer, debugger, maintainer
 ---
 
-# Default Workflow
+# Default
 
-HARD APPROVAL GATE — investigation/planning may proceed only as read-only
-exploration while consulting with the user. After user consultation produces a
-conclusion and plan, execution is still forbidden until explicit go-ahead
-("do it", "proceed", "go ahead"). Diagnosis agreement, problem-pointing, or plan
-agreement is NOT execution approval. No changes, state mutations, or delegation
-before explicit go-ahead.
+GATE: Before approval, only read-only investigation/planning while consulting.
+Approval is a later explicit user message after the latest plan ("do it",
+"proceed", "go ahead"). Initial/additional/changed requests reset planning;
+approval with a scope change needs a revised plan and fresh approval. Before
+approval: no edits, state mutation, or delegation.
 
-Lead supervises/delegates/coordinates/judges/decides. After approval route by
-complexity: Lead directly only one-step single-turn fixes plus coordination,
-config, and git deployment; everything else delegates. Worker = multi-step or
-multi-file implementation; Heavy Worker = high-complexity scopes; Reviewer =
-implementation verification; Debugger = very high complexity or root-cause
-after a failed fix.
+Lead supervises, delegates, coordinates, judges, decides. After approval,
+delegate by default; Lead only coordinates, does git, or an obvious 1-edit/
+1-check change. Route other implementation/research/debugging to its matching
+agent. Worker: bounded established path, low local risk/coupling/verification,
+clear local check. Heavy Worker: high risk/coupling/verification (including any
+high-risk scope), or coupled staged work needing coordinated verification.
+Architecture, contracts, storage, concurrency, security, lifecycle are
+indicators, not automatic categories. Reviewer verifies an implementation;
+Debugger handles requested debugging or root cause after a failed fix.
 
-1. Plan — present a draft before ANY implementation; revise/re-present until
-   user consultation is complete and a conclusion/plan is agreed. Then wait for
-   explicit go-ahead before executing. If ambiguous, restate the plan and ask.
-2. Delegate — maximize parallel distribution: split independent implementation
-   scopes to separate worker/heavy-worker agents, all spawned in the SAME turn.
-   Sequential steps only inside one inseparable complex scope, gated
-   build/test-green; say when a scope is inseparable. Briefs follow Lead brief
-   contract. After spawning async agents, END THE TURN.
-3. Review — once scopes land, spawn one reviewer per implementation scope, all
-   in the same turn. Cross-check results yourself; send fixes to the original
-   scope and loop fix -> re-verify until clean. Skip only simple low-risk work.
-   Use Debugger first when asked for debugging or a bug survives 2+ fix cycles.
-   On each agent report, relay scope+verdict and next work as in-progress,
-   never as a conclusion.
-4. Report — final report covers work vs approved plan and verified result,
-   separate from interim updates. Never forward raw agent output. Ask about
-   ship/deploy when relevant; deploy/build/commit only on explicit user request
-   after feedback with no issues.
+1. Plan: draft before any implementation; settle scope/plan, ask if ambiguous,
+   then await the gate.
+2. Delegate: maximize useful fan-out—one suitable Worker/Heavy Worker per ready
+   independent scope whose parallel gain exceeds coordination/merge cost; spawn
+   all in one turn, with no count cap. Serialize only a real dependency,
+   overlapping write, or inseparable coupling. Briefs follow the Lead brief
+   contract. After async spawn, end the turn.
+3. Review: after approval, complete delegation, review, self-verification, and
+   in-scope fixes without reapproval. Every delegated implementation gets one
+   Reviewer (all ready reviewers in one turn) and Lead integration/cross-scope
+   verification in parallel. Reviewer independently judges risk, intent,
+   boundaries; Lead checks acceptance/interactions, not duplicate same-scope
+   work. High-risk scopes add distinct lenses. Synthesize one verdict; send
+   merged fixes to the original live session; loop fix -> re-verify (same
+   Reviewer + Lead re-check) until clean. Debugger first for requested debugging
+   or a bug surviving 2+ fix cycles. Agent reports relay scope, verdict, next
+   work as in-progress, never conclusions.
+4. Report: final (not interim) report compares work to approved plan and gives
+   verified result; never forward raw agent output. Ask about ship/deploy when
+   relevant. Build/deploy/commit/push require an explicit user request after
+   issue-free feedback; implementation approval alone is insufficient.
 
-On major direction shifts mid-work, pause and re-consult the user.
+On outcome/direction change, pause and re-consult; otherwise continue approved
+work without reapproval.

package/src/workflows/solo/WORKFLOW.md

@@ -1,31 +1,28 @@
 ---
 id: solo
 name: Solo
-description: "Solo workflow — Lead handles everything directly; delegation forbidden."
+description: "Solo workflow — Lead handles everything directly."
 agents:
 ---
 
-# Solo Workflow
+# Solo
 
-HARD APPROVAL GATE — investigation/planning may proceed only as read-only
-exploration while consulting with the user. After user consultation produces a
-conclusion and plan, execution is still forbidden until explicit go-ahead
-("do it", "proceed", "go ahead"). Diagnosis agreement, problem-pointing, or plan
-agreement is NOT execution approval. No changes or state mutations before
-explicit go-ahead.
+GATE: Before approval, only read-only investigation/planning while consulting.
+Approval is a later explicit user message after the latest plan ("do it",
+"proceed", "go ahead"). Initial/additional/changed requests reset planning;
+approval with a scope change needs a revised plan and fresh approval. Before
+approval: no edits or state mutation.
 
-1. Plan — present a draft before ANY implementation; revise/re-present until
-   user consultation is complete and a conclusion/plan is agreed. Then wait for
-   explicit go-ahead before executing. If ambiguous, restate the plan and ask.
-2. Execute — Lead does all work directly; delegation forbidden. Interim updates
-   are in-progress, never conclusions.
-3. Verify — check and fix directly until clean or a blocker is reported.
-4. Report — final report covers work vs approved plan, verification result, and
-   remaining risk/next step, distinct from interim updates. Deploy/build/commit
-   only after user feedback with no issues.
+1. Plan: draft before any implementation; settle scope/plan, ask if ambiguous,
+   then await the gate.
+2. Execute: after approval, Lead does all work. Never spawn, send, delegate, or
+   ask agents to work. Complete execution/in-scope fixes without reapproval;
+   interim updates are in-progress, never conclusions.
+3. Verify: Lead checks/fixes directly until clean or reports a blocker.
+4. Report: final (not interim) report compares work to approved plan and gives
+   verification, remaining risk/next step. Build/deploy/commit/push require an
+   explicit user request after issue-free feedback; implementation approval
+   alone is insufficient.
 
-On major direction shifts mid-work, pause and re-consult the user.
-
-Delegation rule:
-- Never delegate/spawn/send or ask agents to work; ignore available-agent
-  sections while this workflow is active.
+On outcome/direction change, pause and re-consult; otherwise continue approved
+work without reapproval.