External Framework Review Prompt

# External Reviewer Prompt — Deep-Review Framework Critique

> Owner usage: paste this entire prompt into a fresh chat with an external model (Claude / GPT / Gemini / Kimi / etc.), then paste the framework document (`deep-review-framework.md`) immediately after. The external agent has no file or repository access — it works only from what you paste.

---

You are an external, independent reviewer. You have **no access to any files, source code, repositories, or systems** referenced in the document below. You can only critique what is pasted in this conversation. Treat the framework as the artifact under review; do not attempt to evaluate the modules it would later be applied to.

The owner wants an unbiased, candid critique. The framework's author and the supervisor who approved it may share blind spots — your fresh eyes are the entire point. Do not be deferential. If something is wrong, weak, ambiguous, or missing, say so plainly. If it is good, say that too, but do not pad.

## Background context (assume true; do not fact-check)

The framework is the seed of a multi-module security + code/design review program for a peer-federated software stack. Independent module-review agents will follow it to audit seven modules sequentially. The stack includes:

- A peer-federated social platform using the AT Protocol (handles, `did:plc`, `did:web`, `did:webvh`, PLC rotation keys, federation with Bluesky AppView, repo signing).
- A storage module supporting BYOC providers (Backblaze B2, Cloudflare R2, S3-compatible) with encryption-at-rest concerns.
- A payments module integrating Stripe live, Chia Offers / CATs / NFTs, and an in-app "test rail" token that must never be confused for real value.
- A LAN (local-area-network) deployment of these properties for member businesses, layered on top of the social platform as backend.
- Cross-property SSO (LAN ↔ social ↔ payments).
- A Docker Compose "core" template (Traefik, Authelia, Postgres / MySQL / MongoDB, Redis, MinIO, automated backups).
- An event-bus module (currently only one consumer; second consumer deferred).
- A docs-only "system" umbrella module (no runtime code).
- Reviews will be executed by Opus 4.7 max agents, **one module at a time, sequentially**, each on a fresh context window.
- Each module agent writes two artifacts (a context packet + a review) to **two locations** (canonical inside the project, mirror inside a global supervisor tree) and appends to a central findings ledger.

## Your task

Produce a structured critique of the framework. At minimum, cover:

1. **Completeness of risk coverage.** Are there attack surfaces or risk categories in a stack of this shape that the framework would miss? Name them concretely (file format, federation primitive, deployment-topology assumption, etc.).
2. **Domain accuracy.** Where the framework names specific technical risks (did:plc lifecycle, `alsoKnownAs`, audit-log freshness, Chia Offer construction, Stripe webhook signature handling, BYOC presigned URLs, etc.), are the claims accurate? Quote and correct any technical misstatements.
3. **Severity rubric realism.** Will the severity × likelihood scheme produce actionable classifications, or will it generate ambiguous middle-of-the-road outputs that the owner can't triage?
4. **Scope guard adequacy.** Are the hard limits (no production probing, no commits, no exploit dev, no code execution, redaction rules, etc.) tight enough? Any loopholes a careless or over-helpful agent could drift through?
5. **Output format effectiveness.** Will the per-finding structure (ID, title, severity, likelihood, category, location, evidence, realization path, remediation, related findings) actually produce findings that can be acted on, or will it produce boilerplate?
6. **Anti-generic-language guardrail (Section 16).** Is this guardrail well-targeted? Will it actually deter checklist-ese? Could it overcorrect — e.g., suppress useful caveats — and what would that look like?
7. **Atomicity and consistency contract.** The framework specifies dual-location byte-identical writes, append-only ledger, COMPLETE / INCOMPLETE semantics, and resumption rules. Are there race conditions, ambiguity, or hazards in the contract — especially around partial failure, multi-pass resumption, and ID re-use?
8. **Holistic synthesis (Phase D).** Given the holistic agent reads only per-module artifacts (with narrow spot-check rights into code), is its brief sound? Will it produce real cross-project insight, or just a summary?
9. **Bias and blind spots in the framework itself.** What does this framework betray as the author's mental model? What kind of finding is *most likely to be missed* by an agent strictly following it (e.g., a class of vulnerability not explicitly named, a category of design rot not mapped, an operational hazard outside the rubric)?
10. **Compounding-error risk.** If a module agent mechanically follows the framework without deep reasoning, what failure modes will the program have?

You may add other concerns the framework provokes — operational, ethical, legal, governance, supply chain, AI-specific.

## Output format

Use this structure exactly: