Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/pa-pvp-mini/llms.txt

Use this file to discover all available pages before exploring further.

Every pa_pvp mini output follows a fixed format. This reference documents the complete structure, every field, and the terminal marker. The format does not change based on which AI model is running the protocol, how many findings are present, or whether it is Round 1 or Round 2+. The only structural difference between rounds is the presence or absence of the MERGE STATUS block.

​
Full output structure

The complete output template, showing all sections and fields: 
ROUND:
- current_round: [number]
- round_mode: [ROUND 1 / ROUND 2+]

FINDINGS:
- [finding_id] [fix_id] [origin_round] [derived_from or NONE] [HIGH/MED/LOW] [INDEPENDENT/CONFIRMED/CHALLENGED/NEW]
- what_breaks: [one concise statement]
- evidence: [observable reason anchored to ORIGINAL_ARTIFACT]
- fix: [structural fix]

MERGE STATUS (ROUND 2+ ONLY):
- confirmed_fixes_ready: [fix_id] [one-line reason]
- challenged_items: [finding_id or fix_id] [why challenged] [replacement if any]
- new_fixes: [fix_id] [one-line reason]
- conflicts: [finding_id] [independent review position] [prior audit position]

END OF PROTOCOL
Each section is described in detail below.

​
ROUND header

The ROUND header appears at the top of every output without exception.
​
current_round
integer
required
The round number for this output. Always an integer. Set by CURRENT_ROUND if provided; otherwise inferred from the input blocks present. See Round Detection for the inference rules.
​
round_mode
string
required
Always exactly one of two values: ROUND 1 or ROUND 2+. This field reflects the execution path taken — it is not an abbreviation or a paraphrase.

​
FINDINGS block

The FINDINGS block contains one entry per valid finding, up to five total. Each finding occupies three lines: a header line and two sub-field lines.

​
Finding header line

The header line contains six positional fields in this exact order:
​
finding_id
keyword
required
A single keyword derived from the problem. No numbers, no category prefixes. Examples: padding, merge-conflict, sev-boundary. In Round 2+, if the same problem was tracked in PREVIOUS_ROUND_OUTPUT, the original ID must be reused exactly.
​
fix_id
keyword
required
A single keyword identifying the fix. Follows the same naming convention as finding_id. The fix ID is used in the MERGE STATUS block to refer to this fix by name.
​
origin_round
integer
required
The round in which this finding first appeared. For new findings in the current round, this matches current_round. For confirmed or evolved findings from prior rounds, this reflects the round where the finding originated.
​
derived_from
keyword or NONE
required
If this finding or fix replaces or evolves from a previous one, this field contains the ID of that prior item. If the finding is new and does not evolve from any prior item, this field contains exactly NONE.
​
severity
HIGH | MED | LOW
required
The severity level. See Severity Levels for definitions and examples.
​
label
INDEPENDENT | CONFIRMED | CHALLENGED | NEW
required
The finding’s relationship to prior rounds. INDEPENDENT is used in all Round 1 findings and for the independent review portion of Round 2+. CONFIRMED, CHALLENGED, and NEW are used only in Round 2+.

​
Finding sub-fields

​
what_breaks
string
required
One concise statement of the structural problem. This must name what specifically fails, not a general category of failure.
​
evidence
string
required
The observable reason for the finding, anchored to ORIGINAL_ARTIFACT. This must point to something visible in the artifact — a specific step, rule, constraint, or gap. Evidence that relies on inference, assumption, or external context is invalid.
​
fix
string
required
A structural fix that changes at least one of: structure, behavior, constraints, decision rules, flow, validation, or operational clarity. Pure wording changes are not valid fixes unless they resolve structural ambiguity.

​
MERGE STATUS block

The MERGE STATUS block appears only in Round 2+ outputs. It is absent from Round 1. It documents the outcome of the reviewer’s audit of PREVIOUS_ROUND_OUTPUT against the current independent review.
​
confirmed_fixes_ready
list
required
Fixes from prior material that held up under the current round’s independent review. Format: [fix_id] [one-line reason]. A fix is confirmed when the current independent review agrees that the problem is real and the fix is structurally valid.
​
challenged_items
list
required
Prior findings or fixes that the current round disputes. Format: [finding_id or fix_id] [why challenged] [replacement if any]. A challenge may be issued because a prior item is invalid, overstated, duplicated, weak, not anchored to the artifact, or not structurally relevant. If a replacement exists, it is included inline.
​
new_fixes
list
required
Fixes for structural problems found in the current round that were not present in the prior round. Format: [fix_id] [one-line reason]. These are problems the prior round missed.
​
conflicts
list
required
Direct contradictions between the current independent review and the prior audit position. Format: [finding_id] [independent review position] [prior audit position]. Conflicts must be declared explicitly rather than silently resolved. The output does not choose a winner — it surfaces the disagreement.

​
END OF PROTOCOL marker

Every pa_pvp mini output ends with the exact string: 
END OF PROTOCOL
This marker is always present, always on its own line, and always at the end of the output. Its presence signals that the output is complete. An output without this marker should be treated as truncated or incomplete.

​
Example: Round 1 output

ROUND:
- current_round: 1
- round_mode: ROUND 1

FINDINGS:
- enforcement fix-enforcement 1 NONE HIGH INDEPENDENT
- what_breaks: The constraint on maximum retries is stated but has no enforcement mechanism.
- evidence: ORIGINAL_ARTIFACT section 3 declares "no more than 3 retries" but no step checks or resets the retry count.
- fix: Add a validation step before the retry branch that reads the current count and blocks execution if it has reached 3.

- fallback fix-fallback 1 NONE MED INDEPENDENT
- what_breaks: The escalation path has no fallback when the escalation target is unavailable.
- evidence: ORIGINAL_ARTIFACT step 7 routes unresolved items to the team lead with no alternative defined for when the team lead role is vacant.
- fix: Define a secondary escalation target and add a condition: if primary target is unavailable, route to secondary target.

END OF PROTOCOL

​
Example: Round 2+ output

ROUND:
- current_round: 2
- round_mode: ROUND 2+

FINDINGS:
- enforcement fix-enforcement 1 NONE HIGH CONFIRMED
- what_breaks: The constraint on maximum retries is stated but has no enforcement mechanism.
- evidence: ORIGINAL_ARTIFACT section 3 declares "no more than 3 retries" but no step checks or resets the retry count.
- fix: Add a validation step before the retry branch that reads the current count and blocks execution if it has reached 3.

- fallback fix-fallback 1 NONE MED CHALLENGED
- what_breaks: The escalation path has no fallback when the escalation target is unavailable.
- evidence: ORIGINAL_ARTIFACT step 7 routes unresolved items to the team lead with no alternative defined for when the team lead role is vacant.
- fix: Define a secondary escalation target and add a condition: if primary target is unavailable, route to secondary target.

- timeout fix-timeout 2 NONE MED INDEPENDENT
- what_breaks: The retry loop has no timeout, allowing execution to stall indefinitely if the downstream service never responds.
- evidence: ORIGINAL_ARTIFACT step 5 initiates the call and step 6 checks the result, but no maximum wait time is defined between them.
- fix: Add a timeout value to step 5 and define what happens when the timeout expires before a response arrives.

MERGE STATUS (ROUND 2+ ONLY):
- confirmed_fixes_ready: fix-enforcement Current round independently confirmed: constraint with no enforcement is a real structural gap.
- challenged_items: fix-fallback Prior fix targets team lead vacancy only; the deeper issue is the absence of any escalation policy for all unavailability scenarios. Replacement: define an escalation policy that covers all cases where any named role is unavailable, not only the team lead.
- new_fixes: fix-timeout Prior round did not identify the missing timeout on step 5.
- conflicts: fallback Prior round framed this as a routing gap; current round identifies it as a missing escalation policy. Both are valid framings but the policy-level fix is structurally broader.

END OF PROTOCOL

Build docs developers (and LLMs) love

Get started for freeTalk to us