fix(hub): hub-ask geeft alleen status/answer/note terug #165
No reviewers
Labels
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
janpeter/Scrum4Me!165
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/hub-ask-output-shape"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Regressie van mijn eigen besluit-handtekening (#160), gevonden tijdens item 5 van de M34-gate.
Wat er misging
De wait-route draagt sinds die fix een
sig.askHubgaf de rauwe body door en de CLI printte hem letterlijk. Live op de server:Vier sleutels waar het runbook er drie belooft. Schadelijk is het niet — een HMAC-uitkomst prijsgeven verraadt de sleutel niet — maar het is een stille contractwijziging in een referentie-client, en dat is precies het soort dat niemand opmerkt tot een
jq-pijplijn op drie sleutels rekent.De fix
askHubgeeft nu expliciet{status, answer, note}terug in plaats van de body.Bewust géén handtekeningverificatie toegevoegd: dit is een vraag-client, geen autorisatiepad. Die grens wil ik scherp houden — verificatie hier inbouwen wekt de indruk dat er iets bewaakt wordt wat niet bewaakt wordt.
Waarom de bestaande test dit niet ving
Hij kón het niet vangen: zijn mock gaf nooit een
sigterug, dus hij testte een wereld die sinds #160 niet meer bestond. Dat is hetzelfde patroon dat ik in de eindreview bij anderen aanwees — een test die groen blijft omdat zijn mock achterloopt op de werkelijkheid.De nieuwe test stuurt bewust een
sigén een onbekend veld mee, en assert op de sleutelverzameling in plaats van alleen op de waarden. RED-controle: met de oude regel faalt hij, met de fix niet.npm run verify: 2013 tests groen.Regressie van mijn eigen besluit-handtekening. De wait-route draagt sinds die fix een `sig`, en askHub gaf de rauwe body door, waarna de CLI hem letterlijk uitprintte. Live tijdens de M34-gate leverde dat vier sleutels op waar het runbook er drie belooft: {"status":"answered","answer":"Blauw","note":null,"sig":"zkY38fJn…"} Schadelijk is het niet — een HMAC-uitkomst prijsgeven verraadt de sleutel niet — maar het is een stille contractwijziging in een referentie-client, precies het soort dat je niet ziet tot een jq-pijplijn op drie sleutels rekent. Bewust géén handtekeningverificatie toegevoegd: dit is een vraag-client, geen autorisatiepad. Dat onderscheid moet scherp blijven, anders wekt het de indruk dat hier iets beveiligd wordt wat dat niet is. De bestaande test ving dit niet omdat zijn mock nooit een `sig` teruggaf. De nieuwe test stuurt bewust extra velden mee en assert op de sleutelverzameling. RED-controle: met de oude regel faalt hij, met de fix niet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>APPROVED
Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden.
Findings
Review
De wijziging houdt
scripts/hub-ask.mjsop het gedocumenteerde client-contract: bij een terminale wait-response geeftaskHuballeenstatus,answerennoteterug en lekt geen route-interne velden zoalssig. De regressietest in__tests__/scripts/hub-ask.test.tsdekt precies die contractgrens, inclusief toekomstige extra velden.Tests niet lokaal uitgevoerd; de diff bevat wel een gerichte unit-test voor het aangepaste gedrag.