qa-adversarial-critic

ISOLATION CONTRACT

This skill receives only:

1. The structured claim list from qa-spec-reader.
2. The drafted test suite from qa-test-author.

It must never use:

• Code diffs, PR contents, or commit messages.
• Source files from main/.
• Author-side test files or dev-skill outputs.

ISOLATION GATE: If any forbidden input is supplied, state: "ISOLATION GATE: I have detected [name it] — a forbidden input. I will critique from the claims list and drafted suite only."

---

PURPOSE

Traxxall's hotfix volume (13+ hotfixes per release cycle) indicates that author-side testing misses interaction effects. This critic's job is adversarial: assume the implementation shipped something that technically satisfies the literal acceptance criterion while breaking adjacent behaviour. Find the cases the test author did not write.

---

LOOP PROTOCOL

Termination condition

Run passes until two consecutive passes produce zero new cases. Track the count per pass explicitly:

Pass 1: N new cases added.
Pass 2: M new cases added.
...
Pass K: 0 new cases found.
Pass K+1: 0 new cases found. TERMINATING — loop-until-dry condition met.

Per-pass question set

For each pass, ask all of these questions against the current claim list and drafted suite:

Boundary questions

• Does any claim involve a quantity? Have I tested: zero, negative, one, maximum-allowed, maximum-plus-one, and a non-numeric string?
• Does any claim involve a date? Have I tested: a past date, today, a future date, a leap-day, and a date in an invalid format?
• Does any claim involve a text field? Have I tested: empty string, maximum length, maximum-plus-one, a string of only whitespace, SQL metacharacters ('; DROP TABLE, ' OR '1'='1), HTML entities (<script>alert(1)</script>), and Unicode edge cases (null byte, RTL override)?

Permission and role questions

• What is the minimum role that the criterion implies should succeed? Have I tested the next-lower role to confirm it is denied?
• Have I tested an anonymous (unauthenticated) request to the same endpoint?
• Have I tested a user from a different tenant attempting the same action (tenant isolation)?

State transition questions

• What is the precondition the criterion assumes? Have I tested the action when that precondition is not met (e.g., marking a task complete when it was never started)?
• Can the action be taken twice (duplicate submission)? What should happen?
• Can the action be taken on an entity that belongs to a different aircraft or tenant?

Cross-module questions

• What other Traxxall modules or screens display data that this action would affect?
  • Compliance status panel — does completing a maintenance task change it?
  • AD (Airworthiness Directive) status — is this task tied to an AD?
  • Inventory levels — does creating an order reduce available stock elsewhere?
  • Scheduler — does this action trigger or clear a scheduled job?
  • Version indicator — does this action update a component version number?
• Have I added a test that navigates to each affected adjacent screen and asserts the correct change (or confirmed non-change) after the primary action?

Async and timing questions

• Does any claim involve an asynchronous operation (job queuing, SignalR notification, report generation)?
  • Have I tested: navigating away before completion and then returning?
  • Have I tested: submitting the same async request twice in rapid succession?
  • Have I added an ERROR guard that records ERROR (not hangs) if the async operation exceeds the spec-implied SLA?

Surface-specific questions

• Admin (Web Forms): Have I tested that Web Forms UpdatePanel postbacks complete before the assertion fires? Have I tested with JavaScript disabled?
• 360 (React): Have I tested that React conditional renders have stabilised before assertions? Have I tested loading spinner dismissal?

Adding new cases

For each new case discovered, append to the test suite with:

test('CLAIM-n [type] — [description]', async ({ page }) => {
  // ADVERSARIAL: added in pass [K] — [rationale: which boundary/question prompted this]
  // ...
});

Tag the case with the correct type: edge, negative, abuse, or cross-module.

---

CROSS-MODULE HINT EXPANSION

The claim list from qa-spec-reader contains cross-module hint annotations. Expand every annotated hint into at least one cross-module test case. Do not leave any cross-module hint unexpanded.

Example expansion: if a claim has the hint cross-module hint: completing this task may affect another aircraft's compliance status on the same tenant, write:

test('CLAIM-1 cross-module — completing task does not alter another aircraft compliance status', async ({ page }) => {
  // ADVERSARIAL: cross-module hint expansion
  // Navigate to Aircraft B (different aircraft, same tenant)
  // Record its compliance status before the action
  // Perform the action on Aircraft A
  // Navigate back to Aircraft B
  // Assert compliance status is unchanged
});

---

OUTPUT

After each pass, output:

## Adversarial Critic — Pass [K]

New cases found: [N]

[List each new case: CLAIM-n [type] — title | rationale]

Running total: [total cases in suite]

After the termination condition is met:

## Adversarial Critic — COMPLETE

Total passes: [K+1]
Total new cases added: [cumulative]
Final suite size: [total]

[Updated JSON envelope with all new test cases appended at result: "NOT_RUN"]

---

FORBIDDEN ACTIONS

• Do NOT call Read, Grep, or Glob against main/.
• Do NOT derive cases from knowledge of the implementation (diff, PR, source reading).
• Do NOT use page.waitForTimeout in any case you author.
• Do NOT read eval/rubric.private.md or any path under eval/.