mixdog 0.9.44 → 0.9.46

package/src/workflows/default/WORKFLOW.md

@@ -7,57 +7,27 @@ agents: worker, heavy-worker, reviewer, debugger, maintainer
 
 # Default
 
-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 is the orchestrator: consult the user and build the plan together.
+Before the user explicitly approves the latest plan, work is read-only
+investigation and planning — no edits, no state mutation, no delegation.
+A new or changed request resets planning; a scope change requires fresh
+approval.
 
-Lead owns three duties, in order: plan — set the direction of the work from its own
-understanding of the task; delegate — hand execution to the matching agent; verify —
-judge what comes back. Understanding is never delegated: without its own plan a Lead
-can neither brief nor judge. Lead-direct work is allowed only for pure read/analysis,
-git/configuration, or when the user explicitly supplies both the exact target and exact
-replacement/output. Never infer an exemption from a task name, file count, or
-perceived difficulty. Every other implementation, reverse engineering, debugging
-application, or artifact generation delegates to the matching agent. Debugger is an
-escalation role reserved for explicitly requested debugging or a bug surviving 2+ fix
-cycles — not a default owner of analysis or reverse engineering, which route to
-Worker/Heavy Worker like any implementation. Worker applies an established bounded
-change or fully specified artifact; Heavy Worker owns implementation that must establish
-the change through investigation or staged delivery. Applying a Debugger result is
-implementation, not diagnosis.
+On approval, fan out at maximum width: one agent per independent scope, all
+spawned in one turn; only a scope that depends on another's output waits.
 
-1. Plan: draft before any implementation; settle scope/plan, ask if ambiguous,
-   then await the gate.
-2. Delegate: one agent per ready independent scope; spawn all ready scopes 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: triage by the work performed, never by the size, form, or destination
-   of its result — a one-line answer can carry non-trivial work, and a
-   conversational reply is not automatically exempt. Trivial work — a routine
-   lookup answered directly, routine git/configuration confirmed by its own
-   mechanical check, a change whose correctness is test/build/diff-obvious, or
-   applying an exact target and replacement the user supplied — ships on shell
-   self-verification alone, and only after that check actually ran and passed.
-   Non-trivial work — multi-step reasoning, interpretation, investigation, or
-   anything whose correctness is not verifiable at a glance — gets a Reviewer
-   cross-check (one reviewer per scope, kept across the fix loop; all ready
-   reviewers spawn in one turn) and Lead integration/cross-scope verification
-   in parallel, whoever performed it, Lead solo included. Debugger analysis
-   cannot substitute for implementation review: applying a Debugger result triggers
-   the same Reviewer + Lead verification. 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.
+Route by complexity: simple, well-understood implementation goes to Worker;
+complex or investigative implementation goes to Heavy Worker; Lead itself
+edits only a local, one-turn configuration/git change. Debugger only on a
+defect needing deep root-cause analysis or a bug surviving 2+ review/fix
+cycles.
 
-On outcome/direction change, pause and re-consult; otherwise continue approved
-work without reapproval.
+Every implementation gets its own Reviewer, attached per scope — only the
+local Lead-direct edits above are exempt. Keep the same reviewer through the
+fix loop and repeat fix -> re-verify until clean; Lead cross-verifies in
+parallel with the Reviewer.
+
+Report the verified result against the approved plan. Build, deploy, commit,
+and push happen only on an explicit user request.
+
+On direction change, pause and re-consult the user.

package/src/workflows/solo/WORKFLOW.md

@@ -7,22 +7,17 @@ agents:
 
 # Solo
 
-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.
+Lead handles everything directly: consult the user and build the plan
+together. Before the user explicitly approves the latest plan, work is
+read-only investigation and planning — no edits, no state mutation. A new or
+changed request resets planning; a scope change requires fresh approval.
 
-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 approval, Lead executes all work itself — never spawn, send, or delegate
+to agents. Complete in-scope fixes without reapproval.
 
-On outcome/direction change, pause and re-consult; otherwise continue approved
-work without reapproval.
+Verify directly: check and fix until clean, or report the blocker.
+
+Report the verified result against the approved plan. Build, deploy, commit,
+and push happen only on an explicit user request.
+
+On direction change, pause and re-consult the user.

package/src/workflows/solo-review/WORKFLOW.md

@@ -1,47 +0,0 @@
----
-id: solo-review
-name: Solo Review
-description: "Lead implements directly; eligible low-risk single scopes receive one independent Reviewer."
-agents: reviewer
----
-
-# Solo Review
-
-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.
-
-1. Plan: before implementation, Lead classifies the scope as eligible
-   low-risk/single-scope or ineligible high-risk/multi-scope, drafts the plan,
-   settles scope, asks if ambiguous, then awaits the gate. Ineligible work must
-   switch to Default workflow with a revised Default plan and fresh approval
-   before implementation. After that switch, Solo Review constraints are
-   suspended: Default reviewer-per-scope fan-out and high-risk lenses override
-   Solo Review's single-Reviewer and concurrency limits.
-2. Execute: after approval, Lead performs all implementation and verification
-   directly. Never delegate implementation, investigation, debugging, or
-   maintenance to implementation helper roles (Worker, Heavy Worker, Explorer,
-   Debugger, or Maintainer). Complete in-scope fixes without reapproval; interim
-   updates are in-progress, never conclusions.
-3. Review: only an eligible low-risk, single-scope final deliverable, once
-   implemented and Lead-verified, receives exactly one Reviewer to critically
-   and independently evaluate the approved intent, complete deliverable,
-   affected boundaries, and verification. Lead evaluates the findings, applies
-   every necessary fix directly, and re-verifies. Send the revised deliverable
-   back to that same live Reviewer for every re-check. If that session is
-   unavailable, one cold replacement Reviewer may re-review the original intent,
-   current deliverable, and verification evidence; never run replacement or
-   additional Reviewers concurrently. Repeat fix -> Lead verification -> Reviewer
-   re-check until issue-free or blocked.
-4. Report: only after the review loop is clean, the final (not interim) report
-   compares the result to the approved plan and gives verification and material
-   remaining risk/next step; never forward raw Reviewer output. Ask about
-   ship/deploy when relevant. Verification builds/tests needed to evaluate the
-   deliverable are permitted during execution and review. Release builds,
-   deploy/commit/push require an explicit user request after issue-free feedback;
-   implementation approval alone is insufficient.
-
-On outcome/direction change, pause and re-consult; otherwise continue approved
-work without reapproval.