Skip to content

🗂️ Project Management & Repository Taxonomy

At Apollyon, we maintain a strict boundary between writing code, storing assets, and managing tasks. To prevent data sprawl and protect our Intellectual Property (IP), we adhere to a rigid organizational structure within our self-hosted infrastructure.

The Three-Tier Rule

  • The Wiki (Docs-as-Code): For static processes, standards, and architecture (The "How").
  • Nextcloud: For heavy assets, PDFs, and legal documents (The "What").
  • GitLab: For active code, version control, and task tracking (The "When & Who").

1. The Root Boundary (Absolute Isolation)

Because our bare-metal server is a multi-tenant environment, GitLab is divided into two entirely separate Root Groups. This ensures zero cross-contamination between business assets and sandbox environments.

  • Root Group 1: Apollyon (Strictly business, Korvy IP, and client deliverables).
  • Root Group 2: Home-Ops (Strictly personal server infrastructure and sandbox media).

2. The Apollyon Hierarchy

Inside the Apollyon Root Group, the company is segmented by operational focus using Subgroups. Do not create repositories in your personal user namespace (e.g., gitlab/.../pedro/repo); all work must live within this taxonomy.

📂 Apollyon (Root Group)

  • 📁 Korvy (Subgroup: Core Intellectual Property)

    • korvy-frontend (Kotlin Multiplatform UI)
    • korvy-backend (FastAPI & PostgreSQL API)
    • korvy-hardware (ESP32 telemetry and node designs)

  • 📁 Clients (Subgroup: Client Deliverables)

    • gsalud-frontend (Dentistry clinic SPA)
    • (New clients receive their own isolated repositories here)

  • 📁 Internal (Subgroup: Company Operations)

    • apollyon-website (The public React/Vite landing page)
    • handbook (This MkDocs repository)

  • 📁 Infrastructure (Subgroup: Server Configurations)

    • apollyon-deployments (The centralized monorepo holding all production docker-compose.yml files, reverse proxy rules, and deployment scripts)

3. Issue Boards & Task Tracking

We do not use external CRMs or generic to-do apps for engineering tasks. All project management happens within GitLab Issue Boards.

  • Board Location: Issue Boards are maintained at the Subgroup level, not the repository level.
    • Example: The Korvy subgroup board displays tasks for both the frontend and backend simultaneously, allowing project managers to track the entire ecosystem in one unified Kanban view.
  • Workflow Columns: Issues flow strictly from left to right: Backlog ➡️ To Do ➡️ In Progress ➡️ Review/QA ➡️ Closed.

4. The Access Control & Permission Matrix

GitLab permissions cascade downwards. By strictly adhering to the hierarchy above, our access control becomes a highly secure, set-it-and-forget-it system.

Role / Identity Assignment Level Access Scope
Founders / CTO Owner at the Apollyon Root Group. Automatically inherits full control over everything beneath it, including CI/CD variables and Runner management.
Internal Hires Guest at Root Group, Developer on specific Subgroups. Can read the global handbook and view global issue boards, but can only push code to their assigned subgroup (e.g., Korvy).
Agency / Freelancers Developer strictly on a Specific Repository. Isolated access. A contractor hired for gsalud-frontend has zero visibility into the Korvy subgroup or Infrastructure deployments.