@tenantegroup/ai-rules-mcp 1.0.0

package/rules/nuxt/code-quality.md

@@ -0,0 +1,71 @@
+# Code Quality Standards
+
+## TypeScript Requirements
+- Enable strict mode in `tsconfig.json`
+- Never use `any` type without justification
+- Define interfaces for all data structures
+- Use type inference where appropriate
+- Export types for reuse across services
+
+## Code Organization
+- Keep functions small and focused (single responsibility)
+- Extract complex logic into named helper functions
+- Group related functionality in services
+- Avoid deep nesting (max 3 levels recommended)
+- Use early returns to reduce nesting
+
+## Naming Conventions
+- Use camelCase for variables and functions
+- Use PascalCase for classes and types
+- Use UPPER_CASE for constants
+- Use descriptive names (avoid abbreviations)
+- Prefix boolean variables with `is`, `has`, or `should`
+
+## Comments and Documentation
+- Write self-documenting code when possible
+- Comment only when code intent is not obvious
+- Document complex business logic
+- Explain "why" not "what" in comments
+- Keep comments up-to-date with code changes
+
+## Error Handling
+- Use typed error classes when appropriate
+- Never swallow errors silently
+- Log errors with appropriate context
+- Return meaningful error messages to clients (without exposing internals)
+- Handle async errors with try-catch or proper promise chains
+
+## Dependency Management
+- Keep dependencies minimal
+- Regularly update dependencies
+- Review dependency security advisories
+- Avoid adding dependencies for simple functionality
+- Prefer Cloudflare-compatible packages
+
+## Code Reusability
+- Extract shared logic into `/server/utils/`
+- Create reusable services for common operations
+- Define shared types in dedicated type files
+- Avoid code duplication (DRY principle)
+- Balance reusability with simplicity
+
+## Git Practices
+- Write clear, descriptive commit messages
+- Make small, focused commits
+- Reference issues in commit messages when applicable
+- Keep branches short-lived
+- Squash commits when appropriate before merging
+
+## Pull Request Standards
+- Include clear description of changes
+- Link related issues
+- Request review from appropriate team members
+- Respond to review comments promptly
+- Ensure CI passes before requesting review
+
+## Refactoring Guidelines
+- Refactor incrementally, not in large batches
+- Maintain test coverage during refactoring
+- Run tests after each refactor step
+- Document significant architectural changes
+- Keep refactoring PRs separate from feature PRs when possible

package/rules/nuxt/configuration.md

@@ -0,0 +1,31 @@
+# Configuration Standards
+
+## nuxt.config.ts
+- Set Nitro preset to `cloudflare`
+- Enable strict TypeScript mode
+- Use runtime config for all secrets
+- Never hardcode sensitive values
+
+## wrangler.toml
+- Name D1 binding as `DB`
+- Create separate environment blocks for dev, staging, and production
+- Never include hardcoded secrets
+- Declare all resource bindings explicitly (D1, KV, R2, Queues, Durable Objects)
+- Specify compatibility date
+
+## drizzle.config.ts
+- Define schema in `/server/db/schema.ts`
+- Output migrations to `/drizzle` directory
+- Set driver to `d1`
+- Reference `wrangler.toml` for database credentials
+
+## Environment Variables
+- Commit only `.env.example` to repository
+- Store secrets in Cloudflare and GitHub Secrets
+- Use different secrets per environment (dev, staging, production)
+- Never commit actual `.env`, `.env.staging`, or `.env.production` files
+- Never hardcode credentials in source code
+
+## File Commit Policy
+- Commit all configuration files (nuxt.config.ts, wrangler.toml, drizzle.config.ts)
+- Never commit files containing secrets

package/rules/nuxt/core-directives.md

@@ -0,0 +1,12 @@
+# ABSOLUTE CONSTRAINTS
+
+1. **Edge Parity:** You MUST design all code for the Cloudflare Workers runtime.
+   - Use Web Standard APIs (Fetch, Web Crypto).
+   - NEVER use Node.js core modules (`fs`, `path`, `process`).
+   - NEVER access `process.env` directly; use Nitro env bindings or `useRuntimeConfig()`.
+2. **Database (D1 & Drizzle):**
+   - Central schema file is `/server/db/schema.ts`.
+   - All queries MUST use Drizzle ORM. No raw SQL.
+   - Never use KV as primary relational storage.
+3. **Local Dev:** Assume `wrangler dev` is the source of truth for local parity, not `nuxt dev` alone.
+4. **Validation Requirement:** You MUST run `node .ai/scripts/validate-code.js` after writing any code to ensure edge compatibility.

package/rules/nuxt/project-initialization.md

@@ -0,0 +1,53 @@
+# Project Initialization
+
+## Template Repository Policy
+- Every new project begins from the official template repository
+- No project starts from scratch
+- Template includes pre-configured Nuxt + Cloudflare + Drizzle setup
+
+## New Project Checklist
+Complete these steps in order for every new project:
+- [ ] Initialize Nuxt project from template
+- [ ] Add Cloudflare preset to Nitro config
+- [ ] Install Drizzle ORM and drizzle-kit
+- [ ] Configure Wrangler with separate environments (dev, staging, production)
+- [ ] Create D1 databases for each environment
+- [ ] Define initial database schema in `/server/db/schema.ts`
+- [ ] Generate first migration using `drizzle-kit generate`
+- [ ] Run migration using `drizzle-kit migrate`
+- [ ] Create seed file at `/server/db/seed.ts` (if needed)
+- [ ] Implement authentication based on project type
+- [ ] Create first service in `/server/services/`
+- [ ] Create first API route in `/server/api/`
+- [ ] Add first test in `/tests/`
+- [ ] Setup GitHub Actions workflow for CI/CD
+- [ ] Deploy to staging and verify
+- [ ] Deploy to production
+
+## Initial Configuration Files
+Create and configure:
+- `nuxt.config.ts` with Cloudflare preset and strict TypeScript
+- `wrangler.toml` with environment blocks and bindings
+- `drizzle.config.ts` with schema and migration paths
+- `.env.example` with required environment variables (commit this only)
+- `.gitignore` including `.env`, `.env.staging`, `.env.production`
+- `README.md` with project setup and deployment instructions
+
+## First Feature Development
+After initialization, implement this order:
+1. Define database schema for first domain
+2. Generate and run migration
+3. Create service with database queries
+4. Add unit tests for service
+5. Create API endpoint using service
+6. Add authentication middleware if needed
+7. Test locally with `wrangler dev`
+8. Deploy to staging
+
+## Documentation Requirements
+Every project must include:
+- README with setup instructions
+- Environment variable documentation
+- Database schema overview
+- Authentication flow documentation
+- Deployment process documentation

package/rules/nuxt/project-structure.md

@@ -0,0 +1,44 @@
+# Project Structure
+
+## Standard Directory Layout
+Organize all projects using this structure:
+```
+root/
+  app/                    # UI layer
+  server/
+    api/                  # REST endpoints
+    services/             # Business logic
+    db/                   # Database layer
+    middleware/           # Auth, logging, request handling
+    utils/                # Shared utilities
+  tests/                  # Test files
+  drizzle/                # Migration files
+  .github/workflows/      # CI/CD pipelines
+  nuxt.config.ts
+  drizzle.config.ts
+  wrangler.toml
+  README.md
+```
+
+## Structural Rules
+- Place no business logic in API handlers
+- Make no direct database calls in API files
+- Use middleware for authentication and authorization
+- Ensure services are testable without Nuxt runtime
+- Keep API routes thin and focused on request/response handling
+
+## API Organization
+For API-only services, organize routes by version:
+```
+server/
+  api/
+    v1/
+      users.get.ts
+      users.post.ts
+      tasks.get.ts
+```
+
+## Service Organization
+- Group services by domain or feature area
+- Inject database instances into service constructors
+- Keep services independent of framework-specific context

package/rules/nuxt/testing.md

@@ -0,0 +1,48 @@
+# Testing Requirements
+
+## Testing is Mandatory
+Implement tests from day one. No exceptions.
+
+## Minimum Testing Requirements
+Every project must have:
+- Unit tests for all service methods
+- Authentication middleware tests
+- At least one database integration test per critical domain
+
+## Testing Pyramid (Early Stage)
+Distribute tests as:
+- 70% Service unit tests
+- 20% Middleware/authentication tests
+- 10% Database integration tests
+
+## Tooling
+- Use Vitest as test runner
+- Use Node test environment
+- Mock only at external boundaries
+
+## Service Testing
+- Inject database instances into services for easy mocking
+- Test business rules independently of framework context
+- Keep tests fast (unit suite should run in under 1 second)
+- Mock at boundaries, never inside business rules
+
+## Middleware Testing
+Test authentication and authorization:
+- Missing token returns 401
+- Invalid token returns 401
+- Valid token allows request to proceed
+- Roles are correctly enforced
+
+## Database Integration Testing
+- Use local D1 binding for tests
+- Run migrations before test execution
+- Use isolated test database
+- Reset database state between test runs
+- Test at least one full CRUD cycle per domain
+
+## Test Principles
+- Test business logic, not frameworks
+- Ensure services are testable without Nuxt runtime
+- Keep tests fast and focused
+- Avoid testing framework internals
+- Mock only external boundaries (database, APIs)