feat/powerradar

JWT validation accepts 2-part tokens — should require exactly 3

services/metrics/integrations/powerradar-api/src/engine/eigw-client.ts:162

jwtExpiryMs() checks parts.length < 2 — accepts a 2-part token (header.payload with no signature) and attempts to decode it. Valid JWTs are always exactly 3 parts. Change to parts.length !== 3 to reject malformed inputs earlier. Practical impact is nil (the broker only returns well-formed Cognito JWTs) but the guard is loose.

Public OAuth client credentials hardcoded in source

services/metrics/integrations/powerradar-api/src/engine/eigw-client.ts:55

OAUTH_CLIENT_ID='webapi' and OAUTH_CLIENT_SECRET='webapisecret' are documented as public SPA constants (extracted from the app bundle, shared across all users) — not an org secret. Low security risk. The maintenance concern: if PowerRadar ever rotates these constants, updating requires a code change + redeploy. A comment pointing to the specific bundle source (index-BpQKjFYa.js) would help a future maintainer verify and update them.

scope.md success criteria stale — auth model changed

.branch/scope.md:16

Success criteria still reads 'one-time MFA login → refresh token stored in Secrets Manager' and 'Cognito REFRESH_TOKEN_AUTH'. Actual implementation is an OAuth2 password grant against a Spring broker (username+password credential, not a refresh token). The intent.md correctly documents the discovery but the scope.md checklist (line 16) and SG-2 credentialFields note (line 133) still reference the old model. Update scope.md so SG-2 implementers don't misread the credential shape.

Error types use ok/reason pattern instead of ADR-016 _tag+statusCode

services/metrics/integrations/powerradar-api/src/domain/types.ts:337

PowerradarFetchFailure uses {ok: false, reason, httpStatus, details} rather than the canonical discriminated union {_tag, statusCode} required by ADR-016. The transport layer intent (map to InvocationError._tag in the handler) is clear, but the handler (SG-4) will need an explicit mapping step. If other integrations follow _tag+statusCode, this creates an inconsistency. Consider whether this transport-internal pattern should be documented as a sanctioned exception or aligned to {_tag, statusCode} now before SG-4 consumes it.

clearTokenMemo() is exported as a test hook without a test file

services/metrics/integrations/powerradar-api/src/engine/eigw-client.ts:190

Exported only for testing (clearTokenMemo comment line 190). No __tests__/ directory or test files exist yet. The export is appropriate but could be marked with a JSDoc @internal tag to signal it's not part of the public API. Wire it into engine tests when they're written.

@batu/result not in dependencies — intentional deviation for transport layer

services/metrics/integrations/powerradar-api/package.json:18

Other integrations use Result<T, E> from @batu/result for fallible operations (ADR-016). This package uses its own ok/reason discriminated union. If intentional (transport layers can use simpler error shapes before mapping to domain errors), document it in a package-level comment or package.json description. If it should align with @batu/result, add the dependency and refactor before SG-4 solidifies the handler contract.

Engine unit tests absent — high-risk paths untested

services/metrics/integrations/powerradar-api/src/engine/eigw-client.ts:141

clearTokenMemo() test hook is exported (line 190) but no test files exist. isCloudFrontBlock(), jwtExpiryMs(), getToken() memo/refresh logic, and parseTokenResponse() error-envelope parsing are the riskiest paths — WAF detection depends on heuristics, JWT decoding must handle malformed tokens, token refresh must keep the old refresh token when the grant doesn't return a new one. These paths should have unit tests before SG-3 merges; adding them alongside chart-to-batu.ts translation tests is the natural time.

Browser User-Agent string (Chrome/148) will stale silently

services/metrics/integrations/powerradar-api/src/engine/eigw-client.ts:70

The BROWSER_HEADERS object pins Chrome/148 + matching sec-ch-ua. CloudFront WAF bot-detection may eventually reject a browser version that's years old. A stale UA would produce blocked failures with no obvious root cause. Consider adding a comment with the capture date (2026-07-20) so future oncall knows when it was last verified, and add this UA to the SG-7 framework-learnings update checklist.