security(kpi): reject malformed UTF-8 in threshold checks

[seonghobae]

Problem

Protected main c85d710804139c0697d7ef8fa47d02b1389e6d84 reads retained KPI NDJSON in scripts/check-kpi.mjs through non-fatal UTF-8 decoding. Byte-invalid /exchange records can therefore be replacement-normalized before failure-rate, latency and required-window semantics.

This is separate from #122/#123 (kpi:compute) and #104/#105 (strict provenance/snapshot orchestration): exact-byte authentication does not make lossy semantic decoding safe.

RCA

• First failing boundary: retained/snapshotted KPI bytes -> threshold-check JSON semantics.
• Immediate cause: ordinary UTF-8 decoding replaces malformed byte sequences.
• Root cause: threshold checking lacked an explicit valid-byte/text boundary before metric and window evaluation.
• Systemic risk: corrupted evidence can normalize into a different JSON record and influence PASS/FAIL.

Active test-first repair

PR #127 (fix(kpi): reject malformed threshold input bytes) is the current direct-main repair.

• protected/live base: c85d710804139c0697d7ef8fa47d02b1389e6d84;
• RED head: 85a9ce68f346a4281b539bcc45df607a6e4ea66d;
• current exact GREEN head: 85463e4e18750af27aac8ea35ee1680e7b360661;
• current compare: 2 commits ahead / 0 behind live main, merge base exactly the protected head;
• PR state: Ready, mergeable, direct main.

GREEN reads exact bytes and applies fatal TextDecoder decoding before line, JSON or required-window semantics. Existing thresholds, route/latency behavior and non-JSON filtering remain unchanged.

Exact current proof

For unchanged #127 head 85463e4e18750af27aac8ea35ee1680e7b360661:

• application ci 31443518948: terminal success;
• reviewer-ci 31443518901: terminal success;
• eligible central Security Scan 31443518918: terminal success;
• formal reviews: 0;
• inline review threads: 0;
• CodeRabbit was rate-limited on this exact base/head and is non-passing/non-approval evidence.

Acceptance

Repository-owned implementation on #127 current exact head

• Deterministic RED CLI regression makes malformed UTF-8 inside an otherwise valid /exchange record fail before metric output.
• Valid UTF-8 KPI input preserves current threshold and window behavior.
• Syntactically non-JSON/non-Noema lines remain ignored under the existing policy.
• Production code reads exact bytes and decodes with fatal UTF-8 before line/JSON semantics.
• Focused RED -> GREEN plus exact-head application CI, reviewer-ci, eligible central Security Scan and current review/thread validation are complete.
• No production KPI/provenance, release, deployment or acquisition-readiness claim is created by parser hardening.

Remaining protected integration / operation

• Obtain actual live chore(governance): protect main and enforce release checks #27 governance and qualifying independent non-author formal approval required by chore(operations): provision and activate hourly maintainer App #29 where applicable.
• Merge only an unchanged exact head after every applicable gate remains satisfied.
• Re-run malformed-byte, valid-threshold and required-window contracts from protected main after integration.
• Keep real 30-day production KPI provenance and operational acceptance under fix(kpi): bind strict production provenance to exact log bytes #104/fix(kpi): bind strict provenance to exact log bytes #105 and production evidence gates, not this parser repair.

Related: #3, #27, #29, #104, #105, #122, #123, #127