Verified PKG's landed CI (.github/workflows/ci.yml, db7650b/8f45815) against
this lane's actual tree, per the standing instruction that conformance as a
required check is this lane's DoD to verify, not PKG's. It wasn't running:
the `conformance` job's presence-check looks for tests/conformance/CMakeLists.txt
or tests/conformance/package.json, and neither existed -- the job was
silently short-circuiting to a green "skipped" on every PR, forever. The M0
exit gate was not gating anything.
tests/conformance/CMakeLists.txt registers one ctest entry, labeled
"conformance", that shells out to run.sh -- the exact command
tests/conformance/README.md tells a human to run locally, so there is one
definition of "the suite passed", not a CMake-flavoured near-duplicate of it.
cpp/CMakeLists.txt's existing conformance_cpp test gets the same label, for a
lane iterating on core/generated/ who wants the fast native-only path.
Fixed a second landmine found while wiring this: the root CMakeLists.txt only
find_package(nlohmann_json)'s when daemon/CMakeLists.txt exists, since
daemon is its real consumer -- but daemon hasn't landed yet, so
add_subdirectory(tests/conformance) would have failed to configure the
moment this file existed, on every machine, until daemon merges. Fixed inside
tests/conformance/cpp/CMakeLists.txt with an if(NOT TARGET) guard rather than
widening the root file's condition, which is PKG's to change.
run.sh now installs its own Python deps (jsonschema, referencing) on demand:
they aren't in tools/bootstrap.sh's apt list -- that's PKG's script, these
are this suite's own dependency -- so a bare CI image would otherwise fail
check_contract.py with an ImportError before this suite even started.
Verified end to end: `cmake --preset dev && ctest --test-dir build/dev -R
'^conformance$'` passes in 23.8s, exercising the exact command and label the
CI job uses.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_012fgjnqFCS5h5L7gZTZo3rV
Schemas for the whole v1 surface: 38 methods, 9 events, 25 named types and the
JSON-RPC envelope, with x-privileged / x-transports / x-deadlineMs / x-errors
annotations that both generators emit as data rather than prose.
Four generators over one IR (contracts/codegen/schema_ir.py), so the C++ structs,
the TypeScript types and the OpenRPC document cannot disagree about what the
contract says:
gen_cpp.py -> core/generated/velox_proto.{hpp,cpp}
gen_ts.py -> extension/src/shared/protocol/
gen_openrpc.py -> contracts/openrpc.json
gen_cpp_conformance.py -> tests/conformance/cpp/fixture_dispatcher.hpp
Inbound parsing never throws: parse<T>() returns std::expected<T, ParseError> and
nlohmann's throwing ADL from_json is deliberately not emitted. Schema constraints
(minimum, maxLength, pattern, ...) become real runtime checks in both languages —
the daemon does not trust the extension and the extension does not trust the
daemon.
59 golden fixtures: a success case per method, 12 error cases, 9 events. Replayed
by tests/conformance/ against both the generated C++ and a live server over both
transports. tools/mockd serves the same fixtures with unhappy-path flags so the
GUI and EXT lanes never wait for veloxd.
run.sh also proves capture.offer fails open: with a daemon answering slower than
750 ms the client gives up and lets Firefox take the download.
core/generated/ is libveloxproto, a separate target from libveloxcore, which
still never sees JSON — see docs/adr/0009.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_012fgjnqFCS5h5L7gZTZo3rV
samiandClaude Sonnet 5