Data model supports all PRD requirements

When your data model does not cover entities the PRD requires, features that depend on that data silently degrade or fail at runtime. A missing join table for team membership means multi-user collaboration can never persist correctly. A missing audit_results relation means you cannot display scores — the kind of gap that surfaces only after launch, when fixing it requires a migration, a data backfill, and coordinated API changes. ISO 25010:2011 functional suitability defines this as a core quality dimension: software must fulfill its stated functional requirements. Any entity absent from the schema is a hard blocker, not a soft deficiency.

Add the missing entities and relationships directly to your schema file. In Prisma, that means defining the model and its relations, then running prisma migrate dev:

// prisma/schema.prisma
model Team {
  id       String   @id @default(cuid())
  name     String
  members  TeamMember[]
  projects Project[]
}

model TeamMember {
  teamId String
  userId String
  role   String
  team   Team   @relation(fields: [teamId], references: [id])
  @@id([teamId, userId])
}

After migrating, update your RLS policies and permission checks in src/lib/auth/ to account for the new ownership model.

• ID: goal-alignment.feature-completeness.data-model-supports-requirements
• Severity: high
• What to look for: Enumerate every relevant item. Read the PRD for data entities, relationships, and storage requirements. Check the actual data model (Prisma schema, Drizzle schema, database migration files, or equivalent) to verify the entities and relationships exist. If no formal schema file exists, inspect the API routes and component data shapes for implicit data model signals.
• Pass criteria: All entities and relationships described or implied in the PRD are represented in the data model. Field names may differ, but the underlying concepts (user accounts, project records, audit results, etc.) are present with the required relationships. Before evaluating, extract and quote the relevant configuration or code patterns found. Report the count of items checked even on pass.
• Fail criteria: One or more PRD-required data entities, relationships, or fields are absent from the data model. This includes cases where a feature requires persisting data that the PRD specifies, but no schema for it exists.
• Do NOT pass when: The item exists only as a placeholder, stub, or TODO comment — partial implementation does not count as passing.
• Skip (N/A) when: The project has no database or persistent data layer (static sites, CLI tools, or projects where all data is external/read-only).
• Detail on fail: Name the specific entities or relationships missing. Example: "PRD requires team collaboration (multiple users per project) but schema has no teams table or user-project join table." Max 500 chars.
• Remediation: Your data model does not support the full feature set your PRD describes. Add the missing tables/models and their relationships in your schema file (e.g., prisma/schema.prisma, src/db/schema.ts). Run database migrations after updating the schema. Be aware that adding new entities mid-project may require updates to authentication/authorization logic (RLS policies, permission checks).
• Cross-reference: For analysis of how well the implementation quality holds up once the data model is complete, the Code Maintainability audit covers this in detail.

Dynamic checks (generated from PRD content):

For each requirement you extracted in the PRD parsing step, generate one check following this template:

• ID pattern: goal-alignment.feature-completeness.req-{N} where N is the sequential number of the requirement (1, 2, 3...) in the order you identified them
• Label: State the requirement as a positive assertion of what should be true. Example: "User registration with email and password is implemented"
• Severity: Assign based on requirement priority tier:
  • Core requirements → critical
  • Important requirements → high or medium (use high for features that directly support the core value proposition, medium for supporting features)
  • Nice-to-have requirements → low or info
• What to look for: Examine the route files, component files, and API handlers that should correspond to this requirement.
• Pass criteria: The requirement is implemented — the corresponding UI, logic, and data handling exist and appear functional.
• Fail criteria: The requirement is partially implemented (UI exists but no backend), not implemented (no corresponding code found), or implemented differently than specified in a way that changes the user-visible behavior.
• Skip (N/A) when: The requirement is explicitly dependent on an external system the codebase intentionally does not implement (e.g., "integrate with third-party payment processor" — the integration hook exists but the external service is separate).
• Detail on fail: Be specific about what's missing. Reference the requirement text from the PRD and the closest existing code. Example: "PRD req: 'Users can export their data as CSV'. No export route or CSV generation logic found anywhere in codebase." Max 500 chars.
• Remediation: Implement the missing requirement. Reference the PRD specification for the expected behavior and identify the specific files in src/app/ or src/components/ that need to be created or modified.

Dynamic check severity distribution guidance: When assigning severities to dynamic checks, aim for this approximate distribution of the weight contributed by dynamic checks:

• Critical (core requirements): aim for ~30-40% of dynamic weight
• Warning/high+medium (important requirements): aim for ~40-50% of dynamic weight
• Info/low+info (nice-to-have requirements): aim for ~15-25% of dynamic weight

This ensures the combined static + dynamic check pool hits the required severity bands for the overall audit (Critical 20-50%, Warning 25-50%, Info 5-30% of total weight).