Post Readiness Adversarial Audit

Post-Readiness Adversarial Audit

Mission

Do not trust IMPLEMENTATION_READY merely because the earlier workflow produced it.

This skill independently challenges the completed planning package before downstream implementation handoff.

It is a verification skill, not a design generator and not an implementation skill.

Canonical position:

design-to-implementation
→ IMPLEMENTATION_READY
→ POST-READINESS ADVERSARIAL AUDIT
→ audited handoff

1. Input Resolution — No Guessing

Resolve artifact paths in this order:

1. persisted workflow state / execution report
2. explicit workflow inputs
3. exact artifact paths recorded by prior stage gates

Do NOT guess a replacement filename or search for a "similar-looking" artifact when an expected path is missing.

If a required artifact path cannot be resolved:

POST_AUDIT_INPUT_NOT_RESOLVED

Record the exact missing artifact/path.

Required logical inputs:

• authoritative requirement
• current-state analysis
• verified gap analysis
• TDD
• TDD verification
• design artifact registry
• all implementation-required detailed designs
• all corresponding DD verification reports
• WBS
• WBS verification
• test design
• implementation-readiness report
• persisted workflow state/execution report when available
• current repository source

Current source remains authoritative for CURRENT behavior.

2. Workflow / Gate Integrity Audit

Verify the completed run actually passed the required lifecycle rather than merely producing files.

Create:

At minimum cover:

• TDD verification
• design artifact decomposition
• every implementation-required DD verification
• WBS generation
• WBS verification
• implementation readiness

Rules:

• file existence alone does not prove stage success
• prose saying "ready" does not replace structured gate evidence
• missing/malformed gate is a finding
• registry status must agree with DD verification artifacts
• WBS/readiness claims must agree with upstream statuses

3. WBS Semantic Consistency + Deterministic Deep Trace

3A. Exhaustive WBS ↔ Artifact Semantic Identity

Before sampling anything, inspect every WBS task.

For each WBS task derive its primary implementation deliverable and verify:

WBS task title / objective / primary deliverable
↔ referenced Artifact ID
↔ canonical registry artifact name + responsibility
↔ VERIFIED DD owned implementation unit
↔ TDD decision

Create:

Hard failure code:

WBS_ARTIFACT_SEMANTIC_MISMATCH

Use it when a task's primary deliverable does not belong to the referenced artifact according to the registry / VERIFIED DD.

Important:

• Artifact ID existence is not semantic proof.
• A symbol merely appearing in TDD/DD is not ownership proof.
• @see, dependency, import, mention, cross-reference, or neighboring design prose does not allow re-labeling an artifact.
• The same Artifact ID MUST use the same canonical artifact name/responsibility throughout the report.
• If section A says ART-001 = AuditLogger Interface, another section may not treat ART-001 = AuditException unless the registry/DD explicitly defines that ownership.

Required threshold:

WBS semantic identity consistency = 100% of ALL WBS tasks

Any HIGH/CRITICAL semantic mismatch forces:

POST_READINESS_AUDIT_FAIL_WBS_GAPS

3B. Deterministic Deep Backward-Trace Sample

Do not ask the human to manually choose WBS IDs.

Select up to three WBS tasks deterministically from the actual WBS:

1. lowest-ID code-changing task
2. highest-ID code-changing task
3. code-changing task with the highest dependency count
   • tie-breaker: lowest WBS ID
   • if duplicate of #1/#2, choose the next highest dependency-count distinct task

If the WBS does not expose a usable code-changing classification, use all tasks when task count <= 10; otherwise choose lowest ID, highest ID, and highest dependency-count task.

For each selected task trace:

WBS task
→ VERIFIED Detailed Design
→ Design Artifact registry entry
→ TDD decision
→ Verified Gap
→ Requirement rule
→ CURRENT source anchor (when CURRENT source exists)

For PROPOSED_NEW components, verify the proposed location/ownership against the approved design; do not call a non-existent current source path "source verified".

Create:

A generated artifact is navigation evidence, not proof of CURRENT source.

3C. Sampling Claim Discipline

The deep backward trace above is a sample unless every WBS task was selected.

Therefore:

• 3/3 sampled WBS tasks passed is valid when three were sampled.
• all WBS tasks trace back correctly is forbidden unless all WBS tasks were exhaustively traced.
• Universal claims may only come from exhaustive checks, such as the all-task semantic identity audit in §3A.

If the report makes an unsupported universal claim from sampled evidence, record:

AUDIT_CLAIM_EXCEEDS_EVIDENCE

and fail workflow integrity.

4. Proposed Static Architecture Consistency Audit

From the TDD PROPOSED Static Architecture and Component Responsibilities:

For every major PROPOSED_NEW or materially MODIFIED component/type:

TDD static architecture
↔ component responsibilities
↔ design artifact registry
↔ detailed design
↔ WBS task(s)
↔ verification/test obligations

For every EXISTING component named as an existing source anchor:

• verify it exists
• verify the claimed current role/relationship where implementation depends on it

Create:

No major proposed component may exist only in a diagram.

5. Requirement / Negative-Rule Audit

Enumerate every explicit MUST-NOT / exclusion / preserved-behavior rule from the authoritative requirement and verified gap analysis.

For each one prove:

requirement exclusion
→ TDD preservation mechanism
→ relevant DD
→ WBS impact/non-impact
→ test/verification coverage

Create:

Required target:

negative-rule coverage = 100%

Any material exclusion without design/test coverage blocks PASS.

6. Boundary → Exposure Re-Audit

Identify every integration/boundary artifact that the verified TDD says is materially changed.

For each affected boundary:

boundary
← ALL direct invocation/construction sites
← ALL material caller chains
← ALL external entry points / proven internal roots

Compare the re-audit result with:

• current-state analysis
• TDD
• artifact registry
• DD
• WBS
• tests

Create:

Do not sample one representative endpoint when the boundary has multiple callers.

7. WBS Missing-Work Recheck

Independently challenge the earlier WBS verification.

From verified DD/source impacts search where applicable:

• callers/references
• implementations
• constructors/factories/DI
• serializers/mappers
• configuration consumers
• persistence/migration
• tests/fixtures
• integration adapters
• sibling operations that must preserve behavior
• documentation/config samples required by the approved design

Do not add speculative work.

Create:

8. Source-Anchor Health

For all source anchors used by the sampled WBS traces plus every major architecture/boundary decision:

• verify exact symbol/path exists
• verify claimed current role
• verify source has not drifted from the generated artifact's assumption

Record:

VERIFIED
CONTRADICTED
SOURCE_NOT_RESOLVED

8A. Cross-Section Canonical Identity Consistency

Build a canonical identity dictionary from the design artifact registry:

Artifact ID → canonical artifact name → responsibility → VERIFIED DD

Then scan every audit section/table that mentions an Artifact ID.

Create:

Rules:

• one Artifact ID cannot silently change meaning between sections
• a WBS task label does not redefine the artifact
• TDD mentions do not redefine registry ownership
• any semantic contradiction that affects a HIGH/CRITICAL implementation task blocks PASS

Failure code:

CROSS_SECTION_ARTIFACT_IDENTITY_CONTRADICTION

9. Quantitative Audit Scorecard

Report measurable results:

Do not replace failed thresholds with subjective Green/Yellow/Red.

10. Verdict

Use exactly one:

• POST_READINESS_AUDIT_PASS
• POST_READINESS_AUDIT_PASS_WITH_WARNINGS
• POST_READINESS_AUDIT_FAIL_SOURCE_GAPS
• POST_READINESS_AUDIT_FAIL_DESIGN_GAPS
• POST_READINESS_AUDIT_FAIL_WBS_GAPS
• POST_READINESS_AUDIT_FAIL_WORKFLOW_INTEGRITY
• POST_AUDIT_INPUT_NOT_RESOLVED

PASS

Requires all mandatory scorecard thresholds to pass.

Additionally:

• WBS_ARTIFACT_SEMANTIC_MISMATCH count must be 0
• CROSS_SECTION_ARTIFACT_IDENTITY_CONTRADICTION count must be 0 for HIGH/CRITICAL implementation work
• AUDIT_CLAIM_EXCEEDS_EVIDENCE count must be 0
• sampled evidence must never be presented as exhaustive evidence

PASS_WITH_WARNINGS

Allowed only when:

• all mandatory thresholds pass
• no HIGH/CRITICAL finding remains
• warnings are non-blocking and explicitly listed

FAIL

Choose the failure class corresponding to the first material blocking layer. Do not call PASS because the package "looks complete".

11. Mutation Rule

This audit MUST NOT silently edit:

• TDD
• registry
• DD
• WBS
• test design
• readiness report

It reports findings only.

Corrections happen in the owning upstream workflow, then the audit is rerun.

Output

Use the active workflow-declared post-readiness audit output path. Do not reuse legacy audit artifacts.