fix(deploy): referentie-compose niet-runnable maken + dood fragment schrappen #106

Merged

janpeter merged 1 commit from fix/compose-reference-not-runnable into main

2026-07-11 07:20:01 +02:00

janpeter commented

2026-07-11 07:15:57 +02:00

Owner

Sluit de laatste container_name-footgun rond de compose-collision-check. Volgt op het 154-onderzoek van vandaag; raakt de live stack niet (nul downtime, geen deploy-oppervlak).

Wat er aan de hand was

deploy/compose/docker-compose.yml is een referentie-template van de srv-stack, maar droeg de echte live container_names (scrum4me-postgres, -caddy, -workers, -ops-dashboard) én de bind-mount naar /srv/scrum4me/postgres.

Twee onafhankelijke failure modes, en de name: scrum4me-srv uit 6e079dc dekt er maar één van:

	dekt `name:` dit af?
(a) projectnaam, afgeleid van de mapnaam (`compose/`)	✅ ja
(b) `container_name`, globaal uniek, los van het project	❌ nee — een `name:` reist mee met een kopie, de botsing niet

Bij (b) weigert Docker de create ("name already in use"), dus het faalt veilig — maar dat is toeval, niet ontwerp.

Wat deze PR doet

deploy/compose/docker-compose.yml → deploy/reference/scrum4me-stack.yml.tmpl. Uit een map die compose heet, en met een suffix die Compose niet vanzelf oppikt: het valt daarmee buiten docker compose auto-discovery én buiten de glob van check-compose-collision.sh. Wie het tóch wil gebruiken moet expliciet -f typen en loopt dan nog steeds tegen (b) aan — luid en veilig.
De name: en de container_names blijven staan: het is een getrouwe referentie van de live stack, dat is het punt ervan. Ze -ref maken zou de template laten liegen.
deploy/docker-compose.ops-dashboard.yml verwijderd — een fragment om handmatig in de stack te mergen, met build-context /srv/ops/repos/ops-dashboard die op geen van beide hosts nog bestaat. De ops-dashboard-service staat allang in de stack zelf.

Context: waarom max2 dit rood meldde

De scanner vlagde dit bestand daar als destructieve project-name collision. Dat bleek een stale deploy-clone: /srv/scrum4me/ops-dashboard op max2 liep 24 commits achter en miste dus 6e079dc. Na een pull is (a) daar weg. (b) bleef op beide hosts staan — dat is wat deze PR opruimt.

Op 154 is de scanner al clean (de siblings zijn gepind), en een rename van de live stack is daar afgeraden: Caddy proxiet vijf publieke vhosts naar 172.18.0.1:3000, de gateway van het compose-netwerk, en een netwerk-recreate kan dat subnet verschuiven.

Verificatie

YAML valideert; name: scrum4me-srv en alle zes services + container_names intact.
docker compose config kan de template op max2 niet renderen omdat hij naar /srv/scrum4me/secrets/mcp-http.env wijst — een 154-only pad. Dat bevestigt dat het 154's stack beschrijft en geen deploy-bron is.
Enige resterende verwijzing naar het oude pad is een historisch design-review (docs/superpowers/reviews/2026-05-28-…) dat het pad als bewijs citeert. Bewust niet aangepast: dat is een momentopname.

🤖 Generated with Claude Code

Sluit de laatste `container_name`-footgun rond de compose-collision-check. Volgt op het 154-onderzoek van vandaag; **raakt de live stack niet** (nul downtime, geen deploy-oppervlak). ## Wat er aan de hand was `deploy/compose/docker-compose.yml` is een referentie-template van de srv-stack, maar droeg de **echte live container_names** (`scrum4me-postgres`, `-caddy`, `-workers`, `-ops-dashboard`) én de bind-mount naar `/srv/scrum4me/postgres`. Twee onafhankelijke failure modes, en de `name: scrum4me-srv` uit 6e079dc dekt er maar één van: | | dekt `name:` dit af? | |---|---| | (a) projectnaam, afgeleid van de mapnaam (`compose/`) | ✅ ja | | (b) `container_name`, globaal uniek, los van het project | ❌ **nee** — een `name:` reist mee met een kopie, de botsing niet | Bij (b) weigert Docker de create ("name already in use"), dus het faalt veilig — maar dat is toeval, niet ontwerp. ## Wat deze PR doet - `deploy/compose/docker-compose.yml` → **`deploy/reference/scrum4me-stack.yml.tmpl`**. Uit een map die `compose` heet, en met een suffix die Compose niet vanzelf oppikt: het valt daarmee buiten `docker compose` auto-discovery én buiten de glob van `check-compose-collision.sh`. Wie het tóch wil gebruiken moet expliciet `-f` typen en loopt dan nog steeds tegen (b) aan — luid en veilig. - De `name:` en de container_names **blijven staan**: het is een getrouwe referentie van de live stack, dat is het punt ervan. Ze `-ref` maken zou de template laten liegen. - `deploy/docker-compose.ops-dashboard.yml` **verwijderd** — een fragment om handmatig in de stack te mergen, met build-context `/srv/ops/repos/ops-dashboard` die op geen van beide hosts nog bestaat. De ops-dashboard-service staat allang in de stack zelf. ## Context: waarom max2 dit rood meldde De scanner vlagde dit bestand daar als **destructieve** project-name collision. Dat bleek een **stale deploy-clone**: `/srv/scrum4me/ops-dashboard` op max2 liep 24 commits achter en miste dus 6e079dc. Na een pull is (a) daar weg. (b) bleef op beide hosts staan — dat is wat deze PR opruimt. Op 154 is de scanner al clean (de siblings zijn gepind), en een rename van de live stack is daar **afgeraden**: Caddy proxiet vijf publieke vhosts naar `172.18.0.1:3000`, de gateway van het compose-netwerk, en een netwerk-recreate kan dat subnet verschuiven. ## Verificatie - YAML valideert; `name: scrum4me-srv` en alle zes services + container_names intact. - `docker compose config` kan de template op max2 niet renderen omdat hij naar `/srv/scrum4me/secrets/mcp-http.env` wijst — een 154-only pad. Dat bevestigt dat het 154's stack beschrijft en geen deploy-bron is. - Enige resterende verwijzing naar het oude pad is een historisch design-review (`docs/superpowers/reviews/2026-05-28-…`) dat het pad als bewijs citeert. Bewust niet aangepast: dat is een momentopname. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

janpeter added 1 commit

2026-07-11 07:15:58 +02:00

fix(deploy): referentie-compose niet-runnable maken + dood fragment schrappen

CI / Root app checks (pull_request) Successful in 1m58s

Details

CI / Ops-agent checks (pull_request) Successful in 15s

Details

CI / Deploy artifact checks (pull_request) Successful in 12s

Details

CI / Docker image build (pull_request) Successful in 1m27s

Details

3edbd6810f

deploy/compose/docker-compose.yml -> deploy/reference/scrum4me-stack.yml.tmpl

Dit bestand is een referentie-template van de srv-stack; de live stack draait uit
/srv/scrum4me/compose/docker-compose.yml en geen enkele ops-agent-flow wijst
hierheen. Het droeg alleen wél de echte live container_names (scrum4me-postgres,
-caddy, -workers, -ops-dashboard) plus de bind-mount naar /srv/scrum4me/postgres.

Er zijn twee onafhankelijke manieren waarop zo'n kopie de live stack raakt, en de
`name: scrum4me-srv` die er sinds 6e079dc in staat dekt er maar één van af:

  (a) projectnaam — afgeleid van de mapnaam als `name:` ontbreekt. Gedekt.
  (b) container_name — globaal uniek, staat los van het project. Een `name:`
      reist gewoon mee met een kopie; de container_name-botsing verdwijnt daar
      niet door. Docker weigert de create ("name already in use"), dus het faalt
      veilig — maar dat is toeval, niet ontwerp.

Door het bestand uit een map te halen die `compose` heet en het een suffix te
geven die Compose niet vanzelf oppikt, is het geen deploy-oppervlak meer: het valt
buiten `docker compose` auto-discovery en buiten de glob van
check-compose-collision.sh. Wie het tóch wil gebruiken moet expliciet `-f` typen
en loopt dan nog steeds tegen (b) aan — luid en veilig. De container_names blijven
dus bewust staan: het is een getrouwe referentie, dat is het punt ervan.

Daarnaast: deploy/docker-compose.ops-dashboard.yml verwijderd. Dat was een
fragment om handmatig in de stack te mergen, met een build-context
(/srv/ops/repos/ops-dashboard) die op geen van beide hosts nog bestaat. De
ops-dashboard-service staat allang in de stack zelf.

Aanleiding: op max2 meldde check-compose-collision.sh dit bestand als destructieve
project-name collision. Dat bleek een stale deploy-clone (24 commits achter, dus
zonder 6e079dc). Na een pull is (a) daar weg, maar (b) bleef op beide hosts staan.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

janpeter merged commit c6d1861719 into main

2026-07-11 07:20:01 +02:00

janpeter referenced this pull request from a commit

2026-07-11 07:20:02 +02:00

Merge pull request 'fix(deploy): referentie-compose niet-runnable maken + dood fragment schrappen' (#106) from fix/compose-reference-not-runnable into main

janpeter referenced this pull request from a commit

2026-07-12 08:00:13 +02:00

docs(audit): verwijder stale fragment-instructie uit config-tabel (PR #106)