[setnilson]

Why

The master deploy after #11 failed at Lockfile consistency, so Typecheck, lint & build and Upload k8s-pods were both skipped and the k8s-pods blank-render fix never went live. The last app actually deployed is still #10's pre-fix build.

What was broken

1. The scoped override could never install. #11 added:

"@datadog/apps-frontend": { "react": "$react", "react-dom": "$react-dom" }

npm resolves a $name override reference against the root package's own direct dependencies — not against a sibling entry in the same overrides block. This root depends on neither react nor react-dom (only @types/*), so every install failed outright:

npm error Unable to resolve reference $react

Fixed by spelling the versions out. The intent of #11 — forcing @datadog/apps-frontend's ^18 || ^19 peer range down to a single React 18 copy — is preserved.

2. The lockfile was edited, not regenerated. #11 deleted the nested apps/k8s-pods/node_modules/@datadog/apps-frontend entry and left references to packages that no longer had entries, so npm ci rejected it:

npm error Missing: @datadog/apps-frontend@0.0.9 from lock file
npm error Missing: zod@4.3.6 from lock file

Regenerated with npm install, which restores both entries. The many "peer": true removals in the diff are normal npm 10.9.8 re-resolution output, not hand edits.

Also in here

• docs/agents/scaffolding.md asserted that "the $react reference resolves to the root react override". That claim is what the broken override was written from, so it's corrected with a note on the actual failure mode.
• apps/k8s-pods version 0.0.1 → 0.0.2. The Detect changed apps job only builds a matrix from paths that changed under apps/ in the pushed range, so a lockfile-only fix would land green and still not redeploy k8s-pods. This touch is what makes the merge actually ship it.

Verification

Run locally on npm 10.9.8 / node 22.23.1, matching CI's node-version: 22:

• npm ci --ignore-scripts — passes (the step that was failing)
• npm ci — passes
• workspace React alignment check — no mismatches
• npm run typecheck / npm run lint / npm run build — all pass
• grep 'apps/.*/node_modules/react' package-lock.json — no matches, i.e. no duplicate React, which is the check scaffolding.md prescribes

Follow-up worth considering

The workflow has no workflow_dispatch trigger and gates uploads on changed paths, so there is no way to re-run a deploy that failed for a reason unrelated to the app itself — recovery always needs a dummy commit under apps/. Worth adding a manual trigger separately.