rename(phase 1): CapaKraken → Nexus across code, UI, docs, CI (#61)
CI / Architecture Guardrails (push) Successful in 2m38s
CI / Assistant Split Regression (push) Successful in 3m33s
CI / Typecheck (push) Successful in 3m51s
CI / Lint (push) Successful in 5m2s
CI / E2E Tests (push) Has been cancelled
CI / Fresh-Linux Docker Deploy (push) Has been cancelled
CI / Release Images (push) Has been cancelled
CI / Build (push) Has been cancelled
CI / Unit Tests (push) Has been cancelled

rename(phase 1): CapaKraken → Nexus across code, UI, docs, CI (#61)

Co-authored-by: Hartmut Nörenberg <hn@hartmut-noerenberg.com>
Co-committed-by: Hartmut Nörenberg <hn@hartmut-noerenberg.com>
This commit was merged in pull request #61.
This commit is contained in:
2026-05-21 16:28:40 +02:00
committed by Hartmut
parent d9a7ec0338
commit b41c1d2501
943 changed files with 24548 additions and 16832 deletions
+17 -17
View File
@@ -2,7 +2,7 @@
## Goal
This document describes the canonical release path for CapaKraken.
This document describes the canonical release path for Nexus.
The release model is now:
@@ -16,7 +16,7 @@ The release model is now:
### 1. Pull Request Validation
The main [ci.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/ci.yml) workflow remains the merge gate for:
The main [ci.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/ci.yml) workflow remains the merge gate for:
- architecture guardrails
- typecheck
@@ -27,26 +27,26 @@ The main [ci.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/c
### 2. Automatic Image Release
[release-image.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/release-image.yml) now runs automatically on every push to `main` and can still be started manually for rebuilds or tag overrides.
[release-image.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/release-image.yml) now runs automatically on every push to `main` and can still be started manually for rebuilds or tag overrides.
It publishes two images from [Dockerfile.prod](/home/hartmut/Documents/Copilot/capakraken/Dockerfile.prod):
It publishes two images from [Dockerfile.prod](/home/hartmut/Documents/Copilot/nexus/Dockerfile.prod):
- `ghcr.io/<owner>/<repo>-app:sha-<commit>`
- `ghcr.io/<owner>/<repo>-migrator:sha-<commit>`
### 3. Staging Promotion
[deploy-staging.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/deploy-staging.yml) copies the canonical deploy bundle to the staging host:
[deploy-staging.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/deploy-staging.yml) copies the canonical deploy bundle to the staging host:
- [docker-compose.prod.yml](/home/hartmut/Documents/Copilot/capakraken/docker-compose.prod.yml)
- [tooling/deploy/deploy-compose.sh](/home/hartmut/Documents/Copilot/capakraken/tooling/deploy/deploy-compose.sh)
- the rest of [tooling/deploy](/home/hartmut/Documents/Copilot/capakraken/tooling/deploy/README.md)
- [docker-compose.prod.yml](/home/hartmut/Documents/Copilot/nexus/docker-compose.prod.yml)
- [tooling/deploy/deploy-compose.sh](/home/hartmut/Documents/Copilot/nexus/tooling/deploy/deploy-compose.sh)
- the rest of [tooling/deploy](/home/hartmut/Documents/Copilot/nexus/tooling/deploy/README.md)
GitHub Actions also writes a short-lived `deploy.env` containing `APP_IMAGE`, `MIGRATOR_IMAGE`, and the host port.
### 4. Host-Side Deployment
On the target host, [deploy-compose.sh](/home/hartmut/Documents/Copilot/capakraken/tooling/deploy/deploy-compose.sh):
On the target host, [deploy-compose.sh](/home/hartmut/Documents/Copilot/nexus/tooling/deploy/deploy-compose.sh):
1. loads `.env.production` and `deploy.env`
2. validates the rendered compose file
@@ -60,7 +60,7 @@ The host does not build application code from Git anymore.
### 5. Production Promotion
[deploy-prod.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/deploy-prod.yml) repeats the exact staging flow with the same image tag after staging acceptance.
[deploy-prod.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/deploy-prod.yml) repeats the exact staging flow with the same image tag after staging acceptance.
That keeps staging and production on the same artifact instead of rebuilding.
@@ -88,13 +88,13 @@ That keeps staging and production on the same artifact instead of rebuilding.
The canonical host-side inputs are:
- [docker-compose.prod.yml](/home/hartmut/Documents/Copilot/capakraken/docker-compose.prod.yml)
- [docker-compose.prod.yml](/home/hartmut/Documents/Copilot/nexus/docker-compose.prod.yml)
- `.env.production`
- `deploy.env`
`.env.production` holds long-lived runtime configuration and secrets. The example file is [tooling/deploy/.env.production.example](/home/hartmut/Documents/Copilot/capakraken/tooling/deploy/.env.production.example).
`.env.production` holds long-lived runtime configuration and secrets. The example file is [tooling/deploy/.env.production.example](/home/hartmut/Documents/Copilot/nexus/tooling/deploy/.env.production.example).
`deploy.env` is short-lived deployment metadata. The example file is [tooling/deploy/deploy.env.example](/home/hartmut/Documents/Copilot/capakraken/tooling/deploy/deploy.env.example).
`deploy.env` is short-lived deployment metadata. The example file is [tooling/deploy/deploy.env.example](/home/hartmut/Documents/Copilot/nexus/tooling/deploy/deploy.env.example).
Important invariants:
@@ -107,7 +107,7 @@ Important invariants:
Release environments must run migrations through the `migrator` image, which executes:
```bash
pnpm --filter @capakraken/db db:migrate:deploy
pnpm --filter @nexus/db db:migrate:deploy
```
`db:push` remains a local-development tool, not a production rollout mechanism.
@@ -127,9 +127,9 @@ This assumes schema changes follow backwards-compatible expand-and-contract roll
The standard production update is:
1. merge to `main` after CI is green
2. let [release-image.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/release-image.yml) publish `sha-<commit>` images
3. deploy that tag to staging through [deploy-staging.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/deploy-staging.yml)
2. let [release-image.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/release-image.yml) publish `sha-<commit>` images
3. deploy that tag to staging through [deploy-staging.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/deploy-staging.yml)
4. validate staging
5. promote the same tag through [deploy-prod.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/deploy-prod.yml)
5. promote the same tag through [deploy-prod.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/deploy-prod.yml)
The important property is artifact identity: staging and production run the same image, not two separate builds.