janpeter/scrum4me-mcp
1
0
Fork 0
Code Issues 7 Pull requests Projects Releases Packages Wiki Activity Actions

feat(pr-review): plan vinden over productgrenzen heen (ST-053) #186

Merged
janpeter merged 10 commits from feat/pr-review-cross-product into main 2026-10-04 21:21:28 +02:00
Conversation 1 Commits 10 Files changed 9 +1019 -66
janpeter commented 2026-10-04 21:14:39 +02:00
Owner
Copy link

Waarom

Na ST-052 (#183) vindt de PR-review een plan via de PR-beschrijving en via commits, maar alleen binnen het product van de review-job. Werk voor scrum4me-mcp, -docker of -workers dat in een Scrum4Me-sprint is gepland, kreeg zo nog geen plan. Een voorbeeld is T-1972 voor scrum4me-mcp#180.

Wat

Na routes 1–2 en A en B in het eigen product komen twee stappen. Die eerste stappen zelf zijn ongewijzigd en geven byte-gelijke output.

  • Kandidaatproducten (candidateProductIds): producten waarvan de job-eigenaar zelf eigenaar is, binnen de scope van het huidige token. Lidmaatschap telt bewust niet mee: anders kan andermans plan in een Forgejo-comment belanden.
  • A× — codes in andere producten (resolvePlanViaCrossProductRefs):
    • alleen codes die in het eigen product niet bestaan;
    • een unieke match wordt gebruikt (K1 = ja, besluit JP);
    • bij meerdere matches telt alleen de match met een signaal: een repo_url (https of SSH) die naar de repo van de PR wijst, of een PR-commit in de story_logs;
    • een PBI alleen bij een unieke match.
  • B× — commits in andere producten (resolvePlanViaCrossProductCommits).
  • Identiteit: over producten heen sleutelen stories en taken intern op id, omdat codes alleen per product uniek zijn.
  • Herkomst: het veld product op de story, en labels in references en omitted zoals T-1972 (Scrum4Me). De budgetreservering rekent met die labels.
  • SHA's worden per resolve hooguit één keer opgehaald (createResolveContext).
  • wait-for-job geeft user_id mee; zonder user_id is het gedrag exact dat van ST-052.
  • Prompts: noemen de herkomst.
  • Proef: draait elke PR met en zonder user_id, vergelijkt een hash van het resultaat en toont de koppelingen die alleen dankzij K1 bestaan.

Verificatie

  • npm test, inclusief typecheck:tests: 251 testbestanden en 2095 tests geslaagd. npm run typecheck is schoon.
  • Nieuwe testsuite __tests__/lib/pr-linked-plan-cross-product.test.ts, met een nep-database die Prisma's select respecteert.
  • RED-controle: met code- in plaats van id-sleutels falen de drie tests op het mengen van producten.
  • Proef op de echte database en Forgejo:
    • scrum4me-mcp#180 krijgt T-1972 (Scrum4Me) en scrum4me-docker#104 krijgt T-1973 (Scrum4Me);
    • over de 100 recentste PR's stijgt de dekking van 41 naar 71;
    • geen enkele PR met een plan in het eigen product kreeg een andere hash, en niets kwam boven het budget;
    • 5 koppelingen bestaan alleen dankzij K1.

Werk

ST-053 (T-163 t/m T-167), PBI-33, sprint S-2026-10-04-2 op product SC2. Plan met review record (dubbel GO na twee rondes): docs/superpowers/plans/2026-10-04-pr-review-cross-product.md.

Uitrol na merge: zoals ST-052. Op srv en max2 eerst pin_mcp_to_main, dan de codex-worker herbouwen.

🤖 Generated with Claude Code

## Waarom Na ST-052 (#183) vindt de PR-review een plan via de PR-beschrijving en via commits, maar alleen binnen het product van de review-job. Werk voor scrum4me-mcp, -docker of -workers dat in een Scrum4Me-sprint is gepland, kreeg zo nog geen plan. Een voorbeeld is T-1972 voor scrum4me-mcp#180. ## Wat Na routes 1–2 en A en B in het eigen product komen twee stappen. Die eerste stappen zelf zijn ongewijzigd en geven byte-gelijke output. - **Kandidaatproducten** (`candidateProductIds`): producten waarvan de job-eigenaar zelf eigenaar is, binnen de scope van het huidige token. Lidmaatschap telt bewust niet mee: anders kan andermans plan in een Forgejo-comment belanden. - **A× — codes in andere producten** (`resolvePlanViaCrossProductRefs`): - alleen codes die in het eigen product niet bestaan; - een unieke match wordt gebruikt (K1 = ja, besluit JP); - bij meerdere matches telt alleen de match met een signaal: een `repo_url` (https of SSH) die naar de repo van de PR wijst, of een PR-commit in de `story_logs`; - een PBI alleen bij een unieke match. - **B× — commits in andere producten** (`resolvePlanViaCrossProductCommits`). - **Identiteit:** over producten heen sleutelen stories en taken intern op id, omdat codes alleen per product uniek zijn. - **Herkomst:** het veld `product` op de story, en labels in `references` en `omitted` zoals `T-1972 (Scrum4Me)`. De budgetreservering rekent met die labels. - **SHA's** worden per resolve hooguit één keer opgehaald (`createResolveContext`). - `wait-for-job` geeft `user_id` mee; zonder `user_id` is het gedrag exact dat van ST-052. - **Prompts:** noemen de herkomst. - **Proef:** draait elke PR met en zonder `user_id`, vergelijkt een hash van het resultaat en toont de koppelingen die alleen dankzij K1 bestaan. ## Verificatie - `npm test`, inclusief `typecheck:tests`: 251 testbestanden en 2095 tests geslaagd. `npm run typecheck` is schoon. - Nieuwe testsuite `__tests__/lib/pr-linked-plan-cross-product.test.ts`, met een nep-database die Prisma's `select` respecteert. - RED-controle: met code- in plaats van id-sleutels falen de drie tests op het mengen van producten. - Proef op de echte database en Forgejo: - scrum4me-mcp#180 krijgt `T-1972 (Scrum4Me)` en scrum4me-docker#104 krijgt `T-1973 (Scrum4Me)`; - over de 100 recentste PR's stijgt de dekking van 41 naar 71; - geen enkele PR met een plan in het eigen product kreeg een andere hash, en niets kwam boven het budget; - 5 koppelingen bestaan alleen dankzij K1. ## Werk ST-053 (T-163 t/m T-167), PBI-33, sprint S-2026-10-04-2 op product SC2. Plan met review record (dubbel GO na twee rondes): `docs/superpowers/plans/2026-10-04-pr-review-cross-product.md`. **Uitrol na merge:** zoals ST-052. Op srv en max2 eerst `pin_mcp_to_main`, dan de codex-worker herbouwen. 🤖 Generated with [Claude Code](https://claude.com/claude-code) 
Vervolg op ST-052: werk voor mcp/docker/workers dat in een Scrum4Me-sprint
staat, krijgt nu geen plan. Meting op 100 PR's: dekking 41 -> ~71 met een
codezoektocht over toegankelijke producten (uniek of bevestigd via
repo_url/commit) en commits over productgrenzen.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Volgorde eigen product eerst (A, B) en pas dan A×/B×, interne identiteit op
id i.p.v. code, alleen eigen producten van de job-eigenaar, budgetreservering
met labels, token-scopetest, SSH-bewuste repo_url-vergelijking.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Voorbereiding op productoverschrijdend zoeken (ST-053):
- candidateProductIds: alleen producten waarvan de job-eigenaar eigenaar
  is (geen lidmaatschap, anders kan andermans plan in een Forgejo-comment
  belanden), binnen de scope van het huidige token.
- createResolveContext: de commit-SHA's van een PR worden per resolve
  hooguit één keer opgehaald.
- De assembler sleutelt intern op een key en toont een label; binnen het
  eigen product is beide de code, dus de output blijft byte-gelijk. Over
  producten heen wordt de key het id, omdat codes alleen per product uniek
  zijn. De budgetreservering rekent met de labels.
- wait-for-job geeft user_id mee.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Werk voor mcp/docker/workers dat in een Scrum4Me-sprint staat, kreeg geen
plan: de lookup zocht alleen binnen het product van de review-job. Na A en B
in het eigen product (ongewijzigd, die gaan altijd vóór) volgen nu:
- A×: codes uit de beschrijving die in het eigen product niet bestaan,
  gezocht in de eigen producten van de job-eigenaar. Uniek → gebruiken
  (K1 = ja, JP). Meerdere matches → alleen de match met een signaal
  (repo_url = repo van de PR, https of SSH, of een PR-commit in de
  story_logs). PBI's alleen bij een unieke match.
- B×: de PR-commits in diezelfde producten.

Stories en taken sleutelen hier op id, omdat codes alleen per product uniek
zijn; de output draagt de productnaam (veld product en labels in
references/omitted). Getest met een nep-database die select respecteert;
RED-controle: met code-sleutels falen de mengtests.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
De proef draait elke PR met en zonder user_id (= ST-052-gedrag) en print
alleen metadata: stap, verwijzingen, herkomst en een hash van het plan. Zo
is te zien dat PR's met een plan in het eigen product exact gelijk blijven.
Voor de A×-koppelingen die alleen dankzij K1 bestaan, draait de proef A× nog
eens met allowUnsignalledUnique=false (alleen voor de proef; productie volgt
de K1-constante).

Meting 100 PR's: plan 41 -> 71, 0 gewijzigde eigen-plannen, niets boven het
budget, 5 koppelingen zonder signaal.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat(pr-review): prompts noemen de herkomst van een plan uit een ander product
All checks were successful
CI / Final merge attestation and immutable publication (pull_request) Has been skipped
Details
CI / PR candidate (never published) (pull_request) Successful in 5m7s
Details
0953b5c57f 
Een plan dat via A× of B× uit een ander product komt, moet in de review
herkenbaar zijn, zodat een verkeerde koppeling opvalt.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
s4m-codex-reviewer reviewed 2026-10-04 21:21:11 +02:00
s4m-codex-reviewer left a comment
Copy link

COMMENT

De diff volgt het gekoppelde plan en de productstandaarden: A/B in het eigen product blijven vóór A×/B×; kandidaatproducten worden op eigenaar en tokenscope gefilterd; interne id-sleutels voorkomen vermenging van gelijke codes; herkomstlabels en budget worden meegenomen. Geen blokkerende code-, architectuur- of documentatiefinding gevonden.

Findings:

  • INFO — __tests__/packaged-release.test.ts:555 en __tests__/dispatch/git-lifecycle.test.ts:20: de volledige testgate kon in deze reviewomgeving niet groen worden bevestigd. De releasefixture faalt op een esbuild-versiemismatch (0.28.2 versus 0.27.7); de gitfixture mist het tracebestand. Dit zijn geen aangetoonde regressies van deze diff, maar beperken de onafhankelijke verificatie. Daarom safe-default COMMENT.

Verificatie op commit 0953b5c57fec19f99a366053b1fdb34fb77d3bec: beide TypeScript-configs slagen; alle zes relevante suites (resolver, cross-product, PR-referenties, PR-review-jobcontext en beide prompt-suites) slagen. De drie gewijzigde testsuites bevatten samen 54 geslaagde tests.

Plan gekoppeld via pbi. Het plan voor ST-053/PBI-33 is getoetst aan de diff en PR-beschrijving. Er zijn geen meegeleverde references of omitted. Uitrol en live-check zijn expliciet werk na merge en vormen hier geen blokkade. De architectuur-productdoc beschrijft de nieuwe routes en scope.

# COMMENT De diff volgt het gekoppelde plan en de productstandaarden: A/B in het eigen product blijven vóór A×/B×; kandidaatproducten worden op eigenaar en tokenscope gefilterd; interne id-sleutels voorkomen vermenging van gelijke codes; herkomstlabels en budget worden meegenomen. Geen blokkerende code-, architectuur- of documentatiefinding gevonden. Findings: - INFO — `__tests__/packaged-release.test.ts:555` en `__tests__/dispatch/git-lifecycle.test.ts:20`: de volledige testgate kon in deze reviewomgeving niet groen worden bevestigd. De releasefixture faalt op een esbuild-versiemismatch (0.28.2 versus 0.27.7); de gitfixture mist het tracebestand. Dit zijn geen aangetoonde regressies van deze diff, maar beperken de onafhankelijke verificatie. Daarom safe-default COMMENT. Verificatie op commit `0953b5c57fec19f99a366053b1fdb34fb77d3bec`: beide TypeScript-configs slagen; alle zes relevante suites (resolver, cross-product, PR-referenties, PR-review-jobcontext en beide prompt-suites) slagen. De drie gewijzigde testsuites bevatten samen 54 geslaagde tests. Plan gekoppeld via pbi. Het plan voor ST-053/PBI-33 is getoetst aan de diff en PR-beschrijving. Er zijn geen meegeleverde `references` of `omitted`. Uitrol en live-check zijn expliciet werk na merge en vormen hier geen blokkade. De architectuur-productdoc beschrijft de nieuwe routes en scope.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
severity/s2

   
severity/s3

   
severity/s4
No labels
severity/s2
severity/s3
severity/s4
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
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/scrum4me-mcp!186
No description provided.