feat(product-docs): cap naar 250K + splits-instructie in de terugmelding #111

Merged
janpeter merged 1 commit from feat/product-doc-cap-250k into main 2026-08-06 08:57:26 +02:00
Owner

MCP-helft van de ProductDoc-cap-verhoging. Lockstep met Scrum4Me PR #144 — beide schrijven via dezelfde writeProductDoc, dus MAX_PRODUCT_DOC_CONTENT_LEN moet in beide repo's gelijk blijven.

Waarom 250K

De 100K was een zelf-opgelegd Zod-plafond, niet een DB-grens (content_md is @db.Text). De echte harde muur ligt hoger: product_docs.search_vec is een GENERATED STORED tsvector en Postgres weigert er een van >= 1 MB — dan faalt de hele INSERT.

Waarom de melding belangrijker is dan het getal

Een agent die alleen een kaal maxLength ziet, gaat inkorten. De remedie is splitsen. Die staat nu op de drie plekken die een agent daadwerkelijk leest:

  1. de tool-description — bij het kiezen van de tool;
  2. de field-describe — belandt in het gegenereerde JSON Schema, dus zichtbaar vóór de call;
  3. de max()-melding — zichtbaar na een mislukte call.

Bewust .max() gehouden in plaats van superRefine: superRefine sloopt maxLength uit het gegenereerde JSON Schema, waardoor een agent de limiet pas ná een mislukte call zou kennen.

Deploy-noot

De draaiende MCP komt uit ~/Development/scrum4me-mcp-stable. De 250K geldt pas na merge + pull + restart daar; tot dan dwingt de live tool nog 100K af.

Verificatie

npx tsc --noEmit toont geen fouten in src/tools/create-product-doc.ts. De repo heeft pre-existing typecheck-fouten door een stale Prisma-client (agentMessage, ReviewVerdict.COMMENT, sprint_sequence) — die staan los van deze wijziging.

🤖 Generated with Claude Code

MCP-helft van de ProductDoc-cap-verhoging. Lockstep met Scrum4Me PR #144 — beide schrijven via dezelfde `writeProductDoc`, dus `MAX_PRODUCT_DOC_CONTENT_LEN` moet in beide repo's gelijk blijven. ## Waarom 250K De 100K was een zelf-opgelegd Zod-plafond, niet een DB-grens (`content_md` is `@db.Text`). De echte harde muur ligt hoger: `product_docs.search_vec` is een `GENERATED STORED` tsvector en Postgres weigert er een van >= 1 MB — dan faalt de hele INSERT. ## Waarom de melding belangrijker is dan het getal Een agent die alleen een kaal `maxLength` ziet, gaat inkorten. De remedie is splitsen. Die staat nu op de drie plekken die een agent daadwerkelijk leest: 1. de **tool-description** — bij het kiezen van de tool; 2. de **field-`describe`** — belandt in het gegenereerde JSON Schema, dus zichtbaar *vóór* de call; 3. de **`max()`-melding** — zichtbaar *na* een mislukte call. Bewust `.max()` gehouden in plaats van `superRefine`: `superRefine` sloopt `maxLength` uit het gegenereerde JSON Schema, waardoor een agent de limiet pas ná een mislukte call zou kennen. ## Deploy-noot De draaiende MCP komt uit `~/Development/scrum4me-mcp-stable`. De 250K geldt pas na merge + pull + restart daar; tot dan dwingt de live tool nog 100K af. ## Verificatie `npx tsc --noEmit` toont geen fouten in `src/tools/create-product-doc.ts`. De repo heeft pre-existing typecheck-fouten door een stale Prisma-client (`agentMessage`, `ReviewVerdict.COMMENT`, `sprint_sequence`) — die staan los van deze wijziging. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
feat(product-docs): cap naar 250K + splits-instructie in de terugmelding
All checks were successful
CI / Verify (pull_request) Successful in 1m59s
c34a6e07bb
De 100K-cap was een zelf-opgelegd Zod-plafond, niet een DB-grens
(content_md is @db.Text). 250K laat forse documenten toe en blijft ruim
onder de echte harde muur: product_docs.search_vec is een GENERATED
STORED tsvector en Postgres weigert er een van >= 1 MB.

Belangrijker dan het getal is de terugmelding. Een agent die alleen een
kaal maxLength ziet gaat inkorten; de remedie is splitsen. Die staat nu
op drie plekken die een agent daadwerkelijk leest:
- de tool-description,
- de field-describe (belandt in het JSON Schema, dus zichtbaar vóór de
  call),
- de max()-melding (zichtbaar na een mislukte call).

Bewust .max() gehouden i.p.v. superRefine: superRefine sloopt maxLength
uit het gegenereerde JSON Schema, waardoor de agent de limiet pas ná een
mislukte call kent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
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!111
No description provided.