chore(messages): verwijder queue-feature (verhuisd naar scrum4me-workers) #113

Merged

janpeter merged 5 commits from chore/remove-messages-feature into main 2026-07-18 10:01:00 +02:00

Conversation 3 Commits 5 Files changed 15 +8 -1441

janpeter commented 2026-07-18 09:43:01 +02:00

Owner

Copy link

Verwijdert de Messages-feature uit Ops-dashboard. De queue-berichtenfunctie leeft voortaan uitsluitend in scrum4me-workers /queue/messages.

Waarom

De berichtenqueue agent_message verhuist naar de scrum4me-DB. Ops-dashboard schrijft er nu op via zijn eigen Prisma-client op zijn eigen database — na de verhuizing zou die stil naar een verlaten tabel blijven schrijven: je stuurt een taak, hij verdwijnt, geen foutmelding. Prisma kan geen twee databases in één client, dus meeverhuizen kan niet.

Dit kan veilig omdat de opvolger er al is: scrum4me-workers #67 gaf /queue/messages volledige pariteit (push, cancel op pending én claimed, requeue, reply, delete, clear, previewPurge, purgeOlderThan) — méér dan deze pagina had (die kende geen reply en alleen mac/scrum4me-server × claude/codex, geen max2/jp).

Verwijderd

app/messages/, de drie app/api/messages/-routes (list, actions, SSE-stream), lib/agent-messages.ts, lib/agent-message-retention.ts, scripts/check-message-retention.ts + het npm-script check:messages, model AgentMessage uit het schema, de /messages-nav-entry, en de twee tests die volledig over de feature gaan (agent-messages.test.ts, messages-api.test.ts).

Bewust NIET aangeraakt

• lib/parse-worker-log.ts + zijn test — noemen agent_message alleen als item-type in een worker-logstroom (ander domein, 8 consumers onder app/worker-logs/). Blijft.
• De migratiemap 20260528233000_add_agent_message/ — historie.
• Geen migratie die de tabel dropt. Het model gaat uit het schema, maar agent_message blijft fysiek in de DB staan tot ná de cutover-observatieperiode. Schema-DB-drift is hier bewust en tijdelijk — Prisma zou hem bij een migrate dev zien, maar die draaien we niet.
• Drie historische docs die de feature noemen (plan, spec, review onder docs/superpowers/) — historie, buiten code-scope, ongemoeid.

Drie off-list opruimingen (geen dode verwijzing achtergelaten)

• scripts/tsconfig.json — de include noemde de drie verwijderde bestanden; die dode entries weg.
• test/session-expired-coverage.test.ts — een cross-cutting guard die van elk scherm session-expiry-bedrading eist, via een existsSync-assertie. Eén van de schermen was de verwijderde messages-view; alléén die entry is weg, de andere tien schermen blijven bewaakt (test 5/5 groen).
• Beide zijn minimaal: één regel elk, geen bestand verwijderd dat moest blijven.

Verificatie

• grep -rnE "agentMessage|agent_message|agent-message" app lib components prisma test scripts → alleen de toegestane uitzonderingen (parse-worker-log + migratie-SQL). Geen dode import repo-breed.
• grep -rn "/messages" app components → 0.
• npm run typecheck → 0 errors.
• npx vitest run → 30 files / 140 passed (nulmeting 32/163; −23 = de 2 verwijderde testbestanden, geen andere test omgevallen).
• npm run build → Compiled successfully; route-manifest bevat geen /messages of /api/messages.

Volgorde

Deze PR volgt op de nu-gemergde scrum4me-workers #67 (pariteit) en gaat vóór de data-cutover van agent_message naar de scrum4me-DB.

🤖 Generated with Claude Code

Verwijdert de Messages-feature uit Ops-dashboard. De queue-berichtenfunctie leeft voortaan uitsluitend in **scrum4me-workers** `/queue/messages`. ## Waarom De berichtenqueue `agent_message` verhuist naar de scrum4me-DB. Ops-dashboard schrijft er nu op via zijn **eigen Prisma-client op zijn eigen database** — na de verhuizing zou die stil naar een verlaten tabel blijven schrijven: je stuurt een taak, hij verdwijnt, geen foutmelding. Prisma kan geen twee databases in één client, dus meeverhuizen kan niet. Dit kan veilig omdat de opvolger er al is: [scrum4me-workers #67](https://git.jp-visser.nl/janpeter/scrum4me-workers/pulls/67) gaf `/queue/messages` volledige pariteit (push, cancel op pending én claimed, requeue, reply, delete, clear, previewPurge, purgeOlderThan) — méér dan deze pagina had (die kende geen reply en alleen `mac`/`scrum4me-server` × `claude`/`codex`, geen `max2`/`jp`). ## Verwijderd `app/messages/`, de drie `app/api/messages/`-routes (list, actions, SSE-stream), `lib/agent-messages.ts`, `lib/agent-message-retention.ts`, `scripts/check-message-retention.ts` + het npm-script `check:messages`, `model AgentMessage` uit het schema, de `/messages`-nav-entry, en de twee tests die volledig over de feature gaan (`agent-messages.test.ts`, `messages-api.test.ts`). ## Bewust NIET aangeraakt - **`lib/parse-worker-log.ts` + zijn test** — noemen `agent_message` alleen als item-type in een worker-logstroom (ander domein, 8 consumers onder `app/worker-logs/`). Blijft. - **De migratiemap `20260528233000_add_agent_message/`** — historie. - **Geen migratie die de tabel dropt.** Het model gaat uit het schema, maar `agent_message` blijft fysiek in de DB staan tot ná de cutover-observatieperiode. Schema-DB-drift is hier bewust en tijdelijk — Prisma zou hem bij een `migrate dev` zien, maar die draaien we niet. - **Drie historische docs** die de feature noemen (plan, spec, review onder `docs/superpowers/`) — historie, buiten code-scope, ongemoeid. ## Drie off-list opruimingen (geen dode verwijzing achtergelaten) - `scripts/tsconfig.json` — de `include` noemde de drie verwijderde bestanden; die dode entries weg. - `test/session-expired-coverage.test.ts` — een cross-cutting guard die van elk scherm session-expiry-bedrading eist, via een `existsSync`-assertie. Eén van de schermen was de verwijderde messages-view; alléén die entry is weg, de andere tien schermen blijven bewaakt (test 5/5 groen). - Beide zijn minimaal: één regel elk, geen bestand verwijderd dat moest blijven. ## Verificatie - `grep -rnE "agentMessage|agent_message|agent-message" app lib components prisma test scripts` → alleen de toegestane uitzonderingen (parse-worker-log + migratie-SQL). Geen dode import repo-breed. - `grep -rn "/messages" app components` → 0. - `npm run typecheck` → 0 errors. - `npx vitest run` → **30 files / 140 passed** (nulmeting 32/163; −23 = de 2 verwijderde testbestanden, geen andere test omgevallen). - `npm run build` → Compiled successfully; route-manifest bevat geen `/messages` of `/api/messages`. ## Volgorde Deze PR volgt op de nu-gemergde scrum4me-workers #67 (pariteit) en gaat vóór de data-cutover van `agent_message` naar de scrum4me-DB. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

janpeter added 4 commits 2026-07-18 09:43:01 +02:00

chore(messages): verwijder Messages-pagina en API-routes ... 49ef614a1b

De berichtenqueue-UI en -routes verhuizen naar scrum4me-workers /queue/messages, dat volledige pariteit heeft (push, cancel op pending/claimed, requeue, reply, delete, clear, previewPurge, purgeOlderThan). De agent_message-tabel verhuist naar de scrum4me-DB; Ops-dashboard zou anders naar een verlaten tabel blijven schrijven.

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

chore(messages): verwijder agent-messages lib en retention-script ... 1570345ed5

lib/agent-messages.ts + lib/agent-message-retention.ts (domein-helpers voor de queue) en scripts/check-message-retention.ts vervallen met de feature. Ook het npm-script check:messages en de bijbehorende include-entries in scripts/tsconfig.json (verwezen naar de verwijderde bestanden) zijn opgeschoond. De queue draait voortaan in scrum4me-workers.

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

chore(messages): verwijder AgentMessage-model en nav-entry ... 8395f9f64a

Model AgentMessage uit prisma/schema.prisma en de /messages nav-entry uit components/AppNav.tsx. Bewust GEEN drop-migratie: de agent_message-tabel blijft fysiek in de DB tot na de cutover-observatieperiode (tijdelijke, bedoelde schema-DB-drift). De historische migratie 20260528233000_add_agent_message blijft ongewijzigd.

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

test(messages): verwijder queue-tests en dode screen-entry ... 17538c5aef

test/agent-messages.test.ts en test/messages-api.test.ts gingen volledig over de verhuisde queue-feature. In test/session-expired-coverage.test.ts (een cross-cutting guard voor session-expiry-banner-wiring, geen queue-test) verviel enkel de SCREEN_FILES-entry voor de verwijderde messages-view; de guard voor de overige 10 schermen blijft intact.

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

s4m-codex-reviewer requested changes 2026-07-18 09:45:58 +02:00

Dismissed

s4m-codex-reviewer left a comment

Copy link

Verdict: REQUEST_CHANGES

Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden.

Findings

• blocking — prisma/schema.prisma:298 — De PR verwijdert het AgentMessage Prisma-model, maar de diff bevat geen Prisma-migratie en ook geen expliciete documentatie/ADR dat deze tabel voortaan buiten dit dashboard wordt beheerd door scrum4me-workers. Daardoor raakt schema.prisma uit sync met de migratiegeschiedenis: prisma migrate deploy zal de database niet aanpassen, nieuwe omgevingen kunnen een andere DB-vorm krijgen dan bestaande omgevingen, en toekomstige Prisma-migraties kunnen drift of onverwachte drops veroorzaken. Voeg een bewuste migratie toe, of laat het model/schema-eigenaarschap staan en documenteer dat alleen routes/UI/tests uit dit dashboard verdwijnen.

Samenvatting

De verwijdering is verder coherent op de zichtbare applicatielaag: routes, pagina/component, nav-link, helperlib, retentie-script en gerelateerde tests worden samen verwijderd. Door de ontbrekende database-migratie/eigenaarschapskeuze is dit nog niet veilig genoeg om goed te keuren.

# Verdict: REQUEST_CHANGES Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden. ## Findings - **blocking** — `prisma/schema.prisma:298` — De PR verwijdert het `AgentMessage` Prisma-model, maar de diff bevat geen Prisma-migratie en ook geen expliciete documentatie/ADR dat deze tabel voortaan buiten dit dashboard wordt beheerd door `scrum4me-workers`. Daardoor raakt `schema.prisma` uit sync met de migratiegeschiedenis: `prisma migrate deploy` zal de database niet aanpassen, nieuwe omgevingen kunnen een andere DB-vorm krijgen dan bestaande omgevingen, en toekomstige Prisma-migraties kunnen drift of onverwachte drops veroorzaken. Voeg een bewuste migratie toe, of laat het model/schema-eigenaarschap staan en documenteer dat alleen routes/UI/tests uit dit dashboard verdwijnen. ## Samenvatting De verwijdering is verder coherent op de zichtbare applicatielaag: routes, pagina/component, nav-link, helperlib, retentie-script en gerelateerde tests worden samen verwijderd. Door de ontbrekende database-migratie/eigenaarschapskeuze is dit nog niet veilig genoeg om goed te keuren.

janpeter referenced this pull request from a commit 2026-07-18 09:59:28 +02:00

revert(schema): herstel AgentMessage-model om schema-DB-drift te voorkomen

janpeter added 1 commit 2026-07-18 09:59:28 +02:00

revert(schema): herstel AgentMessage-model om schema-DB-drift te voorkomen ... 9a963763ec

De agent_message-tabel blijft fysiek in de ops_dashboard-DB tot na de cutover-observatieperiode (263 productieberichten). Het model uit schema.prisma halen terwijl de tabel blijft is drift: een latere `prisma migrate dev` zou dan een DROP TABLE agent_message genereren op live productiedata. Door schema en tabel gelijk te houden kan migrate dev geen drop genereren.

Het model is byte-identiek hersteld t.o.v. origin/main (f498600), inclusief de self-relations reply_to/replies, met een doc-comment die eigenaarschap en tijdelijkheid vastlegt. De feature zelf blijft verwijderd (routes, UI, lib, script, nav-entry, queue-tests) - verhuisd naar scrum4me-workers /queue/messages. De echte model-verwijdering + drop-migratie is een aparte opruimtaak na de cutover. Reageert op codex-review REQUEST_CHANGES op PR #113.

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

janpeter commented 2026-07-18 10:00:14 +02:00

Author

Owner

Copy link

Verwerkt in 9a96376 — je had gelijk, dank.

De blocking finding klopt: het AgentMessage-model verwijderen terwijl de tabel blijft, is schema-DB-drift, en dat draagt een reëel risico op de data. De aanpak is aangepast langs je optie (b): model teruggezet, eigenaarschap gedocumenteerd, alleen de applicatielaag verwijderd.

Waarom drift hier gevaarlijk is (ter bevestiging van je punt)

De achterliggende reden om de tabel te laten staan: agent_message verhuist naar een andere database (scrum4me), en de data moet daar eerst veilig staan vóór de tabel in ops_dashboard weg mag. Tot die cutover draagt de tabel productiedata. Met het model verwijderd zou een latere prisma migrate dev een DROP TABLE op die tabel genereren — precies het scenario dat je "onverwachte drops" noemt. Het model teruggezet houdt schema en tabel in sync, zodat migrate dev geen drop kán voorstellen. migrate deploy (de prod-pijplijn) was al veilig; het risico zat in migrate dev.

Wat er nu staat

• model AgentMessage is byte-identiek hersteld (incl. de reply_to/replies self-relations). De enige netto schema-wijziging t.o.v. main is een doc-comment die vastlegt: het model is ongebruikt in dit dashboard, blijft bewust staan tot na de cutover, en de echte verwijdering (model + drop-migratie) is een aparte opruim-taak wanneer de data in de scrum4me-DB staat. Dat is je "documenteer het schema-eigenaarschap"-alternatief.
• Alleen de applicatielaag blijft verwijderd: de drie app/api/messages/-routes, app/messages/, lib/agent-messages.ts, lib/agent-message-retention.ts, het retentie-script + npm-hook, de nav-link, en de twee feature-tests.
• Bewust ongemoeid: lib/parse-worker-log.ts (dat agent_message alleen als log-item-type kent, ander domein) en de migratiemap 20260528233000_add_agent_message (historie).

Verificatie

• git diff main..HEAD -- prisma/schema.prisma → alleen de doc-comment.
• npm run typecheck → 0 errors; npx vitest run → 30 files / 140 passed; npm run build → route-manifest zonder /messages.

De docs/superpowers/-plannen/spec/review die de feature nog beschrijven zijn als historie bewust ongemoeid gelaten, in lijn met de migratiemap. Zeg het als je die liever bijgewerkt ziet.

🤖 Generated with Claude Code

## Verwerkt in `9a96376` — je had gelijk, dank. De blocking finding klopt: het `AgentMessage`-model verwijderen terwijl de tabel blijft, is schema-DB-drift, en dat draagt een reëel risico op de data. De aanpak is aangepast langs je optie (b): **model teruggezet, eigenaarschap gedocumenteerd, alleen de applicatielaag verwijderd.** ### Waarom drift hier gevaarlijk is (ter bevestiging van je punt) De achterliggende reden om de tabel te laten staan: `agent_message` verhuist naar een andere database (scrum4me), en de data moet daar eerst veilig staan vóór de tabel in `ops_dashboard` weg mag. Tot die cutover draagt de tabel productiedata. Met het model verwijderd zou een latere `prisma migrate dev` een `DROP TABLE` op die tabel genereren — precies het scenario dat je "onverwachte drops" noemt. Het model teruggezet houdt schema en tabel in sync, zodat `migrate dev` geen drop kán voorstellen. `migrate deploy` (de prod-pijplijn) was al veilig; het risico zat in `migrate dev`. ### Wat er nu staat - `model AgentMessage` is **byte-identiek** hersteld (incl. de `reply_to`/`replies` self-relations). De enige netto schema-wijziging t.o.v. `main` is een doc-comment die vastlegt: het model is ongebruikt in dit dashboard, blijft bewust staan tot na de cutover, en de echte verwijdering (model + drop-migratie) is een aparte opruim-taak wanneer de data in de scrum4me-DB staat. Dat is je "documenteer het schema-eigenaarschap"-alternatief. - Alleen de applicatielaag blijft verwijderd: de drie `app/api/messages/`-routes, `app/messages/`, `lib/agent-messages.ts`, `lib/agent-message-retention.ts`, het retentie-script + npm-hook, de nav-link, en de twee feature-tests. - Bewust ongemoeid: `lib/parse-worker-log.ts` (dat `agent_message` alleen als log-item-type kent, ander domein) en de migratiemap `20260528233000_add_agent_message` (historie). ### Verificatie - `git diff main..HEAD -- prisma/schema.prisma` → alleen de doc-comment. - `npm run typecheck` → 0 errors; `npx vitest run` → 30 files / 140 passed; `npm run build` → route-manifest zonder `/messages`. De `docs/superpowers/`-plannen/spec/review die de feature nog beschrijven zijn als historie bewust ongemoeid gelaten, in lijn met de migratiemap. Zeg het als je die liever bijgewerkt ziet. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

s4m-codex-reviewer requested changes 2026-07-18 10:00:54 +02:00

s4m-codex-reviewer left a comment

Copy link

Verdict: REQUEST_CHANGES

Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden.

Findings

• blocker — app/messages/page.tsx:1: de PR verwijdert de volledige /messages pagina, terwijl de actieve productdoc Messages retentie en job-cancel /messages expliciet als gedeelde UI voor agent_message vastlegt met cancel/requeue en retentie-acties. In deze diff staat geen vervangende dashboard-surface, redirect, migratiepad of productdoc-update die dit contract wijzigt.
• blocker — app/api/messages/actions/route.ts:1: het verwijderen van /api/messages/actions haalt de gedocumenteerde handmatige cleanup en actieve job-cancel/requeue API weg. De productdocs vereisen juist server-side domain helpers en deze route voor previewPurgeOlderThan, purgeOlderThan en verbeterde cancel; de PR verwijdert ook de bijbehorende tests en check:messages, waardoor de destructieve retentie-SQL niet meer geborgd is.

Opmerking

De PR-titel zegt dat de queue-feature naar scrum4me-workers is verhuisd, maar de diff bevat geen bewijs in deze repository dat de Ops Dashboard-verantwoordelijkheid en gebruikersworkflow correct zijn overgedragen. Safe-default: niet approven zolang productdocs en dashboardcontract dit nog als actieve functionaliteit beschrijven.

# Verdict: REQUEST_CHANGES Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden. ## Findings - blocker — `app/messages/page.tsx:1`: de PR verwijdert de volledige `/messages` pagina, terwijl de actieve productdoc `Messages retentie en job-cancel` `/messages` expliciet als gedeelde UI voor `agent_message` vastlegt met cancel/requeue en retentie-acties. In deze diff staat geen vervangende dashboard-surface, redirect, migratiepad of productdoc-update die dit contract wijzigt. - blocker — `app/api/messages/actions/route.ts:1`: het verwijderen van `/api/messages/actions` haalt de gedocumenteerde handmatige cleanup en actieve job-cancel/requeue API weg. De productdocs vereisen juist server-side domain helpers en deze route voor `previewPurgeOlderThan`, `purgeOlderThan` en verbeterde `cancel`; de PR verwijdert ook de bijbehorende tests en `check:messages`, waardoor de destructieve retentie-SQL niet meer geborgd is. ## Opmerking De PR-titel zegt dat de queue-feature naar `scrum4me-workers` is verhuisd, maar de diff bevat geen bewijs in deze repository dat de Ops Dashboard-verantwoordelijkheid en gebruikersworkflow correct zijn overgedragen. Safe-default: niet approven zolang productdocs en dashboardcontract dit nog als actieve functionaliteit beschrijven.

janpeter merged commit 2ed2fc4499 into main 2026-07-18 10:01:00 +02:00

janpeter referenced this pull request from a commit 2026-07-18 10:01:01 +02:00

Merge pull request 'chore(messages): verwijder queue-feature (verhuisd naar scrum4me-workers)' (#113) from chore/remove-messages-feature into main

Sign in to join this conversation.

Reviewers

No reviewers

s4m-codex-reviewer

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

janpeter/Ops-dashboard!113

No description provided.