* feat: Cal.diy — community-driven MIT-licensed fork of Cal.com This squashed commit contains all Cal.diy changes applied on top of calcom/cal.com main: - Rebrand Cal.com to Cal.diy across the entire codebase - Remove Enterprise Edition (EE) features, license checks, and AGPL restrictions - Switch license from AGPL-3.0 to MIT - Remove docs/ directory (migrated to Nextra at cal.diy) - Remove dead code: org tests, EE tips, platform nav, premium username, SAML/SSO, etc. - Clean up .env.example for self-hosted Cal.diy - Update Docker image references to calcom/cal.diy - Update README, CONTRIBUTING.md, and issue templates for Cal.diy community fork - Add PR welcome bot for Cal.diy contributors - Fix API v2 breaking changes oasdiff ignore entries - Replace Blacksmith CI runners with default GitHub Actions 3893 files changed, 20789 insertions(+), 411020 deletions(-) Co-Authored-By: [email protected] <[email protected]> * refactor: remove org-specific /organizations/:orgId endpoints from API v2 atoms controllers (#1701) Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * fix: revert Cal.diy Inc to Cal.com, Inc. in license files, copyright notices, and package metadata (#1702) Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * rip out org related comments in api v2 --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Cal.diy Engineering Rules
This directory contains modular, machine-readable engineering rules derived from Cal.diy's Engineering Standards for 2026 and Beyond.
Structure
Rules are organized by section prefix, as defined in _sections.md:
| Prefix | Section | Impact |
|---|---|---|
architecture- |
Architecture | CRITICAL |
quality- |
Code Quality | CRITICAL |
data- |
Data Layer | HIGH |
api- |
API Design | HIGH |
performance- |
Performance | HIGH |
testing- |
Testing | MEDIUM-HIGH |
patterns- |
Design Patterns | MEDIUM |
culture- |
Team Culture | MEDIUM |
Files
_sections.md- Defines all sections, their ordering, and impact levels_template.md- Template for creating new rules{section}-{rule-name}.md- Individual rule files
Rule Format
Each rule file follows a consistent format with YAML frontmatter:
---
title: Rule Title Here
impact: CRITICAL | HIGH | MEDIUM | LOW
impactDescription: Optional description (e.g., "20-50% improvement")
tags: tag1, tag2, tag3
---
## Rule Title Here
**Impact: LEVEL (optional description)**
Brief explanation of the rule and why it matters.
**Incorrect (description):**
\`\`\`typescript
// Bad code example
\`\`\`
**Correct (description):**
\`\`\`typescript
// Good code example
\`\`\`
Reference: [Link](url)
Adding New Rules
- Copy
_template.mdto a new file with the appropriate section prefix - Fill in the frontmatter (title, impact, tags)
- Write a clear explanation of the rule
- Provide incorrect and correct code examples
- Add a reference link if applicable
Usage
These rules are designed to be:
- Human-readable: Engineers can browse and learn from them
- Machine-readable: AI agents can parse and apply them
- Modular: Individual rules can be updated without affecting others
- Versionable: Changes are tracked in git history
Core Principles
From the blog post, our engineering philosophy is:
We are building infrastructure that must almost never fail. To achieve this, we move fast while shipping amazing quality software with no shortcuts or compromises.
The rules in this directory encode the specific practices that enable this philosophy.