@zigrivers/scaffold 2.1.0

package/knowledge/review/review-prd.md

@@ -0,0 +1,235 @@
+---
+name: review-prd
+description: Failure modes and review passes specific to product requirements document artifacts
+topics: [review, prd, requirements, completeness, clarity, nfr, constraints]
+---
+
+# Review: Product Requirements Document
+
+The PRD is the foundation of the entire pipeline. Every subsequent phase builds on it — user stories, domain models, architecture, implementation tasks. A gap or error here compounds through everything downstream. This review uses 8 passes targeting the specific ways PRD artifacts fail.
+
+Follows the review process defined in `review-methodology.md`.
+
+---
+
+## Pass 1: Problem Statement Rigor
+
+### What to Check
+
+- Is the problem specific, testable, grounded in observable reality?
+- Has quantitative evidence where available?
+- Doesn't prescribe solutions?
+- Names a specific user group, not "users" or "everyone"?
+
+### Why This Matters
+
+The problem statement anchors every decision in the pipeline. If it prescribes a solution instead of describing a pain point, the entire product is built to validate a predetermined answer rather than solve a real problem. Vague problem statements produce vague requirements, which produce vague stories, which produce implementations that technically work but don't solve anything. A problem statement that names "users" instead of a specific group gives no signal about whose needs to prioritize when trade-offs arise.
+
+### How to Check
+
+1. Read the problem statement in isolation — does it describe an observable user pain point?
+2. Check for solution language ("we need to build," "we should use," "modernize our stack") — these prescribe solutions, not problems
+3. Check for a named, specific user group — not "users," "everyone," or "stakeholders"
+4. Look for quantitative evidence (hours wasted, error rates, revenue lost, support tickets) — if none exists, flag it
+5. Verify the problem is testable — could you measure whether it's been solved?
+
+### What a Finding Looks Like
+
+- P0: "Problem statement is 'We need to modernize our technology stack' — this prescribes a solution, not a problem. No user-facing pain point identified."
+- P1: "Problem statement names 'small business owners' but provides no quantitative evidence of the pain. How many hours wasted? What error rate?"
+
+---
+
+## Pass 2: Persona & Stakeholder Coverage
+
+### What to Check
+
+- Are personas goal-driven with constraints, current behavior, and success criteria?
+- Every stakeholder group represented (end users, admins, support, integrators)?
+- No "Everything User" anti-pattern (contradictory persona)?
+- 2-4 meaningful personas (>6 suggests scope too broad, 1 suggests missing secondary users)?
+
+### Why This Matters
+
+Personas become story actors. If a persona is just a role label ("Admin") with no goals, constraints, or context, stories attributed to that persona are ungrounded — the agent writing them has to invent motivations. Missing stakeholder groups mean entire user journeys have no stories. The "Everything User" anti-pattern (a single persona who is both a power user and a beginner, both technical and non-technical) makes prioritization impossible because every feature is equally important to the same persona.
+
+### How to Check
+
+1. List every persona defined in the PRD
+2. For each persona, check for: specific goals, constraints, current behavior, and success criteria
+3. Count personas — fewer than 2 usually means secondary users are missing; more than 6 usually means scope is too broad
+4. Check for contradictions within a single persona (wants simplicity AND power-user features)
+5. List stakeholder groups that interact with the system (end users, admins, support, integrators, billing) and verify each has a persona or is explicitly out of scope
+6. Check that persona descriptions include enough context to write stories — not just "Admin: manages the system"
+
+### What a Finding Looks Like
+
+- P0: "PRD defines a single persona 'User' with no goals, constraints, or context. Cannot write stories — no actor to attribute them to."
+- P1: "PRD describes end user and admin but no mention of support staff, who handle 200+ tickets/week per the problem statement."
+
+---
+
+## Pass 3: Feature Scoping Completeness
+
+### What to Check
+
+- In-scope, out-of-scope, and deferred lists all present?
+- Features specific enough to estimate (not "user management" or "analytics")?
+- Prioritization applied (MoSCoW or equivalent)?
+- No "requirements as solutions" (PRD says WHAT, not HOW)?
+
+### Why This Matters
+
+Missing scope boundaries cause the most expensive downstream failures. Without an out-of-scope list, implementing agents may build features the product team never intended. Without a deferred list, features that should wait for v2 get built into v1, expanding scope and timeline. Vague feature descriptions ("user management") are impossible to decompose into stories — two different agents would build completely different things. Technical prescriptions ("use React and PostgreSQL") in the PRD constrain architecture before the architecture phase has run.
+
+### How to Check
+
+1. Verify three lists exist: in-scope, out-of-scope, and deferred
+2. For each in-scope feature, check specificity — could two different people reading this description agree on what to build?
+3. Check for prioritization (MoSCoW, P0-P3, or equivalent) — if all features are "must-have," prioritization hasn't happened
+4. Scan for technical prescriptions — the PRD should say WHAT the product does, not HOW it's built
+5. Check that feature descriptions describe user-facing behavior, not implementation details
+
+### What a Finding Looks Like
+
+- P0: "No out-of-scope section exists. 'Product management' is listed as a feature with no further detail — could mean anything from a product catalog to a full PIM system."
+- P1: "Feature 'notifications' doesn't specify channel (push? email? in-app? all three?) — two engineers would build different things."
+
+---
+
+## Pass 4: Success Criteria Measurability
+
+### What to Check
+
+- Every criterion has a target value AND a measurement method?
+- Criteria tied to the problem statement (not generic "revenue increases")?
+- Types covered: user behavior, business metrics, technical metrics, adoption?
+
+### Why This Matters
+
+Success criteria that can't be measured can't be verified. "Users are satisfied" is not a success criterion — it's a hope. Without target values, any movement in the right direction technically satisfies the criterion. Without measurement methods, the team can't verify success even if they achieve it. Criteria disconnected from the problem statement indicate the PRD has drifted from its original purpose.
+
+### How to Check
+
+1. List every success criterion in the PRD
+2. For each, check for a specific target value (a number, a percentage, a threshold)
+3. For each, check for a measurement method (how will this be measured? what tool or process?)
+4. Trace each criterion back to the problem statement — does it measure whether the problem is solved?
+5. Check coverage across types: user behavior metrics, business metrics, technical metrics, adoption metrics — if only one type is present, the others are likely missing
+6. Flag criteria that are generic ("increase user satisfaction") rather than specific ("reduce checkout abandonment from 72% to 45%")
+
+### What a Finding Looks Like
+
+- P0: "Only success criterion is 'users are satisfied with the product' — no target value, no measurement method, not tied to problem statement."
+- P1: "Success criterion 'checkout abandonment decreases' has no target value. Decrease from 72% to 71% would technically satisfy it."
+
+---
+
+## Pass 5: NFR Quantification
+
+### What to Check
+
+- All NFR categories addressed: performance, scalability, availability, security, accessibility, data retention, i18n, browser/device support, monitoring?
+- Quantified with numbers, not adjectives ("p95 under 200ms" not "fast")?
+- Conditions specified (under what load, on what connection)?
+
+### Why This Matters
+
+Missing or vague NFRs force implementing agents to make arbitrary decisions about performance, security, and reliability. "The system should be fast" means something different to every engineer. Without quantified targets and conditions, the architecture phase has no constraints to design against, and the testing phase has no thresholds to verify. NFR gaps discovered during implementation are orders of magnitude more expensive to fix than NFR gaps caught during PRD review.
+
+### How to Check
+
+1. Check each NFR category: performance, scalability, availability, security, accessibility, data retention, i18n, browser/device support, monitoring
+2. For each category present, verify quantification — numbers, not adjectives
+3. For performance NFRs, check for conditions: under what load? on what hardware? at what percentile?
+4. For availability NFRs, check for specifics: what's the target uptime? what's the maximum acceptable downtime window?
+5. For security NFRs, check for compliance standards (SOC 2, GDPR, PCI DSS) where applicable
+6. Flag any NFR category that's completely absent
+
+### What a Finding Looks Like
+
+- P0: "No NFRs specified at all. Implementing agents will make arbitrary performance and security decisions."
+- P1: "Performance requirement says 'the system should be fast' — no response time targets, no percentile, no load conditions."
+
+---
+
+## Pass 6: Constraint & Dependency Documentation
+
+### What to Check
+
+- Technical, timeline, budget, team, and regulatory constraints present?
+- Each constraint traceable to downstream architectural impact?
+- External integrations identified with API limitations, costs, rate limits?
+
+### Why This Matters
+
+Undocumented constraints surface as surprises during implementation. A Stripe integration without PCI DSS compliance noted will derail the architecture phase. A team constraint of 3 developers without connection to scope decisions means the plan may be unachievable. Regulatory constraints discovered late can require fundamental redesigns. Every constraint should be visible to downstream phases so they can design around it rather than into it.
+
+### How to Check
+
+1. Check each constraint category: technical, timeline, budget, team size/skills, regulatory/compliance
+2. For each constraint, trace the downstream impact — how does this affect architecture, implementation, or testing?
+3. List all external integrations mentioned in the PRD
+4. For each integration, check for: API limitations, costs, rate limits, authentication requirements, compliance requirements
+5. Flag constraints that are stated but not connected to decisions — "we have 3 developers" without scope implications
+
+### What a Finding Looks Like
+
+- P1: "PRD mentions Stripe integration but doesn't note PCI DSS compliance requirement — this will surface as a surprise during architecture."
+- P2: "Team constraint '3 developers' is stated but not connected to scope decisions — are all features achievable with this team size?"
+
+---
+
+## Pass 7: Error & Edge Case Coverage
+
+### What to Check
+
+- Sad paths addressed for every feature with user input or external dependencies?
+- Session expiry, network failure, concurrent access scenarios considered?
+- Failure modes for third-party integrations documented?
+
+### Why This Matters
+
+Happy-path-only PRDs produce happy-path-only implementations. When the PRD doesn't describe what happens when a payment fails, the implementing agent either guesses (producing inconsistent error handling) or ignores it (producing a broken user experience). Edge cases in user input, network conditions, and third-party integrations are where most production bugs live. Documenting them in the PRD ensures they flow into stories, acceptance criteria, and test cases.
+
+### How to Check
+
+1. For each feature involving user input, check: what happens with invalid input? empty input? malicious input?
+2. For each feature involving external dependencies, check: what happens when the dependency is unavailable? slow? returns unexpected data?
+3. Check for session-related scenarios: session expiry mid-action, concurrent access from multiple devices, browser back button during multi-step flows
+4. Check for data-related edge cases: duplicate submissions, race conditions, large data volumes
+5. For each third-party integration, check: failure modes documented? retry logic specified? fallback behavior defined?
+
+### What a Finding Looks Like
+
+- P1: "Checkout flow describes the happy path but never addresses: payment failure, session expiry mid-checkout, network drop during payment processing."
+- P2: "User profile edit doesn't address concurrent edit scenario — what if user edits on two devices simultaneously?"
+
+---
+
+## Pass 8: Downstream Readiness for User Stories
+
+### What to Check
+
+- Can stories be written from this PRD without guesswork?
+- Features specific enough to map to stories (one feature = one or more stories)?
+- Personas specific enough to be story actors?
+- Business rules explicit enough to become acceptance criteria?
+- Error scenarios detailed enough to become negative test scenarios?
+
+### Why This Matters
+
+The PRD's primary consumer is the user stories phase. If features are too vague to decompose into stories, the story-writing agent must invent requirements — and its inventions may not match the product team's intent. Personas that are just role labels can't be story actors. Business rules that are implied but not stated produce acceptance criteria that are guesses rather than specifications. This pass is the final gate before the PRD leaves the pre-pipeline and enters the main pipeline.
+
+### How to Check
+
+1. Select 3-5 representative features from different areas of the PRD
+2. For each, attempt to write a story title ("As a [persona], I want to [action] so that [benefit]") — if you can't fill in the blanks, the feature or persona is too vague
+3. For each, attempt to write 2-3 acceptance criteria from the PRD description alone — if you have to guess at business rules, they're not explicit enough
+4. Check that error scenarios in the PRD are detailed enough to become "Given [error condition], When [user action], Then [expected behavior]" acceptance criteria
+5. Verify that the mapping from features to stories would be roughly 1:N (one feature produces one or more stories) — if a feature maps to zero stories, it's too vague; if it maps to 20+, it should have been decomposed in the PRD
+
+### What a Finding Looks Like
+
+- P0: "Feature 'user management' cannot be decomposed into stories — what operations? What user types? What permissions model?"
+- P1: "Business rules for discount application are implied but not stated — story acceptance criteria will have to guess at validation logic."

package/knowledge/review/review-security.md

@@ -0,0 +1,213 @@
+---
+name: review-security
+description: Failure modes and review passes specific to security review and documentation artifacts
+topics: [review, security, owasp, auth, threat-modeling]
+---
+
+# Review: Security
+
+The security review document assesses the system's security posture across authentication, authorization, data protection, and vulnerability management. It must address the OWASP top 10 for the project's technology stack, align security boundaries with API contracts and architecture, and ensure secrets management and dependency auditing are actionable. This review uses 7 passes targeting the specific ways security reviewation fails.
+
+Follows the review process defined in `review-methodology.md`.
+
+---
+
+## Pass 1: OWASP Coverage
+
+### What to Check
+
+Each OWASP Top 10 category is addressed for this specific project. The assessment is project-specific (not generic), identifying which categories are relevant, what the project's exposure is, and what mitigations are in place or planned.
+
+### Why This Matters
+
+The OWASP Top 10 represents the most common and impactful web application security risks. Skipping a category does not mean the risk does not exist — it means the risk is unassessed. Generic OWASP checklists that say "use parameterized queries" without connecting to the project's actual database layer provide false security confidence.
+
+### How to Check
+
+1. Verify all 10 OWASP categories are addressed (Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Identity/Auth Failures, Data Integrity Failures, Logging Failures, SSRF)
+2. For each category, check that the assessment is project-specific: which components are affected? What is the attack surface?
+3. Verify that mitigations reference specific architecture components, not generic advice ("use an ORM" vs. "the OrderRepository uses Prisma with parameterized queries by default")
+4. Check for categories marked "not applicable" — is the rationale valid? (SSRF is not applicable only if the system never fetches external URLs)
+5. Verify that mitigations for high-risk categories (Broken Access Control, Injection) are detailed and actionable
+6. Check for OWASP categories beyond the Top 10 if the project has specific risk profiles (API security, mobile security, serverless security)
+
+### What a Finding Looks Like
+
+- P0: "Injection category says 'mitigated by using an ORM' but the system also has raw SQL queries in the reporting module. The mitigation is incomplete."
+- P0: "Broken Access Control category is marked 'mitigated' but the API contracts show several endpoints with no authorization specification (see API review Pass 3). The mitigation claim is unverified."
+- P1: "Cryptographic Failures category says 'use HTTPS' but does not address data encryption at rest, password hashing algorithm, or token generation security."
+- P2: "Security Misconfiguration category provides generic advice. Should reference the project's specific infrastructure (Docker, Kubernetes, cloud provider) and their configuration risks."
+
+---
+
+## Pass 2: Auth/AuthZ Boundary Alignment
+
+### What to Check
+
+Security boundaries (who can access what) align with the API contract's authentication and authorization requirements and the architecture's component boundaries. No access control gaps exist between what the security review specifies and what the API contract enforces.
+
+### Why This Matters
+
+Security boundaries that do not match API contracts mean either the API has endpoints with weaker access control than the security review intends, or the security review assumes protections that the API does not implement. Either way, the gap creates a vulnerability. This pass cross-references the security review with the API contract — it is a consistency check between two artifacts.
+
+### How to Check
+
+1. List every security boundary defined in the security review (user roles, permission levels, resource ownership rules, service-to-service trust)
+2. For each API endpoint, verify its auth/authz requirement aligns with the security review's boundary definition
+3. Check for endpoints that the security review does not cover — are they intentionally public or accidentally unprotected?
+4. Verify that resource-level authorization (user A cannot access user B's data) is specified in both documents consistently
+5. Check that service-to-service authentication matches: does the security review and the architecture agree on how services authenticate to each other?
+6. Verify that admin/elevated-privilege endpoints have additional protections specified in both documents
+
+### What a Finding Looks Like
+
+- P0: "Security document defines role-based access with 'admin' and 'user' roles, but API contract endpoint DELETE /users/{id} has no authorization specification. Can a 'user' role delete other users?"
+- P1: "Security document specifies 'users can only access their own orders' but API contract GET /orders does not mention user-scoping. The endpoint may return all orders regardless of the requesting user."
+- P1: "Service-to-service communication is marked as 'internal, trusted' in the security review but the architecture shows services communicating over the public internet without mTLS."
+- P2: "Security document and API contract both specify auth requirements, but they use different terminology ('role: admin' vs. 'permission: manage_users'). Align the language."
+
+---
+
+## Pass 3: Secrets Management
+
+### What to Check
+
+No secrets are stored in code, version control, or plain-text configuration. A rotation strategy exists. Vault or secrets manager integration is specified.
+
+### Why This Matters
+
+Secrets in code or version control are the most common source of security breaches. A single API key committed to a public repository can compromise an entire production system within hours (automated scanners harvest secrets from public repos). Secrets management is not optional — it is a prerequisite for any production system.
+
+### How to Check
+
+1. Verify that the security review explicitly states: no secrets in code or version control
+2. Check for a secrets management approach: environment variables, vault (HashiCorp Vault, AWS Secrets Manager, etc.), encrypted configuration
+3. Verify that secrets rotation strategy is documented: how often are secrets rotated? What is the process?
+4. Check for secrets categories: API keys, database credentials, JWT signing keys, encryption keys, service account tokens — is each category addressed?
+5. Verify that local development secrets handling is specified: do developers use a .env file? Is it gitignored? Is there a secrets template?
+6. Check for emergency rotation: what happens when a secret is suspected compromised? What is the process?
+7. Verify that CI/CD secrets are addressed: how does the deployment pipeline access production secrets?
+
+### What a Finding Looks Like
+
+- P0: "No secrets management strategy exists. The security review does not address how secrets are stored, accessed, or rotated."
+- P0: "Security document says 'secrets in environment variables' but does not specify how environment variables are populated in production. If they are in a plain-text config file on the server, that is not secrets management."
+- P1: "Secrets rotation is mentioned as 'periodic' without specifying the rotation period or process. When the JWT signing key is rotated, what happens to existing tokens?"
+- P2: "Local development uses a .env file but no .env.example template exists for new developers. They may create secrets with insecure defaults."
+
+---
+
+## Pass 4: Dependency Audit Coverage
+
+### What to Check
+
+Known vulnerability scanning is integrated into the CI pipeline. The dependency audit strategy covers direct and transitive dependencies. A policy exists for responding to discovered vulnerabilities.
+
+### Why This Matters
+
+Third-party dependencies are a major attack surface. A single vulnerable dependency (Log4Shell, for example) can compromise the entire system. Dependency auditing must be continuous (not one-time) and integrated into CI (not a manual process), because new vulnerabilities are discovered daily and dependencies change with every build.
+
+### How to Check
+
+1. Verify a dependency scanning tool is specified (npm audit, Snyk, Dependabot, Trivy, etc.)
+2. Check that scanning runs automatically in CI — not just available locally
+3. Verify that the scanning covers transitive dependencies (not just direct dependencies)
+4. Check for a vulnerability response policy: severity thresholds (block on critical/high, warn on medium), response time expectations (critical: 24h, high: 1 week), exception process
+5. Verify that container image scanning is included if the project uses containers
+6. Check for license compliance scanning if relevant (some licenses are incompatible with commercial use)
+7. Verify that the dependency audit covers all package ecosystems in the project (npm, pip, go modules, etc.)
+
+### What a Finding Looks Like
+
+- P0: "No dependency scanning tool or process is specified. The project has 500+ npm dependencies and no way to detect known vulnerabilities."
+- P1: "Dependency scanning runs locally with 'npm audit' but is not integrated into CI. Vulnerabilities discovered locally may not block deployments."
+- P1: "Scanning covers npm dependencies but the project also has Python dependencies (for data processing) that are not scanned."
+- P2: "Vulnerability response policy does not specify exception process. What if a critical vulnerability has no fix available? Is there a documented workaround/mitigation path?"
+
+---
+
+## Pass 5: Threat Model Scenarios
+
+### What to Check
+
+Threats are identified for all trust boundaries in the system. The threat model uses a structured approach (STRIDE, PASTA, or similar) and covers realistic attack scenarios specific to this project.
+
+### Why This Matters
+
+A threat model that says "attackers may try to compromise the system" is not a threat model — it is a statement of the obvious. Useful threat models identify specific trust boundaries (user-to-API, service-to-service, service-to-database), enumerate realistic threats at each boundary, and map them to mitigations. Without specific threat scenarios, security investments are based on intuition rather than risk analysis.
+
+### How to Check
+
+1. Verify a threat modeling methodology is stated (STRIDE, PASTA, attack trees, or custom)
+2. List all trust boundaries from the architecture: client-to-server, service-to-service, service-to-database, service-to-external-API
+3. For each trust boundary, verify threats are enumerated
+4. Check that threats are specific: "SQL injection via the search parameter on GET /products" not "injection attacks"
+5. Verify that each threat has a likelihood and impact assessment
+6. Check that mitigations are mapped to threats: which mitigation addresses which threat?
+7. Verify that residual risk is documented: threats with no mitigation or partial mitigation
+8. Check for insider threat scenarios: what if a developer, admin, or service account is compromised?
+
+### What a Finding Looks Like
+
+- P0: "No threat model exists. The security review discusses mitigations but has not identified what threats those mitigations are defending against."
+- P1: "Threat model covers client-to-server boundary but ignores service-to-service trust boundaries. Internal services communicate without authentication — an attacker who compromises one service has unrestricted access to all others."
+- P1: "Threat model identifies threats but does not map them to mitigations. It is unclear whether identified threats are mitigated, partially mitigated, or accepted risks."
+- P2: "Insider threat is not addressed. What happens if a developer's machine is compromised and their credentials are stolen?"
+
+---
+
+## Pass 6: Data Classification
+
+### What to Check
+
+Data is categorized by sensitivity level. Handling requirements are specified for each category. Data flows map to classification levels.
+
+### Why This Matters
+
+Not all data requires the same protection. Treating all data identically either under-protects sensitive data (PII, financial, health) or over-protects public data (wasting resources on encryption, access control, and audit logging for non-sensitive data). Data classification drives proportional security investment and ensures regulatory compliance (GDPR, HIPAA, PCI-DSS).
+
+### How to Check
+
+1. Verify that data classification levels are defined (e.g., public, internal, confidential, restricted)
+2. For each classification level, check that handling requirements are specified: encryption at rest, encryption in transit, access control, audit logging, retention, disposal
+3. Map domain entities to classification levels: which entities contain PII? Financial data? Health data?
+4. Verify that data flows respect classification: restricted data does not flow through unprotected channels
+5. Check for regulatory requirements: if the project handles PII (GDPR), payment data (PCI-DSS), or health data (HIPAA), are compliance requirements addressed?
+6. Verify that data classification covers derived data: aggregated analytics, logs that contain PII, backups that contain classified data
+7. Check for data residency requirements if the project operates across jurisdictions
+
+### What a Finding Looks Like
+
+- P0: "No data classification exists. The system handles user email addresses, passwords, and payment information with no documented sensitivity levels or handling requirements."
+- P1: "Data is classified but handling requirements are missing. User email is marked 'confidential' but no encryption-at-rest requirement is specified."
+- P1: "Application logs contain user email addresses and IP addresses (PII) but logs are classified as 'internal' with no PII handling requirements."
+- P2: "Data classification does not address backups. If backups contain 'restricted' data, backup storage must meet the same security requirements."
+
+---
+
+## Pass 7: Input Validation
+
+### What to Check
+
+Validation exists at all system boundaries — not just the frontend. Every point where data enters the system (API endpoints, message consumers, file uploads, webhook receivers) has validation specified.
+
+### Why This Matters
+
+Frontend-only validation is a UX convenience, not a security control. Attackers bypass the frontend entirely and send requests directly to the API. Every system boundary where external data enters must validate that data: type checking, range checking, format checking, and business rule validation. Missing server-side validation is the root cause of injection attacks, data corruption, and denial-of-service via malformed input.
+
+### How to Check
+
+1. List every system boundary where external data enters: API endpoints, message queue consumers, file upload handlers, webhook receivers, scheduled job inputs, admin interfaces
+2. For each boundary, verify that input validation is specified
+3. Check that validation covers: type (string/number/boolean), format (email, URL, date), range (min/max length, min/max value), allowed values (enums, whitelists)
+4. Verify that validation is server-side (not relying on client-side validation for security)
+5. Check for file upload validation: file type, file size, content validation (not just extension checking)
+6. Verify that validation error responses do not leak internal information (no stack traces, no database error messages)
+7. Check for rate limiting on endpoints that accept user input (prevent abuse via high-volume invalid input)
+
+### What a Finding Looks Like
+
+- P0: "API endpoint POST /users accepts a request body with no documented validation. An attacker could send a 100MB payload, inject SQL via the name field, or provide an invalid email format."
+- P1: "File upload endpoint validates file extension (.jpg, .png) but does not validate file content. An attacker could upload a malicious script with a .jpg extension."
+- P1: "Webhook receiver accepts payloads from external services with no signature validation. An attacker could forge webhook calls."
+- P2: "Input validation is specified for API endpoints but not for message queue consumers. A malformed message could cause the consumer to crash."