fix(deps): source-map-js 1.2.2 + shell-quote 1.12.0 (GHSA-68fv-2mgg-jv7q, GHSA-pqg4-j6r4-53mv)

[Goosterhof]

What

Lockfile-only bump of source-map-js from 1.2.1 to 1.2.2, made with npm update source-map-js --package-lock-only.

Why

GHSA-68fv-2mgg-jv7q (high): source-map-js 1.0.0–1.2.1 allows an event-loop denial of service through indexed source-map section offsets. Dependabot has not opened a PR for it yet. On isms the pinned 1.2.1 failed the npm audit --omit=dev gate, and with it every frontend push. This PR is one leg of a fleet wave fixing the same pin in every territory that still carries it.

Verification

• npm audit on this lockfile: source-map-js flagged before, not flagged after.
• Diff: version, resolved and integrity of the one node_modules/source-map-js entry change together, and nothing else moves.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SCdpT7UGfLM4PPM9GqUp1h

[cloudflare-workers-and-pages]

Deploying fs-packages with    Cloudflare Pages

Latest commit:	0e1feb3
Status:	✅  Deploy successful!
Preview URL:	https://1c51aed2.fs-packages.pages.dev
Branch Preview URL:	https://fix-source-map-js-ghsa-68fv.fs-packages.pages.dev

View logs

[Goosterhof]

Round 1 CI was red on check: npm audit --audit-level=high flagged a second advisory that this PR didn't cause, critical GHSA-pqg4-j6r4-53mv on shell-quote 1.10.0 (via @changesets/cli → launch-editor). It fails that gate on every PR against main today. 0e1feb3 bumps it to 1.12.0, lockfile-only, and a local npm audit now reports 0 vulnerabilities. The title now names both advisories.

[crit-ai]

Crit reviewt deze pull request. Crit is een automatische reviewer. Zijn review staat als aparte review op deze pull request, onder dit bericht of, bij een mislukte ronde, na de volgende poging.

• Issue — blokkeert de pull request. Fix het en push, of zeg in de thread wat je laat staan en waarom.
• Nitpick — blokkeert nooit en vraagt geen antwoord. Een nitpick laten liggen is een legitieme keuze.
• Resolven — een thread zelf resolven verandert niets. Crit leest de code en je woorden. Eerst reageren, dan pushen.

Een review lezen

Eén review per ronde. Bovenaan de telling en het oordeel. Daaronder de issues, dan de nitpicks ingeklapt.

• Een issue op een regel die in de diff zichtbaar is, staat ook inline op die regel.
• Een issue elders staat in de samenvatting, gemarkeerd als not on the diff, so not inline.
• Elke nitpick eindigt met de reden waarom hij geen issue is: nitpick because ….
• Finder trace — onder elke issue staat een ingeklapt blok met de ruwe vondst: de claim, het gevolg, de paden die de zoeker volgde en de drie tags. Voor mensen optioneel; voor een agent die de fix maakt is dit het startpunt, want hier staan de paden die de zoeker las, niet alleen de verankerde regel.
• Still open — een eerdere thread waarvan het probleem op deze head nog staat, met de alinea die zegt wat er nog ontbreekt en dezelfde finder trace.
• Settled, not re-filed: N — vondsten die een eerdere thread al dekt; crit post ze niet opnieuw.

Issue of nitpick

Het verschil is niet ernst. Elke vondst draagt drie tags. Geldt één nitpick-waarde, dan is het een nitpick; anders een issue. Een vaste regel kiest, geen agent.

tag	waarde	betekenis	bucket
harm_requires	nothing	het gaat nu al mis, zoals de code er staat	issue
harm_requires	runtime_state	het gaat mis onder een voorwaarde tijdens het draaien: een flag, data, timing	issue
harm_requires	code_change	het gaat pas mis na een latere wijziging die nog niet gedaan is	nitpick
harm_requires	no_runtime_path	geen pad bereikt het probleem: dode code, een onbereikbare tak	nitpick
provenance	introduced	deze pull request schreef de regel	issue
provenance	adjacent	ongewijzigde code die deze wijziging breekt of voedt	issue
provenance	pre_existing	stond er al en deze wijziging maakt het niet erger	nitpick
confidence	confirmed	crit volgde het pad; het klopt op deze head	issue
confidence	unconfirmed	een echte zorg die crit niet rond kreeg; de proof gap zegt wat ontbreekt	nitpick

• Runtime is een issue. Crit noemt het mechanisme, niet een kans; hoe vaak het optreedt weeg jij.
• Buiten de diff is geen vrijstelling. Breekt jouw wijziging bestaande code, dan is dat adjacent en een issue.

Wat doe je met een vondst

Voor een issue werken drie dingen, zolang je het zegt.

actie	wat je doet	wat crit doet
Fixen	fix, reageer in de thread, dán push	ziet de nieuwe code en sluit de thread zelf
Laten staan	zeg wat je laat staan en wie het oppakt: "out of scope voor deze PR", "real, filed as KD-1341", "report aangemaakt in Kendo", "risico geaccepteerd"	sluit de thread en blokkeert er niet meer op
Weerleggen	leg uit waarom het niet klopt, met iets dat crit kan nakijken: een pad, een test, een meting	leest de code; klopt jouw uitleg, dan sluit crit de thread

Wat niet werkt: een thread zelf resolven zonder fix of antwoord. "Werkt bij mij" en "fixen we later" tellen niet.

Een nitpick laten liggen is een legitieme keuze. Hij blokkeert niet en vraagt geen antwoord. Oppakken, een ticket maken of niets doen: alle drie prima.

oordeel	wanneer
request changes	minstens één issue of één open thread
approve	geen van beide; nitpicks mogen blijven
comment	de repo heeft blokkeren of goedkeuren uit staan

Veelgestelde vragen

Een runtime-issue komt bij ons bijna nooit voor. Mag ik hem laten staan?

Ja. Schrijf in de thread dat je het risico accepteert en waarom; crit sluit de thread. Let op: een retry, een cron-overlap of een dubbele webhook gebeurt ook bij één gebruiker.

Crit vond iets in code die ik niet heb aangeraakt. Waarom staat dat op mijn pull request?

Crit zet een vondst waar het probleem woont. Breekt jouw wijziging die code, dan is het adjacent en een issue; een oude bug los van jouw wijziging is pre_existing en een nitpick.

Wat betekent "proof gap" en wat moet ik ermee?

Crit zag een echt mechanisme maar kon één stap niet bewijzen; de proof gap zegt welke. Antwoord in de thread of dat pad bestaat, en fix het als dat zo is.

Ik heb de thread geresolved op GitHub, maar crit komt er toch weer mee. Waarom?

Crit kijkt naar de code, niet naar de knop. Staat het probleem op de nieuwe head nog, dan post crit het opnieuw; fix het of schrijf in de thread waarom je het laat staan.

Wat moet ik precies in een thread schrijven om iets te laten staan?

Noem het gedrag dat je laat staan en wie het oppakt; een Kendo-report zonder ticketnummer telt ook. Crit zoekt het report nooit op en leest alleen wat jij in de thread schrijft.

Ik heb gefixt en gepusht, maar crit ziet mijn reactie niet. Wat ging er mis?

Crit leest de threads vlak na een push, dus een reactie van daarna mist die ronde. Eerst reageren, dan pushen; de fix zelf ziet crit altijd.

Mag ik alles in de finder trace vertrouwen?

De paden en regels wel: crit liep ze na voordat de issue werd gepost. De zinnen eromheen niet altijd. De vetgedrukte kop en de alinea eronder zijn de geverifieerde tekst; waar de trace daarvan afwijkt, wint de alinea. Een absolute bijzin in de trace ("only called by tests") is een claim van de zoeker, geen oordeel.

Ik laat een agent de fix maken. Wat geef ik hem?

De hele comment, inclusief de trace. De trace kan verdere sites noemen; laat hem elke site in de repo controleren voordat hij fixt. Een issue die "three routes" zegt en er één verankert, noemt de andere twee in de trace. Een pad onder node_modules of vendor is leesspoor, geen site.

Moet ik op nitpicks reageren?

Nee. Laten liggen is een legitieme keuze: een nitpick heeft geen thread en blokkeert niet. Zolang de code hetzelfde blijft, kan hij in een volgende ronde opnieuw in de ingeklapte lijst staan.

Waarom zegt crit "request changes" terwijl er geen nieuwe issues zijn?

Een eerdere thread waarvan het probleem nog staat, blokkeert ook. Kijk onder Still open: daar staat de thread met wat er nog ontbreekt.

Kan crit per repo minder streng?

Ja, met twee schakelaars per repo: approve en request changes. Staat request changes uit, dan wordt het oordeel comment en blokkeert de pull request nooit.

[crit-ai]

Crit review

0 issues · 0 nitpicks · head 0e1feb3260

Crit approves — nothing blocking at this head.

No issues or nitpicks.