Files
multitenetsaas/.specify/memory/constitution.md
AHMET YILMAZ b3fff546e9
Some checks failed
System Monitoring / Health Checks (push) Has been cancelled
System Monitoring / Performance Monitoring (push) Has been cancelled
System Monitoring / Database Monitoring (push) Has been cancelled
System Monitoring / Cache Monitoring (push) Has been cancelled
System Monitoring / Log Monitoring (push) Has been cancelled
System Monitoring / Resource Monitoring (push) Has been cancelled
System Monitoring / Uptime Monitoring (push) Has been cancelled
System Monitoring / Backup Monitoring (push) Has been cancelled
System Monitoring / Security Monitoring (push) Has been cancelled
System Monitoring / Monitoring Dashboard (push) Has been cancelled
System Monitoring / Alerting (push) Has been cancelled
Security Scanning / Dependency Scanning (push) Has been cancelled
Security Scanning / Code Security Scanning (push) Has been cancelled
Security Scanning / Secrets Scanning (push) Has been cancelled
Security Scanning / Container Security Scanning (push) Has been cancelled
Security Scanning / Compliance Checking (push) Has been cancelled
Security Scanning / Security Dashboard (push) Has been cancelled
Security Scanning / Security Remediation (push) Has been cancelled
project initialization
2025-10-05 02:37:33 +08:00

78 lines
2.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# SME SaaS Suite Constitution
## Core Principles
### I. Modular-First
Every feature is implemented as a standalone **module** (POS, Booking, CRM, etc.).
* Modules must be self-contained, testable, and well-documented.
* Modules can be enabled/disabled per tenant based on subscription.
* No feature should hard-depend on another module except via well-defined contracts.
### II. Multi-Tenant by Design
Tenant data must always be isolated and protected.
* All services enforce `tenant_id` checks at DB and API layers.
* Multi-tenancy is implemented with row-level security in PostgreSQL.
* No cross-tenant data leakage tolerated.
### III. Test-First Development (Non-Negotiable)
* TDD is mandatory: write failing test → implement feature → pass test → refactor.
* Red-Green-Refactor cycle enforced.
* Each module requires:
* Unit tests (≥ 80% coverage)
* Integration tests for inter-module APIs
* End-to-end tests for user workflows
### IV. Observability & Debuggability
* Structured logging with `tenant_id`, `user_id`, `module` metadata required.
* Metrics (latency, error rate, DB queries) collected per module.
* Errors must include clear context (trace ID + tenant info).
* Debug mode outputs JSON + human-readable logs.
### V. Simplicity & Maintainability
* Prefer minimal solutions (YAGNI principle: *You Arent Gonna Need It*).
* UI/UX designed for low digital literacy users (SMEs).
* No hidden complexity: every architectural decision must be justified in writing.
---
## Security & Compliance
* All API calls require JWT auth with tenant scope.
* Role-based access control: Owner, Manager, Staff.
* Data encrypted at rest (Postgres, S3 storage) and in transit (HTTPS/TLS).
* Payment integration (Stripe/Midtrans) must meet PCI-DSS compliance.
* Regular security audits + penetration testing required before major releases.
---
## Development Workflow
* **Branches:** `main` (stable), `dev` (integration), `feature/*` (modules).
* **Reviews:** All PRs require at least 1 reviewer approval.
* **CI/CD Gates:**
* Unit + integration tests must pass.
* Linting + type checks required.
* Vulnerability scan required.
* **Deployment:** Automated via Docker + Kubernetes. Canary releases before full rollout.
* **Release Cycle:** Monthly minor releases, quarterly major releases.
---
## Governance
* This Constitution supersedes all coding styles and practices.
* Amendments require documentation + team approval.
* No module may ship without compliance to principles.
* Exceptions must be documented with expiration date.
**Version**: 1.0.0 | **Ratified**: 2025-10-04 | **Last Amended**: 2025-10-04