Setup & Development Guardrails
Relevant source files
The following files were used as context for generating this wiki page:
This page outlines the operational guardrails, technical standards, and development workflows enforced within the Comply-Quick project. These guardrails ensure strict type safety, consistent UI/UX via utility-first styling, and a modular architecture that supports reliable automated compliance package generation.
The project utilizes a Next.js App Router architecture with a heavy emphasis on TypeScript strictness and Tailwind CSS for responsive design. These standards are enforced across the entire build lifecycle to maintain code quality and prevent common regressions.
Sources: devin/instructions.md:1-5, package.json:1-35
1. Technical Standards & Code Quality
Development in Comply-Quick is governed by five core operational guardrails that apply to both human and AI contributors.
TypeScript Strict Compliance
The project mandates strict: true within tsconfig.json. Developers are prohibited from using implicit any types, as any type casting, or suppression comments like @ts-ignore. Every variable, parameter, and return value must be explicitly typed or inferable.
Sources: devin/instructions.md:9-15
Architectural Constraints
The project follows a modular, single-responsibility design pattern. Each component file must export exactly one component and should not exceed approximately 150 lines of code.
| Standard | Requirement |
|---|---|
| Component Location | src/components/ (organized by domain) |
| Shared Utilities | src/lib/ |
| Custom Hooks | src/hooks/ |
| File Paths | Absolute Constraint: No parentheses in any path (e.g., use src/app/auth/ instead of src/app/(auth)/) |
| Imports | Top-of-file only; use @/* path alias |
| Sources: devin/instructions.md:23-45 |
Styling & Responsive Design
All styling must use Tailwind CSS utility classes. Mobile-first design is required, starting with base styles and layering breakpoints (sm:, md:, lg:, xl:). Hard-coded pixel widths on layout containers are forbidden.
Sources: devin/instructions.md:17-21
2. Testing Framework & Quality Assurance
The project employs a robust testing suite powered by Vitest to ensure the integrity of the core logic engine and API compliance.
Core Logic Validation
The ClauseEngine is validated through extensive unit tests that check for framework-specific clauses, regional disclosures, and compliance score accuracy.
The diagram shows the testing flow triggered by the test script defined in package.json.
Sources: package.json:9, src/tests/ClauseEngine.test.ts:10-50
Quality Scripts
Pre-commit checks are managed via husky and lint-staged.
| Script | Command | Purpose |
|---|---|---|
lint | eslint | Enforce code style and identify problematic patterns. |
typecheck | tsc --noEmit | Ensure full TypeScript type safety across the project. |
test | vitest run | Execute unit and integration tests. |
quality | npm run typecheck && npm run lint && npm run test && npm run format:check | Comprehensive check before deployment or merging. |
| Sources: package.json:7-18 |
3. Component & Data Flow Architecture
The development of new features, such as the DashboardWizard, must adhere to a specific data flow where user inputs are transformed into a CompliancePackage through a centralized logic engine.
Wizard Interaction Flow
The DashboardWizard guides users through a multi-step selection process, validating inputs at each stage before generating the final legal artifacts.
This sequence illustrates how user selections in the UI interact with the core ClauseEngine to produce compliant output.
Sources: src/app/dashboard/DashboardWizard.tsx:100-150, src/components/ClauseEngine.tsx:430-480
Input Constraints & Validation
The ClauseEngine enforces a strict matrix of allowed values for frameworks, pixels, and regions to prevent malformed package generation.
// src/components/ClauseEngine.tsx:406-428
const VALID_FRAMEWORKS: ReadonlySet<string> = new Set([
"shopify", "nextjs", "wordpress", "wix", "squarespace", "godaddy", "webflow", "woocommerce", "bigcommerce"
]);
function validateInput(input: ComplianceInput): void {
if (!VALID_FRAMEWORKS.has(input.framework)) {
throw new Error(`Invalid framework: "${input.framework}"`);
}
// Additional validation for pixels and regions...
}
Sources: src/components/ClauseEngine.tsx:406-428
4. Environment & Deployment Guardrails
Comply-Quick uses Next.js environment conventions and specific metadata configurations for SEO and security.
- Secrets Management: API keys and credentials must never be committed;
.env.localis used for local secrets. - Path Mapping: The
@/*alias is mapped to./src/*for all internal imports. - Metadata: Global site configuration, such as
SITE_URL, is derived fromprocess.env.NEXT_PUBLIC_SITE_URL.
Sources: devin/instructions.md:41-43, src/app/page.tsx:6
Dependency Guardrails
The project relies on specific versions of core libraries to ensure compatibility, including React 19 and Next.js 16.
Sources: package.json:23-35
Conclusion
Setup and development in Comply-Quick are heavily structured around operational guardrails defined in devin/instructions.md. By strictly enforcing TypeScript types, modular component design, and forbidden path patterns, the project ensures that its automated legal generation engine remains technically sound and maintainable. All contributors are expected to run the quality script to verify compliance with these standards before any commit.