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.

pa_pvp mini produces findings, not instructions. Each finding is a candidate for action, not a mandate. The protocol is designed to surface structural problems and propose fixes — but it does not know your constraints, your timeline, or the downstream consequences of a change. Deciding which fixes to apply requires your own judgment about the artifact’s context, the cost of the change, and the confidence you have in the finding itself.
Do not apply every finding automatically. pa_pvp mini is a review aid, not an authority. A finding that passed one round of review is a strong signal, not a guarantee. A finding that appeared only once, carries LOW severity, or was later challenged by a second AI should be treated as a prompt for your own evaluation — not as a directive. Apply fixes deliberately, not mechanically.

​
When to apply a fix

Certain conditions increase confidence in a finding and make a fix worth applying with high priority:
  • Clear, observable evidence — the finding cites a specific element from the artifact and explains exactly why it breaks. Vague evidence is a sign the finding is weak.
  • Confirmation across multiple rounds — a finding that survives into Round 2 or Round 3 with a CONFIRMED label has been independently verified by a second pass. That confirmation is the strongest signal the protocol produces.
  • HIGH severity with structural consequence — a finding rated HIGH breaks core function, correctness, execution viability, or downstream trust. These are the highest-priority fixes regardless of round.
  • Fix changes structure, not just wording — a valid fix changes flow, constraints, decision rules, validation, or operational behavior. If the fix only changes how something is phrased, verify that the phrasing change carries structural weight before applying it.

​
When to defer or skip a fix

A LOW severity finding represents a real structural weakness, but one with a limited blast radius. The problem exists and the finding is valid — but it does not threaten the core function of the artifact. If you are doing a final hardening pass before deployment, LOW findings are worth addressing. If you are in early iteration and the artifact is still changing, defer them until the structure stabilizes. Fixing small weaknesses in a section that may be rewritten is wasted effort.
A fix that only changes phrasing is invalid under the protocol unless the wording change removes ambiguity that affects structure or behavior. If the finding says a sentence is unclear but the proposed fix does not change what the artifact does — how it flows, what it allows, what it requires — skip it. Wording clarity matters, but pa_pvp mini is not a style reviewer. If the wording creates genuine ambiguity about a constraint or decision rule, the fix is valid. If it is just a readability preference, it is not.
A CHALLENGED label means a second AI independently reviewed the artifact and disputed the prior finding. The challenge may be because the finding was invalid, overstated, not anchored to the artifact, or structurally irrelevant. A challenged finding is weak signal — it was found once and disputed once. Do not apply the fix until you have more signal. Run another round, or evaluate the original evidence yourself against the artifact. If the challenge reasoning is more specific and better anchored than the original finding, weight the challenge more heavily.
If a finding’s conflicts field in the MERGE STATUS block describes two incompatible positions — or if applying the fix would violate a constraint you know is non-negotiable — do not apply it without resolving the conflict yourself first. The protocol surfaces conflicts explicitly rather than silently resolving them, because the resolution requires context the reviewer does not have. Read both positions, understand why they conflict, and decide which is correct given your full knowledge of the artifact’s operating environment.

​
Using Merge Status

In Round 2 and later, every output includes a MERGE STATUS block summarizing how the current round’s independent review reconciles with prior findings. Each field carries a different level of confidence for action:
  • confirmed_fixes_ready — these fixes appeared in a prior round and held up under independent re-review. This is strong signal. Apply these with confidence unless a known constraint prevents it. The confirmation means two independent passes reached the same conclusion about the same problem in the same artifact.
  • challenged_items — prior findings or fixes that the current round disputes. Treat these as weak signal. Read the challenge reason before deciding anything. If the challenge reasoning is well-anchored to the artifact and more specific than the original finding, the challenge is likely correct. If the challenge is vague or relies on a different reading of the artifact, the original finding may still be valid.
  • new_fixes — fixes for problems found in the current round that did not appear in any prior round. These are first appearances and carry the same confidence level as Round 1 findings. Ideally, let them run one more round before applying, unless they are HIGH severity and the evidence is unambiguous.
  • conflicts — direct contradictions between the current independent review and a prior audit position. These are not resolved by the protocol and must be resolved by you. The conflict declaration tells you exactly what both positions are. Use your knowledge of the artifact’s context to decide which position is correct.

​
Structural fixes vs wording fixes

This distinction is load-bearing throughout the protocol. A fix is only valid — and only worth applying — if it changes at least one of the following:
  • Structure — the organization or composition of the artifact
  • Behavior — what the artifact causes to happen
  • Constraints — what the artifact allows, requires, or excludes
  • Decision rules — the conditional logic that determines outcomes
  • Flow — the sequence or order of operations
  • Validation — how correctness or completeness is checked
  • Operational clarity — whether the artifact can be executed without ambiguity
A fix that changes only how something is worded — without touching any of these — is excluded by the protocol. The one exception is a wording change that eliminates structural ambiguity: if the current phrasing creates genuine uncertainty about which branch of a decision rule applies, or which constraint takes precedence, correcting that phrasing is a structural fix. Use your judgment. If you cannot articulate how the wording change affects one of the properties above, it is not a structural fix.

Build docs developers (and LLMs) love

Get started for freeTalk to us