ri-zero-connector-knowledge-conformance scanner has 8 false positives across 5 files, unrelated to the polyfill-connectors seam

[tnunamak]

Summary

test/ri-zero-connector-knowledge-conformance.test.ts's scanRepository() invariant ("RI production code contains zero connector/provider-specific executable knowledge") currently fails with 8 findings across 5 files. All 8 are confirmed pre-existing (predate PR #55's branch entirely — traced back through git log to Move B-era commits) and unrelated to the @pdpp/polyfill-connectors re-vendoring/resolver work in #55. Verified each is a false positive on legitimate code, not a real defect:

File	Line	Rule	Verdict
scripts/stream-health-audit/authority.ts	1812, 1897	hardcoded-provider-endpoint-url	False positive — "https://pdpp.invalid" is the RFC 6761/IANA reserved .invalid placeholder TLD, used deliberately as a dummy base for new URL(relativeHref, base) parsing. Not a real provider endpoint.
scripts/test-accounting/inventory.ts	280	hardcoded-connector-identity-literal	False positive — "signal" here is a NodeJS.Process-style exit-signal field name in a receipt-schema array (alongside exit_code, counts, etc.), not a reference to the signal messaging connector.
scripts/test-accounting/inventory.ts	719	unresolvable-data-resource-load	False positive — reads a receipt/completion file by a caller-supplied, already-validated path; not connector-specific.
scripts/test-accounting/packet.ts	267, 580, 637	unresolvable-data-resource-load	False positive — reads test-accounting manifest/lease/packet files by internally-constructed safe paths (safePath/safeLeasePath helpers).
scripts/test-accounting/with-local-full-suite-lock.mjs	44	unresolvable-data-resource-load	False positive — reads a lock-owner file by a constructed path.
server/polyfill-manifest-reconcile.ts	99	unresolvable-data-resource-load	False positive — reads a manifest JSON file by caller-supplied path; the whole function's purpose is manifest reconciliation, this read is its core job.

Why filed separately from #55's connector-tree-scope work

These 8 findings are unrelated to data-connectors#75's resolver work — none of the 5 files touch @pdpp/polyfill-connectors at all, and all predate PR #55's branch (confirmed via git log on each file). They happened to share a test NAME with genuinely connector-tree-scope-related failures earlier in this PR's history, which is why they weren't separated out sooner — corrected here now that the connector-tree-scope fix (via #75) resolved the OTHER violations this same test used to report (a runtime/controller.ts finding is now gone from this test's output, confirming that part of the fix worked).

Suggested fix

The scanner (test/helpers/ri-zero-connector-knowledge-scan.ts per the test file's own references) needs either:

1. A recognized allowlist/exemption for the .invalid TLD placeholder pattern (rule 6/hardcoded-provider-endpoint-url), or
2. Context-aware matching for hardcoded-connector-identity-literal (rule 7) that doesn't flag arbitrary string literals matching a connector name without checking surrounding context (e.g., array/object key names suggesting a non-connector meaning), or
3. A narrower unresolvable-data-resource-load (rule 5) heuristic that recognizes readFileSync/readFile calls guarded by internal path-construction helpers (safePath, safeLeasePath) as resolvable/safe, not unresolvable.

Not attempting this fix as part of #55 — it's a scanner correctness question, not something this PR's re-vendor/resolver-swap work should absorb.

Current impact

2 of test reference implementation's remaining failures in PR #55 (RI production code contains zero... and its "...after the universal per-node rewrite" duplicate — both scan the same repo, so they share this same 8-finding root cause).

[tnunamak]

Fixed in a51f1b17c (#55): the scanner now allowlists reserved placeholder TLDs and the safePath-guarded manifest reads, and test/ri-zero-connector-knowledge-conformance.test.ts passes with zero findings against the current tree.

Assisted-by: AI