Danvas
Danvas
DashboardSupportWelcome

👤 USER DOCS

User Guides

Getting Started

Getting StartedDashboard & OnboardingApp Settings

Tutorials

Tutorial: Setting Up Shift Tasks & ClosersTutorial: Managing Incidents in the InboxTutorial: Tracking Compliance & Sync StatusTutorial: Operational Workflows with the AI AssistantTutorial: Building & Deploying Custom Checklists

Daily Operations (Staff)

Shift Workspace & TasksService Day SetupDaily Line-UpStaff Service Day ReportsForms

Communication & Chat

Messages & AnnouncementsUnified Operations InboxAI Assistant

Manager & Admin Guides

Daily Line-Up SetupStaff SchedulingManaging LocationsNPS and Guest FeedbackCouponsContacts and Guest HistoryManager CloseoutsDaily Line-Up & ComplianceAnalyticsIncident ReportingWhistleblower Concerns & FeedbackAdmin Tools

⚙️ DEVELOPER DOCS

Getting Started

Getting StartedDevelopmentDeployment Guide

Architecture

Architecture OverviewExplanation: AI Integration & Tenant SecurityExplanation: Dynamic Forms Engine DesignExplanation: Compliance Ledger DesignExplanation: Live Sync & Data FreshnessData FlowArchitecture Decision Records

Core Domain

Core DomainDatabase ReferenceLocations DomainAuth & RBACScheduling DomainReports DomainIncidents DomainUnified Operations InboxLive Sync Data FreshnessToast Sync PipelineNotifications DomainCoupons and Guest NPSAudit Log & Compliance ArchitectureDesign Audit FindingsAI Chat IntegrationAnalytics & Tips Integration

Frontend

Frontend ArchitectureFormsLoading SkeletonsComponentsPWA & Offline ShellScreenshots

API Reference

API Reference

Endpoints

POS Sales APIOptimization Data APISchedule Shifts APIEmployee Export APIReports APIIncidents APIAI Chat APIPush Notifications APIWebhooks APICron API

Contributing

ContributingCode Examples

Security

Security & Compliance

Release Notes

What's New

Contributing

Guidelines for contributing to the Danvas platform

Overview

We welcome contributions! This guide explains our coding standards, testing patterns, and the process for submitting changes.

Engineering Standards

  • Consistency: Adhere to existing naming conventions and architectural patterns.
  • Type Safety: No any. Use strict TypeScript and Drizzle-generated types.
  • Surgical Changes: Keep pull requests focused on a single task. Avoid unrelated refactoring.
  • Self-Documentation: Write clear, descriptive code. Use inline comments for complex business logic only.

Coding Style

We use Biome (via Ultracite) for linting and formatting, and TypeScript for type checking.

# Run all checks (linter + typechecker)
bun run check

# Automatically fix safe lint and format issues
bun run fix

Refer to the Code Style guide for detailed conventions.

Testing

Every change MUST include tests.

  • Unit & Integration Tests: Use Vitest across apps and shared packages.
  • E2E Smoke Tests: Use Playwright for critical app flows (sign-in, filing reports).

Run tests from the repository root:

bun run test          # Run tests across workspace
bun run e2e:smoke     # Run Playwright smoke suite
bun run architecture:check  # Verify package layering boundaries
bun run validate      # Run pre-merge validation pipeline

Submission Process

  1. Create a Branch: git checkout -b feature/your-feature-name.
  2. Commit Changes: Use descriptive, atomic commits.
  3. Open a PR: Target the main branch. Complete the PR template.
  4. Code Review: Address all feedback from the engineering team.
  5. Merge: Once approved and passing CI, your changes will be merged.

Related

Code Style

Architecture Overview

Database Schema

Cron API

Internal endpoints for scheduled operational tasks

Code Examples

Code patterns used in Danvas development

On this page

OverviewEngineering StandardsCoding StyleTestingSubmission ProcessRelated