Technical constraint violations discovered late are among the most expensive defects to fix. If your PRD required PostgreSQL for compliance reasons and the AI chose SQLite, or if it required a self-hosted deployment and the codebase is locked to a managed platform, you face a rewrite — not a refactor. Vendor lock-in violations against explicit PRD constraints can also carry legal and contractual consequences, particularly in enterprise or regulated environments. ISO 25010:2011 portability measures exactly this: whether the system operates within its specified technical environment.
High because stack constraint violations discovered after development require partial rewrites to fix and may introduce compliance or contractual risk if the violated constraint was regulatory.
Review your package.json and deployment configuration files against each explicit PRD constraint. For database violations, check prisma/schema.prisma or drizzle.config.ts for the provider:
// prisma/schema.prisma
datasource db {
provider = "postgresql" // Verify this matches your PRD constraint
url = env("DATABASE_URL")
}
For deployment constraints, inspect vercel.json, Dockerfile, or fly.toml for managed-service dependencies. If a constraint genuinely cannot be met with the current implementation, document the deviation explicitly in your project notes and get explicit sign-off before proceeding — do not silently violate a PRD constraint.
goal-alignment.technical-alignment.stack-aligns-with-prd-constraintshigh"PRD explicitly requires 'no external API dependencies for core features' but codebase integrates with OpenAI API for the primary search feature." Max 500 chars.package.json dependencies and src/ configuration files for compliance. Assess the effort required to bring the implementation into compliance with each constraint. If a constraint is genuinely impractical to meet now, document the deviation explicitly in your project notes and evaluate whether the original constraint should be revised.