docs: establish product and modular monolith architecture

[TechAaroorian]

Summary

Establishes the initial product and architecture documentation for SlotSyncro.

This documentation distinguishes current implementation from proposed capabilities and records the decision to evolve the product application as a modular monolith.

Changes

• Add the central design documentation index and writing conventions
• Document SlotSyncro’s product vision, target users, terminology, principles, and boundaries
• Add an implementation-aware feature inventory using Current, Partial, Proposed, and Exploratory statuses
• Document the existing Turborepo structure and distinguish Turborepo from Turbopack
• Define current and proposed application/package responsibilities
• Record dependency-direction and package-extraction rules
• Add ADR 0001 accepting a modular-monolith architecture for apps/app
• Document incremental module migration, transaction boundaries, and cross-module communication
• Add a content-opportunity backlog for articles, videos, Shorts/Reels, LinkedIn, and X
• Add an architecture article explaining monorepos, Turborepo, modular monoliths, microservices, and Turbopack
• Link the design documentation from the root README

Architectural decision

apps/app will evolve as a modular monolith:

• One Next.js product deployment
• One PostgreSQL database
• Explicit business-module ownership
• Typed in-process module communication
• Thin routes and Server Actions
• Local transactions for core business state
• External delivery handled separately from committed state
• Incremental migration during vertical feature work
• No premature microservices or one-package-per-domain structure

The initial target modules are:

• Identity
• Workspaces
• Scheduling
• Availability
• Booking
• Polling
• Meetings
• Notifications
• Integrations

Documentation principles

• Current behavior must be verifiable in code
• Partial implementations and limitations are documented honestly
• Proposed architecture is not presented as shipped functionality
• Business rules and user journeys will drive the future ER model
• Public documentation presents a production-minded portfolio product without exposing private commercial strategy

Validation

• Verified all relative documentation links
• Ran git diff --check
• Checked documentation for obvious credential values
• No application runtime code was changed

Next steps

Follow-up documentation will cover:

1. Actors and user journeys
2. Detailed use cases and failure paths
3. Numbered business rules
4. Current ER model
5. Proposed domain and ER model
6. Runtime system architecture
7. Implementation roadmap

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	100%	88 / 88
🔵	Statements	100%	89 / 89
🔵	Functions	100%	13 / 13
🔵	Branches	100%	33 / 33

File Coverage

No changed files found.

Generated in workflow #18 for commit 73ed1ac by the Vitest Coverage Report Action