docs: add Node.js compatibility roadmap and conformance test integrity policy

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: NathanFlurry

CLAUDE.md

@@ -29,6 +29,17 @@
 - **no suite-specific VFS special-casing** — the test runner must not branch on suite name to inject different filesystem state; if a test needs files to exist, either the kernel should provide them or the test should be excluded
 - **categorize exclusions honestly** — if a failure is fixable with a patch or build flag, it's `implementation-gap`, not `wasm-limitation`; reserve `wasm-limitation` for things genuinely impossible in wasm32-wasip1 (no 80-bit long double, no fork, no mmap)
 
+### Node.js Conformance Test Integrity
+
+- conformance tests live in `packages/secure-exec/tests/node-conformance/` — they are vendored upstream Node.js v22.14.0 test/parallel/ tests run through the sandbox
+- `docs-internal/nodejs-compat-roadmap.md` tracks every non-passing test with its fix category and resolution
+- when implementing bridge/polyfill features where both sides go through our code (e.g., loopback HTTP server + client), prevent overfitting with these three mitigations:
+  - **wire-level snapshot tests**: capture raw protocol bytes and compare against known-good captures from real Node.js
+  - **project-matrix cross-validation**: add a project-matrix fixture (`tests/projects/`) using a real npm package that exercises the feature — the matrix compares sandbox output to host Node.js
+  - **real-server control tests**: for network features, maintain tests that hit real external endpoints (not loopback) to validate the client independently of the server
+- never inflate conformance numbers — if a test self-skips (exits 0 without testing anything), mark it `vacuous-skip` in expectations.json, not as a real pass
+- every entry in `expectations.json` must have a specific, verifiable reason — no vague "fails in sandbox" reasons
+
 ## Tooling
 
 - use pnpm, vitest, and tsc for type checks