Parallelization: Voting

Majority vote

Implement the Parallelization: Voting pattern in this codebase, using the LLM client and language we already use.

## Goal

Decide whether a code snippet is exploitable by asking several independent model calls and returning the majority verdict, or 'needs human review' when there is none.

## How it works

1. Send the snippet to N independent calls at once (default 3) with the Vulnerability audit prompt, sampled at a nonzero temperature; to vary the angle, swap some for the Alternate-perspective prompt with a different persona.
2. Give no call another's output; each one reasons on its own.
3. From each reply, read the last line and accept it only if it is exactly "VERDICT: vulnerable" or "VERDICT: safe". Any other reply is an abstention, not a vote.
4. Count the votes in plain code. If one verdict has more than half of all N calls, return it with the counts and every voter's reasoning.
5. Otherwise return "needs human review" with the counts and the reasoning, so a person sees the disagreement.

## Prompts

### Vulnerability audit prompt

```markdown
Decide whether the code below contains an exploitable
vulnerability. Reason step by step, then end with a final line
of exactly "VERDICT: vulnerable" or "VERDICT: safe".

<code>{{snippet}}</code>
```

### Alternate-perspective prompt

```markdown
You are a {{persona}} reviewing the code below for exploitable
vulnerabilities. Judge only what the code shows, not what it
might be used for. End with "VERDICT: vulnerable" or "VERDICT: safe".

<code>{{snippet}}</code>
```

## Stop rule

One round: N calls, one tally, done. No call is re-sampled to break a tie; a split goes to a person.

## Requirements

- Make N (default 3, odd) and the temperature (default 0.8) parameters.
- Count a majority against all N calls, abstentions included, so one valid vote among failures cannot win.
- If a call errors, retry it once, then count it as an abstention.
- Log every voter's reasoning and verdict next to the final tally, so a wrong majority can be studied.
- Add a test with a stub LLM that returns vulnerable, vulnerable, safe; assert the result is vulnerable with counts {vulnerable: 2, safe: 1}, and that vulnerable, safe plus one malformed reply gives needs human review.

LLM picks

Implement the Parallelization: Voting pattern (LLM picks variant) in this codebase, using the LLM client and language we already use.

## Goal

Produce a written security finding for a code snippet by sampling several independent findings and having an LLM select the one most consistent with the others.

## How it works

1. Send the snippet to N independent calls at once (default 5) with the Finding prompt, sampled at a nonzero temperature.
2. Number the replies 1 to N; drop any that are empty or errored after one retry.
3. Send all the numbered candidates to one more call with the Selection prompt, which picks the one most consistent with the majority.
4. Parse the selector's reply into a candidate number. If it is not a valid number in range, retry the selector once, then fall back to candidate 1 and mark the result unselected; every candidate is an independent sample, so the first is as good a default as any.
5. Return the chosen candidate verbatim, with its number and all the candidates for audit.

## Prompts

### Finding prompt

```markdown
You are a security reviewer. Write a one-paragraph finding for
the code below: what is exploitable, how an attacker would use
it, and the fix. If nothing is exploitable, say why.

<code>{{snippet}}</code>
```

### Selection prompt

```markdown
I have generated the following responses to the same question:

{{#each candidates}}
Response {{number}}: {{text}}
{{/each}}

Evaluate these responses and select the one most consistent
with the majority. Answer with only: "Response <number>".
```

## Stop rule

One round: N samples and one selection call (plus at most one retry). The selector picks; it never rewrites or merges.

## Requirements

- Make N (default 5) and the sampling temperature (default 0.8) parameters.
- Return the selected candidate exactly as sampled; the selector's reply is used only for its number.
- Put every candidate in the selection prompt in full; if they do not fit the context window, lower N rather than truncating them.
- Log the candidates, the selector's raw reply and the chosen number.
- Add a test with a stub LLM whose selector replies "Response 2"; assert the returned text equals the second sampled candidate exactly.

Model ensemble

Implement the Parallelization: Voting pattern (Model ensemble variant) in this codebase, using the LLM client and language we already use.

## Goal

Answer a question with several different models, rank their answers by pairwise comparison, and fuse the top-ranked ones into a single answer.

## How it works

1. Send the question to K different models at once (default 3), each configured separately, with the same prompt.
2. For every pair of answers, ask the ranker which is better with the Pairwise ranking prompt; run each pair twice with the order swapped, and count a win only when both orders agree.
3. Score each answer by its number of wins and keep the top 2, breaking ties by the earlier model in the list.
4. Send the question and the top answers, best first, to the fuser with the Fusion prompt, and return its reply.

## Prompts

### Pairwise ranking prompt

```markdown
Which answer to the question is better: more correct, more
complete and clearer?

<question>{{question}}</question>
<answer_a>{{a}}</answer_a>
<answer_b>{{b}}</answer_b>

Reply with exactly one letter: A or B.
```

### Fusion prompt

```markdown
Write the best possible answer to the question by combining
the strengths of these candidate answers, which are ranked best
first. Keep what is correct, drop what is wrong, and do not add
claims none of them support.

<question>{{question}}</question>
<candidates>{{ranked_answers}}</candidates>
```

## Stop rule

One round: K answers, K x (K - 1) ranking calls and one fusion call. Nothing loops back to the answering models.

## Requirements

- Make K (default 3) and the number of answers to fuse (default 2) parameters, and keep the model list as configuration.
- If one model errors or times out, rank the answers that did arrive; with only one answer, return it without fusing.
- If a ranking reply is neither "A" nor "B", retry it once, then count that comparison as a draw.
- Log every pairwise verdict and the final scores, so a model that keeps losing can be dropped.
- Add a test with stub models and a stub ranker that prefers B over A, B over C and A over C; assert the fuser prompt contains B's answer before A's and does not contain C's.