coder-loop ยท diff
git:20260815.78cdb07 to git:20260816.16b23e9
95 added, 40 removed. Audit A to A.
---
name: coder-loop
description: >-
Run the Codex Optimized Development, Evaluation, and Remediation (CODER)
Loop with an orchestration-only coordinator, non-overlapping task-family
owners, fresh independent reviewers, evidence-scoped remediation, and final
- coordinator acceptance. Use in Codex when the user invokes the CODER Loop,
- asks to divide a complex change into bounded implementation families with
+ coordinator acceptance. Discover and compose optional MSW, Timebox, MSL, and
+ Codex Voice Optimizer companions as the Slopware Dev Stack without making
+ them dependencies. Use in Codex when the user invokes the CODER Loop, asks
+ to divide a complex change into bounded implementation families with
independent reviewers, requests multi-agent implementation without
- overlapping ownership, or requires review and repair to repeat until every
- acceptance-blocking gap is independently rechecked. Do not trigger for an
- ordinary single-agent change, a review-only request, or a non-Codex host.
+ overlapping ownership, requires review and repair until every blocking gap
+ is independently rechecked, asks for the CODER tutorial or Slopware Dev
+ Stack, or wants CODER to install or use its companions. Do not trigger for
+ an ordinary single-agent change, a review-only request, or a non-Codex host.
---
# CODER Loop
CODER stands for Codex Optimized Development, Evaluation, and Remediation. The
loop uses bounded task-family review to give complex implementation clear
ownership, independent evaluation, and evidence-scoped repair.
+ It is also the development engine of the Slopware Dev Stack: CVO can control
+ it, MSW keeps it necessary, Timebox makes an authorized run converge, and MSL
+ makes the user-facing result clear. Every layer remains optional and
+ independently installable.
+
Turn a complex implementation into a small set of coherent ownership lanes,
then make every candidate earn acceptance in a fresh context. Keep the parent
as coordinator and final decision owner. Let workers implement, reviewers
review, and only admitted acceptance gaps create repair work.
- Require Codex collaboration capabilities that can provide at least one
- implementation subagent and one fresh review subagent. If either capability is
- unavailable, state what is missing and stop without claiming that the CODER
- Loop completed.
+ ## Activate the CODER Loop
+ Read [references/companions.md](references/companions.md) once on activation.
+ Discover the active Slopware companion catalog, apply the available composition
+ rules, and present the stack once without delaying work.
+
+ When the user asks to learn CODER or see the Slopware Dev Stack, read
+ [references/workflows/tutorial.md](references/workflows/tutorial.md) and teach
+ before taking any live action. The teaching-only tutorial does not require
+ repository, project, task, or collaboration capabilities.
+
+ For bare activation without an implementation outcome, explain in one sentence
+ that CODER uses bounded workers, fresh evaluation, and targeted remediation,
+ then offer the tutorial, a real outcome, or the stack overview. Do not ask the
+ vague question "what should we do?"
+
+ A live loop requires Codex collaboration capabilities that can provide at
+ least one implementation subagent and one fresh review subagent. If either
+ capability is unavailable, state what is missing and stop the live loop without
+ claiming completion. Continue answering questions and teaching the tutorial.
+
## Bind the decision
Before delegating, establish:
- the requested outcome;
- the complete candidate boundary, including source, tests, generated files,
configuration, and relevant untracked files;
- the retained behavior that must survive;
- the smallest acceptance claims that prove the outcome;
- the current repository state and user changes that must be preserved;
- - explicit scope, external-write, commit, and publication authority.
+ - explicit scope, top-level task creation or fork, external-write, commit, and
+ publication authority.
Ask only when a missing owner decision can materially change those facts. Do
not turn setup into a form, ledger, acknowledgment, or approval ritual.
## Decompose into task families
Define a task family as one coherent body of implementation with one owner,
one candidate boundary, and one proof surface. Group closely related work when
splitting it would create coordination without independent progress. Separate
work when ownership, dependencies, files, or proof can remain distinct.
- Give each family exactly one implementation owner.
- Prevent overlapping file or behavior ownership. Sequence families whose
candidates can invalidate each other.
- Run families concurrently only when they are genuinely independent.
- Preserve related repairs with the original worker when practical.
- - Use one family when the task does not justify more. The CODER Loop never invents agent
- count or parallelism.
+ - Use one family when the task does not justify more. The CODER Loop never
+ invents agent count or parallelism.
## Use Codex collaboration
Read [references/codex.md](references/codex.md) before spawning. Keep the
- current Codex task as the coordinator and use collaboration subagents for
- ordinary implementation and independent review. At any point in the loop, when
- a role must inherit completed task history through a fork and also use a
- different model or reasoning effort, use the explicit two-step top-level task
- route defined there. This rule applies to initial implementation, repair,
- integration, or any other role for which both requirements are present.
+ current Codex task as the coordinator and use collaboration subagents as the
+ standard mechanism for implementation, repair, integration, and independent
+ review:
+ - use `fork_turns: "all"` when a role needs the coordinator history and its
+ current model and reasoning effort;
+ - use `fork_turns: "99"` with explicit `model` and `reasoning_effort` when a
+ role needs inherited working context and a different execution profile;
+ - use `fork_turns: "none"` for a fresh independent reviewer, selecting its
+ model and reasoning effort explicitly when required.
+
+ Always send the complete bounded role contract. Inherited context does not
+ replace role, scope, candidate, evidence, or authority instructions.
+
+ Use a top-level Codex task only after the user explicitly authorizes its
+ creation or fork and the role genuinely needs separate task lifecycle or
+ addressability, project or worktree placement unavailable to the collaboration
+ route, or an exact source-task history that the bounded subagent route cannot
+ supply. The explicit fork and first-continuation procedure in the Codex
+ reference is a fallback for those cases, not the normal model-routing
+ mechanism. Without that authority, stay inside collaboration subagents or
+ report the exact lifecycle need that remains unmet.
+
Choose the minimum capable model and reasoning effort from the settings exposed
- by the Codex route actually being used. For a collaboration subagent, use only
- settings that its spawn capability accepts. For a top-level fork, use settings
- that its first continuation accepts. Use a project or user model policy when
+ by the Codex route actually being used. Use a project or user model policy when
one exists. Otherwise prefer the inherited model and change it only when task
evidence shows that another capability or cost profile is needed. Never
hard-code a vendor lineup into the loop.
Classify a task only when the host exposes a meaningful model choice:
- **Mechanical:** an exact reproducer, bounded required change, no unresolved
contract, design, ownership, or proof choice, and deterministic evidence.
- **Reasoning-required:** uncertainty remains in cause, semantics,
architecture, implementation direction, ownership, or proof design.
Assign the minimum capable worker. A small diff alone does not make a task
mechanical. After review, classify a repair from the admitted gap rather than
reusing the original task label by habit.
## Run the implementation and review loop
For each task family:
1. Send the bounded contract from
[references/role-contracts.md](references/role-contracts.md) to its worker.
2. Let the worker implement and verify the family. Collect the exact candidate,
diff, and belonging evidence, not merely a success summary.
3. Freeze that candidate long enough to review it. Start a fresh reviewer that
did not implement it and has not received the implementer's reasoning or
conclusions.
4. Give the reviewer the decision, complete candidate boundary, retained
behavior, acceptance claims, raw artifacts, and verification evidence.
5. Apply [references/review-kernel.md](references/review-kernel.md). Admit only
observations whose deletion would leave an acceptance claim unmet or
unsupported.
6. Return each admitted blocking gap to the family owner for the smallest
sufficient repair. Do not turn optional improvements into repair work. If
- the repair requires a new inherited-history fork with different model or
- reasoning settings, apply the same two-step top-level task route.
+ the repair needs inherited working context with different model or
+ reasoning settings, use the same `fork_turns: "99"` collaboration route.
7. Start another fresh review of the changed candidate. Reconsider only the
acceptance claims the repair could affect.
8. Repeat while an acceptance-blocking gap remains. Stop and withhold
acceptance when a live gap cannot be closed inside the user's scope or
authority.
Do not assign the reviewer to repair its own findings. A reviewer can explain
evidence and contract impact, but the worker owns changes and the coordinator
owns acceptance.
## Preserve evidence across repairs
Treat review evidence as belonging to the candidate it observed. When the
candidate changes, invalidate only evidence for claims the change could affect.
Do not rerun unrelated review, discard still-belonging proof, or assume that a
changed test suite proves retained product behavior.
Use the contract to decide what remains live:
- A newly added file makes any earlier review that omitted it incomplete.
- A narrow source repair does not erase unrelated proof.
- A changed test can settle only the behavior it actually observes.
- A removed behavior does not remain an acceptance claim unless the approved
contract retains it.
## Integrate and accept
Keep worker and reviewer reports as evidence, never as acceptance. Have the
- coordinator inspect the integrated candidate, resolve cross-family conflicts,
- confirm the required proof, and decide:
+ coordinator inspect the integrated candidate and identify any cross-family
+ conflict. Route every required source, test, or configuration change to a
+ bounded integration owner and review that candidate through the same loop.
+ Then confirm the required proof and decide:
- **accept** when every live acceptance claim has belonging evidence; or
- **withhold** when at least one live claim remains unsettled.
Do not add an arbitrary review-round limit. Stop at the acceptance fixed point,
an explicit user stop, or a genuine blocker. Report the accepted result and
proof, or the exact open claim and authority needed to continue.
+ When an authorized Timebox wraps the loop, its hard stop ends work but never
+ changes the acceptance test. Withhold acceptance for every unsettled claim and
+ report the strongest proven candidate.
+
## Review the completed loop
After acceptance or a genuine terminal block, read
[references/postmortem.md](references/postmortem.md). Treat the postmortem as
routing calibration, not another candidate review or acceptance gate.
Assess whether each task family's classification and model assignment proved
sufficient, whether review or remediation changed that judgment, and whether
scope, evidence, authority, or an authoritative time constraint explains the
result better than model capability. Use the completed loop evidence and any
comparable records already authorized by the project.
Recommend at most one controlled mapping change, and only when repeated
comparable records show complete evidence, stable scope, and no
reasoning-required remediation. One successful assignment never lowers a
future default. Any recommendation applies only to the next comparable task
and preserves the same independent-review standard.
Do not create a mandatory `CODER_LEDGER.md` or other record merely to prove the
loop ran. If no comparable history exists, treat the completed loop as one
observation and make no mapping change.
## Preserve authority
Delegation never expands authority. Keep pushes, branch publication, pull or
merge requests, comments, approvals, merges, deployments, destructive actions,
and other external writes prohibited unless the user explicitly authorizes the
specific action. Preserve implementation, staging, commit, and publication as
separate boundaries.
- Archive every temporary top-level Codex task that the CODER Loop created or
- forked after its role is terminal and the coordinator has captured its result and evidence.
- Never archive the coordinator, a pre-existing user task, a task still handling
- repair, or a task waiting for user input.
+ Archive every temporary top-level fallback task that the CODER Loop created or
+ forked after its role is terminal and the coordinator has captured its result
+ and evidence. Never archive the coordinator, a pre-existing user task, a task
+ still handling repair, or a task waiting for user input.
Do not create a mandatory ledger, timer, hook, advisor pass, model roster, or
- status ceremony. Apply another skill or project policy alongside the CODER Loop only when
- the user or an authoritative project rule invokes it. A required advisor can
- challenge the coordinator's judgment, but never replaces independent review or
- the coordinator's final acceptance decision.
+ status ceremony. Apply another skill or project policy alongside the CODER
+ Loop only when the user or an authoritative project rule invokes it. A required
+ advisor can challenge the coordinator's judgment, but never replaces
+ independent review or the coordinator's final acceptance decision.
- ## Compose with Slopware skills
+ ## Compose the Slopware Dev Stack
- - Apply MSW, when available, to task-family admission, finding admission, and
- repair scope.
- - Apply MSL, when available, to the final coordinator report after the complete
- evidence is known.
- - Under Codex Voice Optimizer, run the CODER Loop inside an owning work task. Keep the
- voice coordinator limited to routing and user-facing synthesis.
+ Use [references/companions.md](references/companions.md) as the single contract
+ for discovery, activation state, boundary ownership, installation, and stack
+ presentation.
+
+ - Apply MSW to work admission when it is available.
+ - Activate Timebox only from explicit requester authority or applicable project
+ policy. Keep one fixed clock owned by the CODER coordinator.
+ - Apply MSL once at the final user-facing boundary after raw evidence settles
+ acceptance.
+ - Under CVO, keep the CODER Loop inside an owning work task. CVO routes committed
+ intent and speaks material state; it never becomes the CODER coordinator,
+ worker, reviewer, or clock owner.
+
+ When the user asks what the system supports, present the CODER development
+ engine and optional stack layers as one coherent product family: install one
+ layer or compose the stack. Every skill works alone, and all are free forever.