SOP-Driven Team

Message pool

Implement the SOP-Driven Team pattern in this codebase, using the LLM client and language we already use.

## Goal

Run a fixed procedure of role agents, where each role turns the documents it subscribes to into one structured document of its own, ending with a quality check that can send work back.

## How it works

1. Write the procedure down as an ordered list of roles. For each role, record the document types it reads and the one document type it writes, with a template for that document.
2. Keep a message pool: an append-only store of documents, each tagged with its type and author. Post the user's requirement to it.
3. For each role in order, collect the documents it subscribes to from the pool and call it with the Role agent prompt, filling in its profile and its output template.
4. Validate each output against its template (required sections present, code parses) and publish it to the pool; on a validation failure, retry that role once with the errors.
5. Run the QA role with the QA engineer prompt and publish its report to the pool. If the report lists failures, run the engineer again with it, then QA again.
6. When QA passes, return the final code with every document in the pool.

## Prompts

### Role agent prompt

```markdown
You are the {{role}} on a software team. Your goal: {{role_goal}}
You follow the team's standard procedure; do only your own step.

<inputs>
{{subscribed_documents}}
</inputs>

Produce your {{document_type}}, using exactly this template:
<template>
{{output_template}}
</template>

Fill every section. Where an input is unclear, state your assumption in
the document's "Assumptions" section instead of asking questions.
```

### QA engineer prompt

```markdown
You are the QA engineer. Check the code against the requirements and design.

<requirements>{{prd}}</requirements>
<design>{{design}}</design>
<code>{{code}}</code>
<test_results>{{test_output}}</test_results>

Respond in JSON:
{"passed": true|false,
 "failures": [{"test": "...", "expected": "...", "actual": "...", "file": "..."}]}
Fail the code if any requirement is unmet or any test fails.
```

## Stop rule

Stop when QA passes, or after 3 QA rounds. On the cap, return the latest code, the failing test report and every document, with a status of qa_failed.

## Requirements

- Keep the role order in configuration, not in prompts, so a role can be added or reordered without rewriting the others.
- Each role sees only the document types it subscribes to, never the whole pool, so its context stays small.
- Cap the QA rounds with a parameter (default 3).
- Log every published document with its type, author and token cost.
- Add a test with a stub LLM whose QA role fails once and then passes; assert the roles ran in the order PM, architect, engineer, QA, engineer, QA, and the pool holds 7 documents including the requirement.

Chat chain (ChatDev)

Implement the SOP-Driven Team pattern (Chat chain (ChatDev) variant) in this codebase, using the LLM client and language we already use.

## Goal

Run a fixed chain of phases in which each phase is a short dialogue between two role agents, an instructor and an assistant, whose agreed conclusion becomes the next phase's input.

## How it works

1. Write the chain down as an ordered list of phases, e.g. design, coding, review, test. For each phase, record the instructor role, the assistant role, the phase goal and the shape of its conclusion (a design note, code, a review).
2. For each phase, start a fresh two-agent dialogue: give the instructor the Phase instructor prompt and the assistant the Phase assistant prompt, each filled in with the phase goal and the previous phase's conclusion.
3. Alternate turns, where a turn is one instructor message plus one assistant reply: the instructor gives one instruction or review comment, and the assistant answers. When the assistant's reply begins with <SOLUTION>, take it as the phase's conclusion.
4. For coding phases, run the code after each assistant reply and give the instructor the compiler or test output with the next turn.
5. Pass only the conclusion, never the whole dialogue, to the next phase. After the last phase, return the final code with every phase's conclusion.

## Prompts

### Phase instructor prompt

```markdown
You are the {{instructor_role}} at a software company, working with the
{{assistant_role}} on this phase: {{phase_goal}}

<input_from_previous_phase>{{previous_conclusion}}</input_from_previous_phase>
{{#if run_output}}<latest_run_output>{{run_output}}</latest_run_output>{{/if}}

Give the {{assistant_role}} one specific instruction or review comment that
moves this phase forward. Do not do the work yourself.
```

### Phase assistant prompt

```markdown
You are the {{assistant_role}} at a software company, working with the
{{instructor_role}} on this phase: {{phase_goal}}

<input_from_previous_phase>{{previous_conclusion}}</input_from_previous_phase>

Carry out the instruction you were given. If you need a detail you do not
have, ask for it in one question before answering.
When you and the {{instructor_role}} have agreed on the result, begin your
reply with <SOLUTION> and give the complete {{conclusion_type}}.
```

## Stop rule

End a phase when the assistant replies with <SOLUTION>, after 10 turns, or when the code is unchanged for two turns in a row. End the chain after its last phase; if a phase hits its cap without a solution, carry its latest reply forward and mark that phase unresolved.

## Requirements

- Keep each phase's dialogue separate, so later phases see only the earlier conclusions and not the full chat.
- Cap every phase at a configurable number of turns (default 10).
- Run the code for real in the testing phase and feed the actual errors to the tester; do not let it guess at results.
- Log every phase with its two roles, its turn count and its conclusion.
- Add a test with a stub LLM in which every assistant returns different code on each turn and replies with <SOLUTION> on its second turn; assert that 4 phases ran, each took exactly 2 turns, and each phase received the previous phase's conclusion as its input.