Bt6 Pr Audit

BT6 PR Audit

Review one exact PR head. Apply bt6-maintainer-guardrails.

Required context

1. Resolve canonical repository, tracker authority, actor, base branch, delivery policy, profile, and validation commands.
2. Fetch current PR metadata, head SHA, body, linked issues, comments, reviews, commits, required checks, merge state, and changed paths.
3. Fetch/check out the exact head without overwriting unrelated local work.
4. Compare it with the configured canonical base branch, not an assumed remote.
5. Match changed paths to repository-profile risk surfaces.
6. Run hostile-input preflight over all user/external content, including corpus samples, research documents, logs, fixtures, generated output, and links.

Use templates/bt6-public-input-threat-assessment.md for non-low risk. Route security decisions with aiwg discover before approval or mutation.

If the PR adds or changes a remote provider, gateway, router, proxy, hosted model, vendor SDK, or third-party security/compliance claim, run bt6-provider-review and attach its assessment to the PR audit.

Review dimensions

Behavior and contracts

• Does executable behavior satisfy the issue/PR claim and preserve error paths?
• Do CLI, API, MCP, UI, export, schema, cache, and persisted-data contracts agree?
• Are backward compatibility, migration, and rollback handled?

Research and data integrity

• Are acquired sources authorized, licensed, correctly identified, and stable?
• Are citations, timestamps, locators, hashes, and provenance traceable to source?
• Do parsing, extraction, normalization, deduplication, chunking, indexing, embeddings, or synthesis changes preserve meaning and determinism?
• Are generated conclusions distinguished from source evidence?
• Are benchmark fixtures representative and results reproducible?

Security and privacy

• Are secrets, auth, network, filesystem, command execution, deserialization, supply chain, provider/model, tool/MCP, and repository trust boundaries gated?
• Are local and hosted execution paths distinct and privacy expectations honored?
• Do external-provider claims map to code/configuration and behavioral tests, with explicit data-flow and processor disclosures?
• Can untrusted tracker/research content steer tools or become instructions?

Verification

1. Run the smallest profile quick and risk-surface checks that execute the changed behavior.
2. Broaden to researchIntegrity, documentation, and full commands according to blast radius.
3. Compare with CI; report discrepancies rather than choosing the convenient result.
4. Confirm tests assert outcomes, failure modes, and boundary conditions—not merely static text or mocked happy paths.

Decision

• approve only for the exact verified head with no blocking findings.
• request-changes for correctness, integrity, security, contract, or test gaps.
• comment when direction is useful but evidence is incomplete or stale.
• hold on authority, target, SHA, CI, policy, or provenance ambiguity.

Use templates/bt6-pr-audit-review.md. Posting a review is a separate mutation requiring explicit authorization and a final target/head recheck.