docs(queue): rules-file revisie 3 — kimi geen bestemming, host-neutrale env, requeue-recept #109

Merged

janpeter merged 2 commits from docs/rules-file-revisie3 into main

2026-07-27 04:59:40 +02:00

janpeter commented

2026-07-27 03:55:37 +02:00

Owner

T-130: revisie 3 van de rules-file. Actief op mac sinds vandaag (277b6354…, 5469 bytes, 34 regels); de fence in dit document is byte-identiek geverifieerd aan het actieve bestand. De sync naar de twee servers loopt als T-133.

Kimi is géén bestemming — en dat staat er nu expliciet. Change of plans: Kimi kan zijn eigen requests niet claimen. Het model blijft in het vocabulaire (het is uitgerold naar shared, de CLI-tweelingkopie, alle drie de hosts en beide consumers, en het breekt niets), maar mac:kimi als bestemming zou een zwart gat zijn: berichten komen aan, niemand haalt ze op. De regel noemt mac:codex als alternatief en vraagt de lezer om mac:kimi niet alsnog aan de lijst toe te voegen — zonder die laatste zin verwijdert de volgende lezer het symptoom en herstelt het probleem.

Twee host-specifieke defecten opgelost, gemeld door max2. Het background-snippet deed source ~/.zshenv, wat op geen van beide servers bestaat; de env-regel noemde max2 niet terwijl die óók ~/.config/s4m-queue.env gebruikt. max2 vond ze bij de eerste sync en repareerde ze bewust níét, omdat byte-identiek het acceptatiecriterium was — precies de juiste afweging.

Het requeue-recept is expliciet. De regel "vastzittende claims herstellen automatisch ~5 min na procesdood" was waar maar misleidend in combinatie met requeue onder admin/jp. Empirisch op max2: ná een MCP-herstart geeft je eigen claim onmiddellijk QUEUE_CLAIM_EXPIRED terwijl de rij op claimed blijft staan, en s4m-queue requeue is de enige weg vooruit — er is geen MCP-equivalent. Met de waarschuwing erbij om nooit een taak uit te delen die zélf de MCP herstart zonder dit recept; die claim overleeft de herstart per definitie niet.

Twee correcties op dit document zelf.

s4m-rules-apply bestaat wél. Een eerdere versie van het statusblok beweerde van niet, op grond van command -v dat niets vond — en de reden dát hij onvindbaar was is veelzeggend: de bin was kapot. Een cp -R van dist/ had de executable-bit van alle drie de binaries gewist en alleen cli.js werd gerepareerd, de enige die toen getest was. Inmiddels hersteld. Hij kent kimi overigens niet: eigen allowlist, en targetPath() zou kimi's regels in Claude's map laten belanden. Openstaande beslissing, genoteerd.

En de CLI-uitrol is rond op alle drie de hosts, met per host een andere topologie: mac en scrum4me-server draaien een npm link naar een dev-checkout, max2 een echte globale installatie. Dat verschil plus de chmod-val staat nu vast, inclusief het advies de bin-map uit package.json af te lopen in plaats van op je geheugen te vertrouwen.

Alleen documentatie; geen code.

🤖 Generated with Claude Code

T-130: revisie 3 van de rules-file. Actief op mac sinds vandaag (`277b6354…`, 5469 bytes, 34 regels); de fence in dit document is byte-identiek geverifieerd aan het actieve bestand. De sync naar de twee servers loopt als T-133. **Kimi is géén bestemming — en dat staat er nu expliciet.** Change of plans: Kimi kan zijn eigen requests niet claimen. Het model blijft in het vocabulaire (het is uitgerold naar shared, de CLI-tweelingkopie, alle drie de hosts en beide consumers, en het breekt niets), maar `mac:kimi` als bestemming zou een zwart gat zijn: berichten komen aan, niemand haalt ze op. De regel noemt `mac:codex` als alternatief en vraagt de lezer om `mac:kimi` niet alsnog aan de lijst toe te voegen — zonder die laatste zin verwijdert de volgende lezer het symptoom en herstelt het probleem. **Twee host-specifieke defecten opgelost, gemeld door max2.** Het background-snippet deed `source ~/.zshenv`, wat op geen van beide servers bestaat; de env-regel noemde max2 niet terwijl die óók `~/.config/s4m-queue.env` gebruikt. max2 vond ze bij de eerste sync en repareerde ze bewust níét, omdat byte-identiek het acceptatiecriterium was — precies de juiste afweging. **Het requeue-recept is expliciet.** De regel "vastzittende claims herstellen automatisch ~5 min na procesdood" was waar maar misleidend in combinatie met requeue onder admin/jp. Empirisch op max2: ná een MCP-herstart geeft je eigen claim onmiddellijk `QUEUE_CLAIM_EXPIRED` terwijl de rij op `claimed` blijft staan, en `s4m-queue requeue` is de enige weg vooruit — er is geen MCP-equivalent. Met de waarschuwing erbij om nooit een taak uit te delen die zélf de MCP herstart zonder dit recept; die claim overleeft de herstart per definitie niet. **Twee correcties op dit document zelf.** `s4m-rules-apply` bestaat wél. Een eerdere versie van het statusblok beweerde van niet, op grond van `command -v` dat niets vond — en de reden dát hij onvindbaar was is veelzeggend: de bin was kapot. Een `cp -R` van `dist/` had de executable-bit van alle drie de binaries gewist en alleen `cli.js` werd gerepareerd, de enige die toen getest was. Inmiddels hersteld. Hij kent kimi overigens niet: eigen allowlist, en `targetPath()` zou kimi's regels in Claude's map laten belanden. Openstaande beslissing, genoteerd. En de CLI-uitrol is rond op alle drie de hosts, met per host een andere topologie: mac en scrum4me-server draaien een npm link naar een dev-checkout, max2 een echte globale installatie. Dat verschil plus de chmod-val staat nu vast, inclusief het advies de `bin`-map uit `package.json` af te lopen in plaats van op je geheugen te vertrouwen. Alleen documentatie; geen code. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

janpeter added 2 commits

2026-07-27 03:55:37 +02:00