{"slug":"business/PARENT_REPOSITORIES_ROLES","title":"Parent Repositories & Operational Roles Specification","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/PARENT_REPOSITORIES_ROLES.mdx","bytes":9621,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nUnder our canonical **Customer Zero** operating mandate, we run the IntegrateWise engine to operate, monitor, and synchronize IntegrateWise itself.\n\nOur company runs as a network of **seven specialized repositories** in `/Users/nirmal/Github/`. This document defines the exact, immutable roles and operational boundaries of the ecosystem:\n\n```\n                  ┌──────────────────────────────┐\n                  │    IntegrateWise - Memory    │\n                  │   (Filesystem Memory Vault)  │\n                  └──────────────┬───────────────┘\n                                 │\n                     [IntegrateWise Folder Monitor] (Folder monitor)\n                                 │\n                                 ▼\n                  ┌──────────────────────────────┐\n                  │      integratewise-live      │ ──[feeds telemetry]──▶  integratewise-ops (Ops)\n                  │ (Unified View Surface Backend)│\n                  └──────────────┬───────────────┘\n                                 ├──────────────────────────────┐\n                                 ▼                              ▼\n                  ┌──────────────────────────────┐ ┌──────────────────────────────┐\n                  │  integratewise-business-...  │ │ org-mem.bookofprojects-...   │\n                  │ (BI Visual Cockpit - Chart)  │ │(CSM Success Cockpit - Con CS)│\n                  └──────────────────────────────┘ └──────────────────────────────┘\n                                                                │\n                                                       [publishes approved]\n                                                                │\n                                                                ▼\n                                                       integratewise-docs (Docs)\n```\n\n---\n\n## Shared Ecosystem Primitives & Repositories\n\n### 1. The Core Engine (The Backend Substrate)\n\n- **Repository**: `integratewise-live` (this repo)\n- **Role**: **The Unified View Surface Backend (Memory, Ingestion, Gateway)**\n- **Operational Mechanism**:\n  - Acts as the central engine, Normalizer pipeline, Spine DB PostgreSQL, and Cloudflare Edge databases (D1/KV/Queues).\n  - Serves as the single backend that powers all visual frontends/cockpits. Everything compiles and routes here.\n  - Handles authentications, processes S1-S8 normalizer stages, and exposes edge tables to frontend visual shells.\n\n---\n\n### 2. The Visual Cockpits (The View Surfaces)\n\n- **BI Cockpit (Chart)**:\n  - **Repository**: `integratewise-business-intelligence-hub` (aka `v0-realistic-design-main`)\n  - **Role**: **The Business Intelligence Visual System**\n  - **Operational Mechanism**: Surfaces executive/founder metrics, trendlines, and performance charts, backed strictly by `integratewise-live`.\n- **Customer Success Cockpit (Con Success / CSM Success)**:\n  - **Repository**: `org-mem.bookofprojects-integratewise`\n  - **Role**: **The Account Success / CSM Success Visual System**\n  - **Operational Mechanism**: Surfaces specialized account success views, personal/organizational memory projections, case studies, and corporate project records, backed by `integratewise-live`.\n\n---\n\n### 3. The Operations Telemetry (Ops)\n\n- **Repository**: `integratewise-ops`\n- **Role**: **The Operations Controller Board**\n- **Operational Mechanism**:\n  - Vue 3 dashboard command center used to monitor the live pipeline queues, Normalizer checkpoints, active signal caches, and quarantine logs.\n\n---\n\n### 4. Inbound File Ingestion & Filesystem Intelligence (Folder Monitor)\n\n- **Folder Monitor**:\n  - **Repository**: `IntegrateWise Folder Monitor`\n  - **Role**: **The Filesystem Intelligence Dashboard & Local Ingestion Monitor**\n  - **Operational Mechanism**:\n    - **Local Folder Watcher (Chokidar Daemon)**: Runs as a background daemon on the operational Mac/ops machine. It monitors `IntegrateWise - Memory` directories in real-time, capturing file modifications and streaming the payload chunks directly to `webhook-ingress` via HTTP POST.\n    - **Filesystem Intelligence Dashboard**: A static, single-page, vanilla JS dashboard (`index.html` + `app.js` with `IW_DATA` pre-built bundle) projecting the operational filesystem structure, department mapped folders (00-09 model), file explorer manifests, review queue lifecycles, and Mac system health/cleanup candidates.\n    - **Governance Rule**: To uphold our primary governance primitive (_the system proposes, humans approve_), the dashboard is strictly read-only, and all action buttons are permanently disabled with the label \"Approval required\".\n- **Memory Substrate**:\n  - **Repository**: `IntegrateWise - Memory`\n  - **Role**: **The Filesystem Vault Substrate**\n  - **Operational Mechanism**: Permanent, offline-first physical storage vault for organizational context, decisions, and system guidelines using markdown folder structures.\n\n---\n\n### 5. Document Publication (Docs)\n\n- **Repository**: `integratewise-docs`\n- **Role**: **The Brand Documentation Hub**\n- **Operational Mechanism**:\n  - Hosts public and internal documentation, which differ based on context.\n  - Wired to a sync pipeline: when a memory is published or promoted via governance inside **Ops / Governance**, the doc system automatically captures, sanitizes, and syncs the content.\n\n---\n\n## Governance & Action Boundaries\n\n**Governance** is the central workspace layer where **digital works** (approved mutations), **digital orders** (compiled Playbooks), and **folder monitor** statuses are made visible and manageable:\n\n- **Digital Works**: Proposals staged or approved by the Triage Bot scoring model. Staged items wait for human approval in the Governance Queue before committing.\n- **Digital Orders**: Step-by-step playbooks generated by the Twin and sent to local secure client CLI instances for execution, keeping server runtime footprints at zero.\n- **Folder Monitor Visibility**: Monitors active file-sync states and edge caches in real-time.\n\n---\n\n## The Core Substrate: User Workbench State Capture & Run Flow Loop\n\nUnder the **Customer Zero** operational model, the **User Workbench** (located inside the primary monorepo at `integratewise-live/apps/web`) acts as the active human-governed command membrane. Every single interactive change, curation task, threshold modification, setting toggle, or playbook activation made by the operator inside the workbench is captured in real-time and orchestrates the system's runtime flows:\n\n```\n                  ┌──────────────────────────────┐\n                  │   User Workbench Interface   │\n                  │  (apps/web/src/components)   │\n                  └──────────────────────────────┘\n                                 │\n                   [Direct spineClient Mutation]\n                                 │\n                                 ▼\n                  ┌──────────────────────────────┐\n                  │    Spine DB / Substrate      │ ──[Dual-Write]──▶  IntegrateWise - Memory\n                  │ (Authoritative SQL Fortress) │                     (Local Filesystem Vault)\n                  └──────────────────────────────┘\n                                 │\n                           [State Signal]\n                                 │\n                                 ▼\n                  ┌──────────────────────────────┐\n                  │    Twin & Signal Engines     │ ──[Handoff]────▶   Local Playbook Executon\n                  │  (Real-Time Cognitive Loops) │                     (Zero-Server footprint)\n                  └──────────────────────────────┘\n```\n\n### Operational Loop Lifecycle:\n\n1. **Workbench Mutation**: When the user changes settings (e.g., in the CSM settings-view), approves an organic memory promotion, or clicks \"Run\" on a playbook, the frontend client intercepts the action and executes a write operation through the abstracted `spineClient` layer.\n2. **State DB Hydration**: The update is committed securely to the authoritative **Spine DB**.\n3. **Core Memory Dual-Write**: The sync worker dual-writes the update directly back to the physical `IntegrateWise - Memory` markdown files, preserving permanent historical records.\n4. **Signal & Execution Flow**: The commit instantly triggers a `state-change` signal. The **Signal Engine** flags anomalies on the `integratewise-ops` telemetry board, the **Twin Engine** updates L2 cognitive overlays in the workbench, and the operator hands off compiled **Playbook JSONs** for execution inside the user's secure local environment.\n"}