docs: record dedicated project Discord categories

2026-08-27 20:18:06 +00:00
parent 0a993fae46
commit 2dc80c16e2
9 changed files with 62 additions and 8 deletions
@@ -0,0 +1,47 @@
+---
+title: Dedicated Discord category per project
+---
+
+# Dedicated Discord category per project — 2026-08-27
+
+## Context
+
+All Corp v1 lifecycle channels previously shared the guild-level `corp-v1` category. As the pilot expanded across AeroSim, Maze Next Gen, and E-Shop v1, that flat topology made each project's working boundary harder to scan and increased the risk of mixing project-local channels with Board governance.
+
+## Decision
+
+RootAtSkic (`discord:1518725627845283888`) approved one dedicated top-level Discord category per Corp v1 project in Board message `1542625777495965836`.
+
+- Reserve `corp-v1` (`1537070242335821924`) for Board and shared governance channels.
+- Name each project category `corp-v1-<code>`.
+- Keep exactly seven lifecycle channels inside each project category in this order: General, Scope, Architecture, UI/UX, Kanban, Delivery, Releases.
+- Preserve existing channel IDs, history, topics, pins, webhooks, permission overwrites, and delivery targets during migration.
+- Apply the same topology to future kickoffs and delete only an empty project category during an approved sunset.
+
+## Implementation
+
+The central [`corp-v1--main`](https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1--main) skill was updated to version `4.3.0` and merged through PR [8](https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1--main/pulls/8) at `785e57d6381f60a0caacefdedec791aa3b1fe2fd`.
+
+Three categories were created with the existing approved permission-overwrite model:
+
+| Project | Category | Discord ID |
+|---|---|---|
+| AeroSim | `corp-v1-aerosim` | `1542627633123299359` |
+| Maze Next Gen | `corp-v1-mazeng` | `1542627645441839174` |
+| E-Shop v1 | `corp-v1-eshopv1` | `1542627655189270719` |
+
+The 21 existing lifecycle channels were moved by immutable channel ID. No project channel was recreated.
+
+## Verification
+
+A fresh full-guild readback confirmed:
+
+- every project category exists as a category and retains nine permission overwrites;
+- all seven exact channels for each project have the expected `parent_id` and lifecycle order;
+- all 21 channel IDs are unchanged and each channel retains nine permission overwrites;
+- the guild-level `corp-v1` category now contains only `corp-v1-board` and `corp-v1-guild`;
+- Hermes can still read recent history in every moved lifecycle channel.
+
+## Consequences
+
+Project navigation and the governance boundary are now explicit without losing history or changing channel-targeted integrations. Project records must include the dedicated category ID, and future provisioning must reject lifecycle channels placed directly under the governance category.