@bluealba/platform-cli 1.0.1 → 1.1.0

package/docs/getting-started/core-concepts.mdx

@@ -0,0 +1,892 @@
+---
+title: Core Concepts
+description: Essential concepts of the Blue Alba Platform - Applications, Modules, Operations, Roles, Rules, Tenants, and Catalog
+---
+
+import { Card, CardGrid, Aside, Tabs, TabItem } from '@astrojs/starlight/components';
+
+Understanding these core concepts is essential for working effectively with the Blue Alba Platform. These building blocks form the foundation of the platform's architecture and authorization system.
+
+## Platform Building Blocks
+
+<CardGrid stagger>
+  <Card title="Applications" icon="seti:folder">
+    Logical groupings of related functionality that users interact with. Examples: "Customer Portal", "Admin Console", "Analytics Dashboard".
+  </Card>
+
+  <Card title="Modules" icon="puzzle">
+    Deployable units of code - either a backend service or frontend UI. Modules belong to Applications and can be shared across them.
+  </Card>
+
+  <Card title="Operations" icon="approve-check">
+    The most granular level of permissions. Every action a user can perform (read, write, delete, approve) is an Operation.
+  </Card>
+
+  <Card title="Roles" icon="seti:config">
+    Collections of Operations that define what a user can do. Examples: "Admin", "Viewer", "Editor".
+  </Card>
+
+  <Card title="Rules" icon="seti:license">
+    Authorization logic that allows or denies Operations based on conditions. Rules implement business authorization logic.
+  </Card>
+
+  <Card title="Tenants" icon="codeberg">
+    Isolated instances of the platform for different customers or organizations. Each tenant has separate data, users, and configurations.
+  </Card>
+
+  <Card title="Catalog" icon="open-book">
+    Dynamic registry of Applications and Modules that enables runtime discovery and routing of services.
+  </Card>
+
+  <Card title="Platform Context" icon="seti:json">
+    Request-scoped information about the current tenant, user, and application being accessed.
+  </Card>
+</CardGrid>
+
+---
+
+## Applications
+
+**Applications** are the highest-level organizational concept in the platform. They represent logical groupings of functionality that make sense to end users.
+
+### What is an Application?
+
+An Application is:
+- A **named collection** of related features (e.g., "Customer Portal", "Administration")
+- A **logical grouping** of one or more Modules (UIs and services)
+- A **unit of access control** - users are granted access to Applications
+- An **entry point** in the navigation menu
+
+### Application Structure
+
+```typescript
+interface Application {
+  id: string;
+  name: string;               // Unique identifier (e.g., "admin-portal")
+  displayName: string;
+  description: string;
+  modules: Module[];          // Associated modules
+  allowedByDefault: boolean;  // Application visible to all users without manual assignment
+}
+```
+
+### Example Applications
+
+<Tabs>
+  <TabItem label="Administration">
+    **Application**: Platform Administration
+
+    **Purpose**: Manage users, roles, applications, and platform configuration
+
+    **Modules**:
+    - Admin UI (frontend)
+    - User Management Service (backend)
+    - Application Catalog Service (backend)
+  </TabItem>
+
+  <TabItem label="Customer Portal">
+    **Application**: Customer Self-Service Portal
+
+    **Purpose**: Allow customers to view orders, submit tickets, manage profile
+
+    **Modules**:
+    - Customer Portal UI (frontend)
+    - Orders Service (backend)
+    - Ticketing Service (backend)
+  </TabItem>
+
+  <TabItem label="Analytics">
+    **Application**: Analytics Dashboard
+
+    **Purpose**: View business metrics and reports
+
+    **Modules**:
+    - Analytics UI (frontend)
+    - Reporting Service (backend)
+  </TabItem>
+</Tabs>
+
+<Aside type="tip">
+  Think of Applications as the items you see in the main navigation menu. Each Application groups related features that users access together.
+</Aside>
+
+---
+
+## Modules
+
+**Modules** are the deployable units of code - the actual services and UIs that make up your platform.
+
+### What is a Module?
+
+A Module is:
+- A **deployable artifact** (a service or UI application)
+- Either a **backend service** (microservice) or **frontend UI** (micro-frontend)
+- A **registered entity** in the application catalog
+- A **route target** that the gateway can proxy to
+
+### Module Types
+
+There are six types of modules:
+
+**UI Modules** (Frontend) [app]
+- React-based micro-frontends
+- Loaded dynamically by the Shell UI
+- Built with `pae-ui-react-sdk`
+- Examples: Customer Portal UI, CRM UI
+
+**Tool Modules** (Frontend) [tool]
+- React-based micro-frontends that provide platform utilities and administration features
+- Appear in the navbar tools section rather than the application selector
+- Built with `pae-ui-react-sdk`
+- Examples: Admin UI, Documentation UI
+
+**Service Modules** (Backend) [service]
+- NestJS or Express-based microservices
+- Registered with the gateway
+- Handle business logic and data persistence
+- Examples: Habits Service, Scheduler Service
+
+**Utility** (Frontend) [utility]
+- React-based micro-frontends
+- It is loaded by the browser but is not mounted on a DOM element.
+- Provides reusable elements such as components, styles, and utility functions.
+- Examples: pae-ui-react-core
+
+**Cloud Function** (Backend) [cloud-function]
+- Support for running serverless functions
+
+**Documentation Modules** (Documentation) [documentation]
+- Documentation sites created using the [Blue Alba Platform Documentation Template](/_/docs/guides/adding-documentation-sites/).
+
+### Module Structure
+
+```typescript
+interface Module {
+  name: string;              // Unique identifier
+  displayName: string;
+  description: string;
+  type: 'app' | 'tool' | 'service' | 'utility' | 'cloud-function' | 'documentation';    // Module type
+  
+  applicationId: string;     // Parent application
+  baseUrl: string;
+  host: string;
+  port: number;
+
+  dependsOn: string[];
+
+  // Only for 'app' and 'tool' types
+  ui: {
+    "route": string;
+    "mountAtSelector": "#pae-shell-ui-content",
+    "bundleFile": string;   // file path
+    "customProps": {}
+  }
+
+  authorization: {
+    "operations": string[];
+    "routes": {}
+  }
+
+}
+```
+
+### Module Registration
+
+Modules register themselves with the gateway's catalog on startup:
+
+<Tabs>
+  <TabItem label="Service Module">
+    ```typescript
+    // In a backend service
+    const module = {
+      code: 'habits-service',
+      name: 'Habits Tracking Service',
+      type: 'SERVICE',
+      applicationId: 'habits-app',
+      serviceUrl: 'http://pae-habits-service:4002',
+      routes: [
+        { path: '/habits', method: 'GET' },
+        { path: '/habits/:id', method: 'GET' },
+        { path: '/habits', method: 'POST' }
+      ]
+    };
+
+    // Register with catalog
+    await catalogClient.registerModule(module);
+    ```
+  </TabItem>
+
+  <TabItem label="UI Module">
+    ```typescript
+    // In a frontend UI
+    const module = {
+      code: 'habits-ui',
+      name: 'Habits UI',
+      type: 'UI',
+      applicationId: 'habits-app',
+      entryPoint: 'http://localhost:8081/main.js',
+      containerElement: '#habits-app-container'
+    };
+
+    // Register with catalog
+    await catalogClient.registerModule(module);
+    ```
+  </TabItem>
+
+  <TabItem label="Documentation Module">
+    ```typescript
+    // In a documentation service
+    const module = {
+      code: 'app-documentation',
+      name: 'App Documentation',
+      type: 'DOCUMENTATION',
+      applicationId: 'app-documentation',
+      baseUrl: '/app/docs',
+      routes: [
+        { path: '/habits', method: 'GET' },
+        { path: '/habits/:id', method: 'GET' },
+        { path: '/habits', method: 'POST' }
+      ],
+      service: {
+        host: "pae-sandbox-documentation",
+        port: 80
+      },
+      dependsOn: [
+        "@bluealba/pae-shell-ui"
+      ]
+    };
+
+    // Register with catalog
+    await catalogClient.registerModule(module);
+    ```
+  </TabItem>
+</Tabs>
+
+---
+
+## Operations
+
+**Operations** represent the most granular level of permissions in the platform. Every action that requires authorization is an Operation.
+
+### What is an Operation?
+
+An Operation is:
+- A **specific permission** (e.g., "users.read", "orders.create", "reports.delete")
+- The **smallest unit** of authorization
+- A **building block** for Roles
+- Typically **verb-based** (read, write, update, delete, approve, etc.)
+
+### Operation Naming Convention
+
+Operations follow a hierarchical naming pattern using double colons (::):
+
+```
+{domain}::{resource}::{action}[.{modifier}]
+
+#### Structure
+
+- **domain**: Functional area of the system (e.g., authorization, authentication, documentation)
+- **resource**: Specific entity within the domain (e.g., role, auth-methods, impersonation)
+- **action**: Operation to perform (e.g., delete, manage, read, config)
+- **modifier (optional)**: Additional qualifier to specify scope or context
+
+Examples:
+- `authorization::role::delete` - Delete roles from the authorization system
+- `authorization::role::manage-operations` - Manage operations assigned to specific roles
+- `documentation::access` - Access system documentation
+
+### Operation Structure
+
+```typescript
+interface Operation {
+  id: string;
+  name: string;              // e.g., "users::read"
+  description: string;
+  applicationId: string;     // Which app this belongs to
+}
+```
+
+### Using Operations in Code
+
+Operations are checked throughout the platform:
+
+<Tabs>
+  <TabItem label="Frontend (React)">
+    ```typescript
+    import { useAuth } from '@bluealba/pae-ui-react-core';
+
+    function UserManagement() {
+      const { hasAccess } = useAuth();
+
+      const canRead = hasAccess('users.read');
+      const canWrite = hasAccess('users.write');
+      const canDelete = hasAccess('users.delete');
+
+      return (
+        <div>
+          {canRead && <UserList />}
+          {canWrite && <CreateUserButton />}
+          {canDelete && <DeleteUserButton />}
+        </div>
+      );
+    }
+    ```
+  </TabItem>
+</Tabs>
+
+<Aside>
+  **Best Practice**: Define Operations at a granular level. It's easier to combine fine-grained Operations into Roles than to split coarse-grained ones later.
+</Aside>
+
+---
+
+## Roles
+
+**Roles** are collections of Operations that define what a user can do in the system.
+
+### What is a Role?
+
+A Role is:
+- A **named collection** of Operations
+- A **permission set** assigned to users
+- A **template** for common access patterns
+- **Reusable** across different users and groups
+
+### Role Structure
+
+```typescript
+interface Role {
+  id: string;
+  name: string;              // e.g., "admin", "viewer"
+  description: string;
+  applicationId: string;     // Which app this role applies to
+  operations: Operation[];   // Granted operations
+}
+```
+
+### Common Role Patterns
+
+<CardGrid>
+  <Card title="Admin Role" icon="star">
+    **Operations**: All operations for an application
+
+    **Use Case**: System administrators who need full access
+
+    **Example**:
+    - `users::*` (all user operations)
+    - `orders::*` (all order operations)
+    - `settings::*` (all settings operations)
+  </Card>
+
+  <Card title="Viewer Role" icon="open-book">
+    **Operations**: Only read operations
+
+    **Use Case**: Users who need to view data but not modify it
+
+    **Example**:
+    - `users::read`
+    - `orders::read`
+    - `reports::read`
+  </Card>
+
+  <Card title="Editor Role" icon="pencil">
+    **Operations**: Read and write operations (but not delete)
+
+    **Use Case**: Users who can create and update data
+
+    **Example**:
+    - `users::read`
+    - `users::write`
+    - `orders::read`
+    - `orders::write`
+  </Card>
+
+  <Card title="Custom Role" icon="setting">
+    **Operations**: Specific subset for business needs
+
+    **Use Case**: Specialized roles for unique workflows
+
+    **Example** (Approver):
+    - `orders::read`
+    - `orders::approve`
+    - `orders::reject`
+  </Card>
+</CardGrid>
+
+### Role Assignment
+
+Users receive Roles in two ways:
+
+1. **Direct Assignment**: Role assigned directly to a user
+2. **Group Membership**: User belongs to a Group that has the Role
+
+```typescript
+// Direct role assignment
+await userService.assignRole(userId, roleId);
+
+// Group-based assignment
+await groupService.addMember(groupId, userId);
+// User automatically gets all roles assigned to the group
+```
+
+<Aside type="tip">
+  **Best Practice**: Use Groups for role assignment rather than direct assignment. This makes managing permissions for many users much easier.
+</Aside>
+
+---
+
+## Rules
+
+**Rules** are the mechanism that connects authorization concepts together by associating **Resources** with **Subjects**.
+
+### What is a Rule?
+
+A Rule is:
+- The **association** between a Resource and a Subject
+- A **grant or deny** decision for access
+- The **building block** of the authorization system
+- How the platform determines **who can access what**
+
+### Key Concepts
+
+#### Resources
+
+A **Resource** is anything that can be protected by authorization. In the platform, there are three types of Resources:
+
+<CardGrid>
+  <Card title="Operations" icon="approve-check">
+    The most granular resource - a specific permission or action (e.g., `users::read`, `orders::delete`)
+  </Card>
+
+  <Card title="Roles" icon="seti:config">
+    A collection of Operations grouped together (e.g., "admin", "viewer")
+  </Card>
+
+  <Card title="Applications" icon="seti:folder">
+    A logical grouping of functionality (e.g., "platform", "customer-portal")
+  </Card>
+</CardGrid>
+
+<Aside type="note">
+You can grant or deny access to any of these three resource types: **Operations**, **Roles**, or **Applications**.
+</Aside>
+
+#### Subjects
+
+A **Subject** is the target to which access is granted or denied. There are two types of Subjects:
+
+<Tabs>
+  <TabItem label="User">
+    **User**: A specific individual identified by the Identity Provider
+
+    ```json
+    {
+      "subjectType": "user",
+      "subject": "john.doe@company.com",
+      "resourceType": "operation",
+      "resource": "orders::read",
+      "denied": false
+    }
+    ```
+
+    The `subject` field contains the user's identifier (typically their email from the Identity Provider).
+
+    **Use Case**: Give John Doe access to read orders
+  </TabItem>
+
+  <TabItem label="Group">
+    **Group**: Users belonging to a group from the Identity Provider
+
+    ```json
+    {
+      "subjectType": "group",
+      "subject": "sales-team",
+      "resourceType": "application",
+      "resource": "reports-app",
+      "denied": false
+    }
+    ```
+
+    The `subject` field contains the group identifier from the Identity Provider.
+
+    **Use Case**: Give all members of the Sales Team group access to the Reports application
+  </TabItem>
+</Tabs>
+
+### Rule Structure
+
+A Rule has the following structure:
+
+```typescript
+interface Rule {
+  // Subject: Who is this rule for?
+  subjectType: 'user' | 'group';
+  subject: string;              // User email or group identifier
+
+  // Resource: What are they getting access to?
+  resourceType: 'operation' | 'role' | 'application';
+  resource: string;             // Resource identifier
+
+  // Effect: Grant or deny?
+  denied: boolean;              // false = ALLOW, true = DENY
+
+  // Tenant scope
+  tenantId?: number;            // null = global (applies to all tenants)
+}
+```
+
+**Field Descriptions:**
+
+| Field | Type | Description | Example |
+|-------|------|-------------|---------|
+| `subjectType` | `"user"` \| `"group"` | Type of subject | `"user"` |
+| `subject` | `string` | User email or group name | `"juan.bruno@bluealba.com"` |
+| `resourceType` | `"operation"` \| `"role"` \| `"application"` | Type of resource | `"application"` |
+| `resource` | `string` | Resource identifier | `"platform"` |
+| `denied` | `boolean` | `false` = ALLOW, `true` = DENY | `false` |
+| `tenantId` | `number` \| `null` | Tenant scope. `null` = global (all tenants) | `1` |
+
+### Tenant-Scoped vs Global Rules
+
+Rules can be either **tenant-scoped** or **global**:
+
+- **Tenant-scoped** (`tenantId` is set): The rule only applies within that specific tenant. Rules created from the Admin UI are always scoped to the current tenant.
+- **Global** (`tenantId` is `null`): The rule applies across all tenants. In the Admin UI, these are displayed with a "Global" badge.
+
+<Aside type="note">
+  When deleting a global rule from the Admin UI, a confirmation dialog warns that the deletion will affect all tenants.
+</Aside>
+
+### How Rules Work
+
+Rules create associations between Subjects and Resources:
+
+```
+Subject + Resource + Effect = Rule
+
+Examples:
+- User "john@company.com" + Operation "orders::read" + ALLOW
+  → John can read orders
+
+- Group "admins" + Application "admin-portal" + ALLOW
+  → All admin group members can access Admin Portal
+
+- User "temp@company.com" + Role "admin" + DENY
+  → Temp user explicitly cannot have admin role (even if assigned)
+```
+
+### Rule Examples
+
+<Tabs>
+  <TabItem label="User → Operation">
+    **Grant a user access to a specific operation**
+
+    ```json
+    {
+      "subjectType": "user",
+      "subject": "developer@company.com",
+      "resourceType": "operation",
+      "resource": "users::delete",
+      "denied": false
+    }
+    ```
+
+    **Result**: User `developer@company.com` can delete users
+  </TabItem>
+
+  <TabItem label="Group → Application">
+    **Grant a group access to an application**
+
+    ```json
+    {
+      "subjectType": "group",
+      "subject": "engineering",
+      "resourceType": "application",
+      "resource": "developer-portal",
+      "denied": false
+    }
+    ```
+
+    **Result**: All users in the `engineering` group can access the Developer Portal
+  </TabItem>
+
+  <TabItem label="User → Role">
+    **Assign a role to a user**
+
+    ```json
+    {
+      "subjectType": "user",
+      "subject": "admin@company.com",
+      "resourceType": "role",
+      "resource": "platform-admin",
+      "denied": false
+    }
+    ```
+
+    **Result**: User `admin@company.com` gets the `platform-admin` role and all its operations
+  </TabItem>
+
+  <TabItem label="Deny Rule">
+    **Explicitly deny access**
+
+    ```json
+    {
+      "subjectType": "user",
+      "subject": "contractor@company.com",
+      "resourceType": "operation",
+      "resource": "sensitive::access",
+      "denied": true
+    }
+    ```
+
+    **Result**: User `contractor@company.com` cannot access sensitive data (even if their role grants it)
+  </TabItem>
+
+  <TabItem label="Group → Role">
+    **Assign a role to all members of a group**
+
+    ```json
+    {
+      "subjectType": "group",
+      "subject": "support-team",
+      "resourceType": "role",
+      "resource": "customer-support",
+      "denied": false
+    }
+    ```
+
+    **Result**: All users in the `support-team` group get the `customer-support` role
+  </TabItem>
+</Tabs>
+
+
+---
+
+## Tenants
+
+**Tenants** enable multi-tenancy - running a single instance of the platform for multiple customers or organizations with complete data isolation.
+
+### What is a Tenant?
+
+A Tenant is:
+- An **isolated instance** of the platform
+- A **customer or organization** using the platform
+- The **top-level data boundary** for all resources
+- A **context** that flows through every request
+
+### Tenant Structure
+
+```typescript
+interface Tenant {
+  id: string;
+  code: string;              // Unique identifier (e.g., "acme-corp")
+  name: string;              // Display name
+  status: 'ACTIVE' | 'SUSPENDED' | 'DELETED';
+
+  // Configuration
+  settings?: Record<string, any>;
+  branding?: {
+    logo?: string;
+    primaryColor?: string;
+    secondaryColor?: string;
+  };
+
+  // Subscription info
+  plan?: string;
+  subscriptionStartDate?: Date;
+  subscriptionEndDate?: Date;
+}
+```
+
+### Tenant Isolation
+
+Every resource in the platform belongs to a tenant:
+
+```typescript
+// Users belong to tenants
+interface User {
+  id: string;
+  tenantId: string;  // Isolates users by tenant
+  email: string;
+  // ...
+}
+
+// Data belongs to tenants
+interface Order {
+  id: string;
+  tenantId: string;  // Isolates orders by tenant
+  customerId: string;
+  // ...
+}
+```
+
+### Platform Context
+
+The **Platform Context** carries tenant information through every request:
+
+```typescript
+interface PlatformContext {
+  tenantId: string;           // Current tenant
+  userId: string;             // Current user
+  applicationId?: string;     // Current application
+  requestId: string;          // Trace ID
+}
+```
+
+The gateway extracts the tenant from:
+1. **JWT token** (for authenticated users)
+2. **API key** (for service-to-service calls)
+3. **Subdomain** (e.g., `acme.platform.com`)
+4. **Custom header** (for development)
+
+### Tenant Isolation in Practice
+
+<Tabs>
+  <TabItem label="Automatic (Recommended)">
+    Use the platform's built-in tenant context:
+
+    ```typescript
+    // Backend service
+    @Injectable()
+    export class OrdersService {
+      async findAll(@PlatformContext() ctx: PlatformContext) {
+        // Automatically filters by ctx.tenantId
+        return this.ordersRepository.find({
+          where: { tenantId: ctx.tenantId }
+        });
+      }
+    }
+    ```
+  </TabItem>
+
+  <TabItem label="Manual (Advanced)">
+    Explicitly handle tenant filtering:
+
+    ```typescript
+    @Injectable()
+    export class OrdersService {
+      async findAll(tenantId: string) {
+        // Manual tenant filtering
+        return this.ordersRepository.find({
+          where: { tenantId }
+        });
+      }
+    }
+    ```
+  </TabItem>
+</Tabs>
+
+<Aside type="caution" title="Critical">
+  **Always** filter data by `tenantId`. Failing to do so can expose data across tenant boundaries - a serious security issue.
+</Aside>
+
+---
+
+## Catalog
+
+The **Catalog** is the platform's dynamic registry of Applications and Modules.
+
+### What is the Catalog?
+
+The Catalog is:
+- A **service registry** that tracks all services and UIs
+- A **dynamic routing table** for the gateway
+- A **discovery mechanism** for micro-frontends
+- The **source of truth** for available applications
+
+### How the Catalog Works
+
+```mermaid
+graph LR
+    A[Service Starts] --> B[Register with Catalog]
+    B --> C[Catalog Stores Metadata]
+    C --> D[Gateway Queries Catalog]
+    D --> E[Gateway Routes Requests]
+```
+
+1. **Registration**: Services and UIs register on startup
+2. **Storage**: Catalog stores module metadata in database
+3. **Discovery**: Gateway queries catalog for routing
+4. **Routing**: Gateway proxies requests to appropriate service
+
+### Catalog API
+
+The catalog provides APIs for managing modules:
+
+```typescript
+// Register a module
+POST /catalog/modules
+{
+  "code": "habits-service",
+  "name": "Habits Service",
+  "type": "SERVICE",
+  "serviceUrl": "http://pae-habits-service:4002",
+  "routes": [...]
+}
+
+// Get all modules
+GET /catalog/modules
+
+// Get modules by application
+GET /catalog/applications/{appId}/modules
+
+// Unregister a module
+DELETE /catalog/modules/{moduleId}
+```
+
+### Benefits of the Catalog
+
+<CardGrid>
+  <Card title="Zero-Config Gateway" icon="setting">
+    Gateway doesn't need configuration files - it learns routes from the catalog
+  </Card>
+
+  <Card title="Flexible Deployment" icon="rocket">
+    Add, remove, or update services without redeploying the gateway
+  </Card>
+
+  <Card title="Health Tracking" icon="approve-check">
+    Catalog can track service health and availability
+  </Card>
+</CardGrid>
+
+---
+
+## Putting It All Together
+
+Here's how these concepts work together in a real scenario:
+
+### Example: User Views Their Orders
+
+1. **User** (belongs to **Tenant** "ACME Corp") logs in
+2. **Gateway** authenticates and extracts **Platform Context** (tenant, user)
+3. User navigates to the "Orders" **Application** in the Shell UI
+4. **Catalog** provides the Orders **Module** location to the Shell
+5. Shell loads the Orders UI **Module** (micro-frontend)
+6. User clicks "View My Orders"
+7. UI checks if user has `orders.read` **Operation** (they do via their **Role**)
+8. UI calls the Orders Service via the **Gateway**
+9. **Gateway** checks authorization:
+   - User has `orders.read` operation
+   - **Rules** evaluated: "allow read own orders" passes
+10. Gateway routes request to Orders **Service Module**
+11. Service queries database filtered by **Tenant** ID
+12. Orders returned to UI
+
+### Key Takeaways
+
+- **Applications** group related functionality
+- **Modules** are the deployable services and UIs
+- **Operations** are granular permissions
+- **Roles** collect Operations for assignment
+- **Rules** add conditional logic
+- **Tenants** provide multi-tenancy isolation
+
+## Next Steps
+
+Now that you understand the core concepts:
+
+1. **[Installation Guide](/_/docs/getting-started/installation/)** - Set up your development environment
+2. **[Development Workflow](/_/docs/getting-started/development-workflow/)** - Learn the day-to-day development process
+3. **[Architecture Deep Dive](/_/docs/architecture/overview/)** - Explore the technical architecture
+4. **[Authorization Guide](/_/docs/guides/authorization/)** - Master the authorization system