Skip to content

STD-ARC-004: Application Boundaries & Behaviors

Status: Living Document Authority: High - "The Constitution" Last Updated: January 2026

This document defines the architectural boundaries, distinct roles, and global behaviors for the applications within the Singular Dream monorepo. It serves as the primary reference for where code belongs and how applications should interact.

1. Global Behaviors (The Common Law)

These rules apply to all applications within the repository (@sd/*).

1.1 Technology Standards

  • Language: strict TypeScript (strict: true) is mandatory for all new code.
  • Package Management: pnpm with TurboRepo for workspace management.
  • Formatting: Prettier for code style, ESLint for code quality.
  • Environment config: All apps must support the 3-Tier Environment Model (dev, stg, prod).

1.2 Monorepo Citizenship

  • Shared Code: Business logic, types, and utilities shared by more than one app must reside in packages/.
  • foundation-*: Core building blocks (auth, data, logging).
  • mod-*: Domain-specific business modules (finance, community).
  • ui: Shared design system components.
  • No Direct App-to-App Imports: Apps must not import directly from other apps (e.g., web cannot import from marketing). Inter-app communication must happen via APIs or shared libraries.

1.3 State & Data

  • Single Source of Truth: Data definitions (schemas) live in foundation-data or domain packages, not in individual apps.
  • Environment Isolation: Production data is strictly isolated. No app in a dev environment may connect to prod services.

2. Application Domains

2.1 Public Portal (The Truth)

Identity: "The Exposé" Package: @sd/marketing (Legacy name, technically apps/portal) Location: apps/marketing

Role & Purpose

The public face of Singular Dream is NOT a sales tool. It is a Forensic Exposé & Case for Action.

  • Target Audience: Existing Owners (Victims of mismanagement).
  • Mission: To reveal the historical scandal (waste, fraud, abuse) and mobilize owners to join the new Sovereign Platform.
  • Tone: Cinematic, Serious, Urgent, Investigative.

Key Behaviors

  • Deeply Cinematic: Uses motion and narrative to tell the history of the scandal.
  • Mobilization First: Every page drives the user to "The Ascent" (Onboarding/Claiming their Unit).
  • Read-Mostly: Delivers information.
  • Stateless: Simple delivery.

Rigid Boundaries

  • ⛔ NO Direct writing to the core Platform database.
  • ⛔ NO "Sales" language. This is about Justice, not Products.
  • ✅ YES Consumption of public APIs.
  • ✅ YES Collection of "Ascent" data (secure submission to Platform).

2.2 Platform Application

Identity: "The Engine" Package: @sd/platform (or platform legacy) Location: apps/platform

Role & Purpose

The core product. This is the Business Operating System. It is primarily Administrative and Transactional but maintains Cinematic Undertones to distinguish it from generic SaaS.

Key Behaviors

  • Pre-Auth (The Hero): The Login/Landing page adheres to the Deeply Cinematic standard. It is the visual bridge from Marketing.
  • Post-Auth (The Workspace): Shifts to the Blended Standard (Apple-like polish).
  • Thematic Wallpapers: Uses subtle, cinematic wallpapers to queue domain context (e.g., Green/Gold for Finance, Blue/Glass for Community).
  • Strong Navigation: Elegant, intuitive navigation is the anchor of the experience.
  • The Line Crossed: We use cinematic visuals for Context, NOT for Narrative. The Platform does not tell a story; it facilitates a lifestyle.

Rigid Boundaries

  • ⛔ NO Active Storytelling. No "scroll-jacking" to force a narrative arc inside the app.
  • ⛔ NO "Marketing" fluff code inside the authenticated shell.
  • ✅ YES High-end materials (Glass, Blur, Light) for UI components.
  • ✅ YES The Authoritative Writer for business data.

2.3 SysOps Application

Identity: "The God Hand" Package: @sd/sysops Location: apps/sysops

Role & Purpose

The Operational Control Plane. It is strictly Administrative and Transactional. It minimizes cinematic flair in favor of raw efficiency but checks the "Branding Box" to feel part of the family.

Key Behaviors

  • Pure Utility: "Minimum of cinematic quality". No distractions.
  • Branded Fidelity: Uses the correct brand color palette and typography to maintain family resemblance.
  • Simple Backgrounds: No heavy wallpapers or textures. Clean, high-contrast readability.
  • Omnipotent Capability: Runs with elevated privileges.
  • Automation First: Designed for CLI and efficiency.

Rigid Boundaries

  • ⛔ NO Hosting of Business Logic. SysOps should trigger a Platform API to "Create User", not write raw SQL to insert a user (unless in disaster recovery).
  • ✅ YES Cross-cutting visibility. Can see data from all environments (with proper auth).
  • ✅ YES Destructive capability (can wipe databases, restart servers).

3. Interaction Matrix

Source App Target: Marketing Target: Platform Target: SysOps
Marketing N/A Link Only. Marketing links to Platform login/signup. None. Marketing is unaware of SysOps.
Platform Link/CMS. May fetch content preview. N/A Signal. May send health/telemetry signals to SysOps.
SysOps Control. Can deploy/monitor Marketing. Control. Can deploy/monitor Platform, trigger jobs. N/A

4. Decision Framework: "Where does this code go?"

Scenario A: "I need to add a new 'About Us' animation."

➡️ Marketing App. This is narrative/presentation code.

Scenario B: "I need to calculate the late fees for a unit."

➡️ Shared Package (mod-finance) imported by Platform. This is core business logic.

Scenario C: "I need to restart the staging server every night."

➡️ SysOps App. This is operational automation.

Scenario D: "I need a standard 'Button' component."

➡️ Shared UI Package (packages/ui). Used by Marketing (maybe) and Platform.

5. Editorial Protocol

When reviewing this document in Typora, you may leave instructions for the AI using the following syntax:

[!AI] Update the SysOps section to include "CloudOps" as a future module.

The AI will detect this block, perform the action, and remove the block.

7. Platform UX Patterns

7.1 The Workstation Concept

The Platform unifies all domains into a consistent "Workstation" model. Users do not "visit pages"; they "enter workspaces".

  • Goal: Cognitive continuity. A Property Manager switching from Finance to Compliance should feel they are in the same room, just using different tools.
  • Structure:
  • Summary First (The Head): Key metrics, KPIs, and high-level status at the top.
  • Action Grid (The Body): The primary interactive area (usually a Data Grid).
  • Detail/Sub-Workspace (The Hands): Clicking a line item opens a detailed view or sub-workspace actionable context.

7.2 Information Hierarchy

Level 1: The Dashboard (Summary)

  • High-level aggregation.
  • "Traffic Light" status indicators (Red/Yellow/Green).
  • NO complex editing here.

Level 2: The Grid (List)

  • Primary Source: Syncfusion Data Grid.
  • Filtering, Sorting, Grouping.
  • Bulk Actions.

Level 3: The Detail (Item)

  • Full context of a single entity (e.g., a Unit, an Invoice).
  • Tabs for related sub-entities.
  • Complex forms.

7.3 Component Selection Strategy

To maintain velocity and consistency, we follow a strict hierarchy of implementation:

  1. Primary Source: Syncfusion (@syncfusion/ej2-*)

    • Use for: Complex Data Grids, Charts, Schedulers, Kanban boards, Rich Text Editors.
    • Why: It provides enterprise-grade functionality out of the box. Do not reinvent the Data Grid.

  2. Secondary Source: Shadcn/UI & Tailwind (packages/ui)

    • Use for: Layout primitives, Cards, Buttons, Dialogs, simple Inputs, Typography.
    • Why: It provides the aesthetic "glue" and the modern, accessible feel that wraps the heavy Syncfusion components.

  3. Tertiary Source: Custom Development

    • Use for: Only when the above two cannot solve the problem (e.g., a specific 3D visualization or highly custom workflow).
    • Rule: "Don't build it if you can buy/borrow it."

7.4 The Integration Mandate (Visual Compliance)

Functionality at the cost of aesthetics is a FAILURE. When using "Primary Source" components (Syncfusion) that come with their own styles, you MAY NOT use them "out of the box" if they clash with the "Cinematic/Blended" vibe.

  • [MUST] Visual Taming: You must override the default styles (via CSS or Theme Studio) to match our Layout, Typography, and Color tokens.
  • [MUST] Seamless Blend: A user should not be able to tell where "Shadcn" ends and "Syncfusion" begins.
  • [Example]: A Syncfusion Data Grid must have its borders, headers, and row heights adjusted to match the surrounding "Glassmorphic" container.

8. Satellite Domains (External)

8.1 Singular Dream Docs

Identity: "The Library" Location: External Repo (Satellite) Status: Subservient to the Monorepo

Role & Purpose

The definitive Knowledge Base for the ecosystem. While technically external, it is spiritually part of the platform. It serves Developers, Integrators, and Power Users.

Visual Standard

  • Style: Academic / Archival.
  • Goal: "Zero Friction". The user is there to learn, not to be entertained.
  • Characteristics:
  • High-contrast typography (Inter/Geist Mono).
  • Minimal UI chrome.
  • No cinematic effects.
  • Excellent search and indexing.
  • Relationship: It mirrors the Structure of the Platform (Workstation concepts) but strips away the Visuals to focus on the text.

9. Glossary of Terms

6.1 Design Styles

6.1 The Visual Spectrum

1. Deeply Cinematic (Marketing)

The "Movie"

  • Goal: Total Immersion.
  • Characteristics: Heavy 3D, WebGL, scrolly-telling, video backgrounds.
  • Vibe: "I am watching a story."

2. Administrative w/ Cinematic Undertones (Platform)

The "Cockpit"

  • Goal: Delightful Utility.
  • Characteristics: Dense information but with premium materials (glass, light, motion).
  • Vibe: "I am doing important work in a beautiful machine."

3. Administrative & Transactional (SysOps)

The "Engine Room"

  • Goal: Raw Efficiency with Brand Fidelity.
  • Characteristics: Lists, logs, terminals. Minimal motion.
  • Vibe: "I am fixing the machine. Don't slow me down."

Version History

Version Date Author Change
0.1.0 2026-01-26 Antigravity Initial Audit & Metadata Injection