Dayuse Vibe Coding Standards

This skill ensures that code generated for non-developers meets professional standards while remaining understandable.

Core Principles

When generating code, you MUST follow these rules:

1. TypeScript only - All code must use strict TypeScript
2. No any type - The any type is strictly forbidden
3. DDD Architecture - Organize code according to Domain-Driven Design
4. Systematic testing - Every feature requires tests
5. Mandatory linting - Code must pass ESLint and Prettier
6. Zod validation - Validate external inputs with Zod
7. Result Pattern - Use Result<T, E> instead of throw/catch
8. Security by default - Security audit, authorization checks, and no hardcoded secrets

DDD Architecture

Organize code into 4 distinct layers:

src/
├── domain/           # Business logic (THE WHAT)
│   ├── entities/     # Business objects with identity
│   ├── value-objects/# Immutable objects without identity
│   ├── repositories/ # Data access interfaces
│   └── services/     # Complex business operations
│
├── application/      # Use Cases (THE HOW)
│   ├── use-cases/    # Unit business operations
│   └── dtos/         # Data Transfer Objects
│
├── infrastructure/   # Technical details (THE WHERE)
│   ├── repositories/ # DB/API implementations
│   ├── services/     # External services
│   └── persistence/  # DB configuration
│
└── interfaces/       # Entry points (THE WHO)
    ├── http/         # REST controllers
    ├── cli/          # CLI commands
    └── events/       # Event handlers

Layer Rules

Strict TypeScript

Required Configuration

All projects must have the following in tsconfig.json:

{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "noImplicitReturns": true,
    "noUncheckedIndexedAccess": true
  }
}

Alternatives to the any Type

Type Guard Pattern

function isUser(value: unknown): value is User {
  return (
    typeof value === 'object' &&
    value !== null &&
    'id' in value &&
    'name' in value
  );
}

Validation with Zod

Use Zod to validate ALL external inputs:

import { z } from 'zod';

// Define the schema
const CreateUserSchema = z.object({
  name: z.string().min(2).max(100),
  email: z.string().email(),
  age: z.number().int().positive().optional(),
});

// Infer the TypeScript type
type CreateUserInput = z.infer<typeof CreateUserSchema>;

// Validate data
function validateInput(data: unknown): Result<CreateUserInput, ValidationError> {
  const result = CreateUserSchema.safeParse(data);
  if (!result.success) {
    return err(new ValidationError(result.error.issues));
  }
  return ok(result.data);
}

Result Pattern

Never use throw/catch for business errors. Use the Result Pattern instead:

type Result<T, E = Error> =
  | { success: true; data: T }
  | { success: false; error: E };

// Helpers
const ok = <T>(data: T): Result<T, never> => ({ success: true, data });
const err = <E>(error: E): Result<never, E> => ({ success: false, error });

// Usage
function createUser(input: CreateUserInput): Result<User, UserError> {
  if (await userExists(input.email)) {
    return err(new EmailAlreadyExistsError(input.email));
  }
  const user = new User(generateId(), input.name, input.email);
  return ok(user);
}

// Consumption
const result = createUser(input);
if (!result.success) {
  // Handle the error
  return handleError(result.error);
}
// Use result.data

Security and Authorization (Zero Trust)

The AI must adopt a Zero Trust approach: never trust inputs or implicit state.

1. Systematic Authorization Checks

Every business action must verify WHO is performing it and whether they have the RIGHT to do so.

// ❌ BAD: Assumes the user has permission because they are authenticated
function deleteProject(projectId: string, user: User) {
  return projectRepo.delete(projectId);
}

// ✅ GOOD: Explicit permission check (Business Logic)
function deleteProject(projectId: string, user: User): Result<void, AppError> {
  const project = await projectRepo.findById(projectId);

  // Ownership or role check
  if (project.ownerId !== user.id && user.role !== 'ADMIN') {
    return err(new UnauthorizedError("You do not have permission to delete this project"));
  }

  return projectRepo.delete(projectId);
}

2. No Hardcoded Secrets

NEVER write API keys, tokens, passwords, or certificates directly in code.

// ❌ FORBIDDEN
const API_KEY = "sk-1234567890abcdef";

// ✅ REQUIRED
const API_KEY = process.env.OPENAI_API_KEY;

3. Input Sanitization

Never insert raw user data into:

• HTML (XSS risk)
• SQL queries (SQL Injection risk)
• System commands (Command Injection risk)

Use Zod to validate the format and escaping libraries for display.

Testing with Vitest

Test Location

Place tests alongside source files:

src/domain/entities/
├── user.ts
└── user.test.ts

Test Structure

import { describe, it, expect, beforeEach } from 'vitest';

describe('User', () => {
  describe('changeName', () => {
    it('should update name when valid', () => {
      // Arrange
      const user = new User('1', 'John', email);

      // Act
      user.changeName('Jane');

      // Assert
      expect(user.name).toBe('Jane');
    });

    it('should return error when name too short', () => {
      const user = new User('1', 'John', email);
      const result = user.changeName('J');
      expect(result.success).toBe(false);
    });
  });
});

Tests Required For

• All domain Entities and Value Objects
• All application Use Cases
• All public functions
• Edge cases and error handling

Linting

Commands to Run

Before completing ANY code task:

npm run lint        # Check for issues
npm run lint:fix    # Auto-fix issues
npm run format      # Format with Prettier
npm run test        # Run tests

Full Verification Script

npm run lint:fix && npm run format && npm run test

Code Generation Workflow

For each new feature:

1. Determine the Layer

• Pure business logic? -> domain/
• Operation orchestration? -> application/
• External integration? -> infrastructure/
• Entry point? -> interfaces/

2. Create with Proper Types

• Define interfaces first
• Use explicit types everywhere
• Never use any
• Validate inputs with Zod

3. Handle Errors with Result

• Define specific error types
• Return Result instead of throw
• Document error cases

4. Write Tests

• Create the test file alongside the source
• Test the happy path
• Test error cases

5. Verify Quality

npm run lint:fix && npm run format && npm run test

Naming Conventions

Additional Resources

For detailed guides, refer to:

• references/ddd-architecture.md - Complete DDD Patterns
• references/typescript-patterns.md - Alternatives to the any type
• references/testing-guide.md - Complete Vitest Guide
• references/linting-setup.md - ESLint/Prettier Configuration
• references/zod-validation.md - Validation with Zod
• references/result-pattern.md - Detailed Result Pattern

Quick Reference

ALWAYS:
✓ Strict TypeScript
✓ Explicit types everywhere
✓ Tests for all code
✓ Linter before finishing
✓ DDD structure
✓ Zod for external inputs
✓ Result for business errors
✓ Permission checks

NEVER:
✗ any type
✗ Skip tests
✗ Ignore linter errors
✗ Infrastructure logic in domain
✗ throw/catch for business errors
✗ Unvalidated data
✗ Hardcoded secrets/API keys