fix(dev): make OIDC smoke target install its declared JWT dependency

[seonghobae]

Current authority — 2026-09-22 KST

• direct parent refactor(ddd): restore contextual-orchestrator ownership boundary #899: c10b6545520afb342e68d01ea4bcfce75a6e5bab
• exact head: 0dd0fd9a74165a63a081d1435123a79be6feefca
• state: open / Draft / mechanically mergeable
• direct auth descendant security(auth): migrate public frontend off direct grants #1120: 73ab7ea24517bfcb1edfc83676f9fb56ea524bc0
• downstream docs: make README links registry-safe #1117: 72341358f7edf01360a5da69b01fe87684b8076b
• downstream fix(auth): add safe browser sign-in recovery #1124: c49aff397736db601fd1d2cb428c8006d0090d26

Findings owned here

The existing JWT/smoke RED→repair lineage remains authoritative: declared PyJWT dev dependency, removal of direct-interpreter bypass, token/JWKS compatibility evidence, PyJWT security floor, and RS256-only owned verifier paths. #899's latest movement is source-neutral (c10b6545..., no file delta) and is not accepted as repair/evidence.

Ordinary two-parent/non-force convergence 0dd0fd9a... adopts current #899 while preserving the seven-file JWT/smoke delta. Fresh compare from current #899 has exact merge-base and behind_by=0.

#1120, #1117 and #1124 were immediately converged down the stack; each has behind_by=0 against its new current parent and retains only its prior child-owned delta. No force push, destructive rebase, or parent source copy was used.

Predecessor hosted receipts do not transfer. Keep Draft while #899 is unmerged and until one unchanged exact head has applicable repository/security/static-analysis evidence and qualifying independent review.

No self-approval, gate weakening, blind rerun, new source-neutral wake commit, protected-main merge, or release is claimed.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[seonghobae]

Dependency-security traceability refresh (2026-09-20): the current uv.lock resolves pyjwt 2.13.0, but both backend/dev metadata still permit pyjwt[crypto]>=2.8.0. GitHub Reviewed advisory GHSA-xgmm-8j9v-c9wx / CVE-2026-48526 marks all PyJWT <2.13.0 affected by the mixed-family public-JWK/HMAC confusion issue, and GHSA-w7vc-732c-9m39 / CVE-2026-48525 marks >=2.8.0, <=2.12.1 affected by the detached-JWS unbounded decode DoS; both are patched in 2.13.0. PyPI now publishes 2.14.0 (2026-09-11). Therefore the resolved lock is currently above the known 2.13.0 security boundary, but the declared floor remains security-stale and permits vulnerable future resolution. Do not fix this with a metadata-only floor edit: move declared floor, regenerated lock, and an executable dependency/security regression together, then attach exact-head install/security receipts. References: GHSA-xgmm-8j9v-c9wx ; GHSA-w7vc-732c-9m39 ; https://pypi.org/project/PyJWT/