d4ea931bf8
* feat(agents): add modular engineering rules from 2026 standards Add a rules directory with individual rule files derived from the Cal.com Engineering in 2026 and Beyond blog post. Rules are organized by section (architecture, quality, data, api, performance, testing, patterns, culture) following the Vercel agent-skills structure. Includes: - _sections.md defining rule categories and impact levels - _template.md for creating new rules - 14 individual rule files covering key engineering standards - README documenting the rules structure and usage Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * feat(agents): consolidate DI and Repository+DTO docs into rules - Move di-pattern.md content to rules/patterns-di-pattern.md - Extract Repository + DTO section from knowledge-base.md into: - rules/data-repository-methods.md (method naming conventions) - rules/data-dto-boundaries.md (DTO location and naming) - Update knowledge-base.md to reference the new rule files - Delete old di-pattern.md file Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * chore(agents): remove stub reference sections from knowledge-base.md The rules directory is self-contained with its own README, so these redirect sections are unnecessary clutter. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * refactor(agents): combine DI pattern rules into single file Merged patterns-di-pattern.md into patterns-dependency-injection.md to eliminate overlap and create one comprehensive DI guide. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
2.5 KiB
2.5 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Handle NP-Hard Scheduling Problems Carefully | HIGH | Prevents exponential blowup in scheduling operations | performance, scheduling, algorithms, np-hard |
Handle NP-Hard Scheduling Problems Carefully
Impact: HIGH
Scheduling problems are fundamentally NP-hard. This means that as the number of constraints, participants, or time slots grows, the computational complexity can explode exponentially. Most optimal scheduling algorithms have worst-case exponential time complexity, making algorithm choice absolutely critical.
Real-world implications:
- Finding the optimal meeting time for 10 people across 3 time zones with individual availability constraints is computationally expensive
- Adding conflict detection, buffers, and other options amplifies the problem
- Poor algorithm choices that work fine for small teams become completely unusable for large organizations
- What takes milliseconds for 5 users might take many seconds for organizations
Strategies for managing NP-hard complexity:
// Use approximation algorithms
async function findMeetingTime(participants: User[], duration: number) {
// Find "good enough" solution quickly rather than perfect solution slowly
const approximateSlots = await findApproximateAvailability(participants, {
maxIterations: 1000,
timeout: 500, // ms
});
return approximateSlots[0]; // Return first good-enough option
}
// Implement aggressive caching
const cachedAvailability = new LRUCache<string, Availability>({
max: 10000,
ttl: 1000 * 60 * 5, // 5 minutes
});
// Pre-compute common scenarios during off-peak hours
async function precomputeTeamAvailability(teamId: number) {
// Run during low-traffic periods
const team = await teamRepository.findById(teamId);
const availability = await computeTeamAvailability(team);
await cache.set(`team:${teamId}:availability`, availability);
}
Key strategies:
- Use approximation algorithms that find "good enough" solutions quickly
- Implement aggressive caching of computed schedules and availability
- Pre-compute common scenarios during off-peak hours
- Break large scheduling problems into smaller, more manageable chunks
- Set reasonable timeout limits and fallback to simpler algorithms when needed
This is why performance isn't just a nice-to-have in scheduling software. It's the foundation that determines whether your system can scale to enterprise needs.
Reference: Cal.com Engineering Blog