[09/36] Add OC-010 GraphQL support

[cjohnsto-nz]

---

This is part 13 of 21 in a stack made with GitButler:

•  21  [22/36] Release 0.8.0 with packaged PDF.js preview #54
•  20  [21/36] Complete OC-070 protocol surface polish #56
•  19  [20/36] Record final OpenCollection supervisor acceptance #53
•  18  [19/36] Add OC-110 runtime authoring UX #52
•  17  [18/36] Add OC-080 runtime lifecycle and OC-110 task setup #51
•  16  [16/36] Record OC-050 OC-090 OC-100 supervisor audit #50
•  15  [15/36] Add OC-050 auth and transport support #49
•  14  [14/36] Add OC-100 request type UX #48
•  13  [13/36] Add OC-100 request type UX task #47
•  12  [12/36] Add OC-080 and OC-090 task tracks #46
•  11  [11/36] Record OC-010 through OC-040 supervisor audit #45
•  10  [10/36] Add OC-020 WebSocket support #44
•  9  [09/36] Add OC-010 GraphQL support #43 <-- current
•  8  [08/36] Require demo server fixtures for parallel tracks #42
•  7  [07/36] Record OC-000 and OC-060 supervisor audit #41
•  6  [06/36] Add OC-060 schema round-trip validation #40
•  5  [05/36] Add OC-040 runtime scripting support #39
•  4  [04/36] Add OC-090 gRPC streaming support #38
•  3  [03/36] Add OC-030 gRPC unary protobuf support #37
•  2  [02/36] Add OC-000 protocol dispatch foundation #36
•  1  [01/36] Add OpenCollection agent plan #35

[APKiwi]

Verdict: approve with nits. Best dep story in the stack: GraphQL is a hand-rolled {"query":...,"variables":...} POST with no graphql package and no client lib, exactly right for what this needs. Demo server binds 127.0.0.1 with deterministic fixtures, and the gRPC/WS dry-runs redact secrets properly.

• Major, reviewability not runtime: the GraphQL support this PR is titled for lives in the ancestor. graphqlSupport.ts, the dispatch wiring, webSocketClient.ts, grpcClient.ts, runtimeExecutionService.ts and the gRPC/ws deps all exist identically at the base (the docs-titled fixtures PR), while this increment bundles OC-020/030/040 glue that has nothing to do with OC-010. The feature can't be reviewed where it's named. GitButler restack artifact, but it defeats the point of the stacked split.
• Minor: sendRequestTool.ts (~741) calls buildGraphQLHttpRequest(request) eagerly for both dry-run and live paths, outside the try/catch that produces the structured error shape. Malformed GraphQL variables JSON therefore returns the generic ToolBase error instead of the {success:false, protocol, code} contract every other failure gets, and on the live path the result is computed then unused. Move it inside the dry-run branch or wrap it.
• Minor: no GraphQL-aware error handling. A 200 with {errors:[...]} renders as a plain success, no errors surface, no partial-data indication. Fine as MVP (Bruno does the same), just noting users can only reach errors via a runtime assertion on res.body.errors.
• Minor: buildGraphQLHttpRequest always packs a JSON body regardless of method, so method: GET would send a GET with a JSON body instead of query-string encoding. Latent, schema and demos only use POST.
• Nit: the demo fixture's users.find(id) || users[0] fallback means the user-with-variables assertion only holds for userId 1 or 2, changing the env var silently breaks it via the fallback. Echo the requested id instead.
• Nit: codeLensProvider quick-reject uses substring checks before the real parse, harmless but can full-parse files that merely contain the substring in a comment.

Tests: strong (live query and mutation against an ephemeral local fixture, invalid-variables, unresolved-var scan across all surfaces, tool dry-run + live, schema validation of the demo collection). Caveat: the runtime/WS/gRPC tests here exercise ancestor code, so they inflate this PR's apparent coverage.

Deps: none added in this increment, and the hand-rolled GraphQL approach is the right build-vs-buy call.

[cjohnsto-nz]

Fixed in ade2d0812df1b5881fb93ad4a90d8a7f9f2830b1.

• sendRequestTool no longer constructs the GraphQL HTTP adapter eagerly. Live sends now go directly through RequestExecutionService; dry-run construction is guarded and malformed variables return the normal structured result with success: false, protocol: "graphql", and code: "MISSIO_INVALID_GRAPHQL_VARIABLES".
• GraphQL GET now encodes query and variables as query parameters and sends no HTTP body. Existing active parameters with those names are updated rather than duplicated.
• The demo fixture no longer substitutes user 1 for an unknown requested ID; it returns a deterministic user carrying the requested ID.
• PR [09/36] Add OC-010 GraphQL support #43 also referenced getUnsupportedSnippetDiagnostic without importing or defining it, so the branch did not pass npm run compile independently. The exact implementation previously present only later in PR [21/36] Complete OC-070 protocol surface polish #56 (feature/oc-070-surface-polish, commit 35bf2af) now lives here with the guard that first uses it. This avoids inventing a second implementation and keeps the later change content-identical.

Not changing the GraphQL 200 response handling. HTTP success and GraphQL operation success are separate: a response may contain both data and errors, and Missio preserves that complete body in the response viewer. Assertions can impose operation-specific policy. Reclassifying partial-data responses as transport failures is outside OC-010's basic execution scope and needs an explicit product contract.

Not changing the CodeLens substring prefilter. It is only a cheap rejection path; candidates are still parsed as YAML and must pass the protocol type guard before any lens is emitted.

On the stack split: src/services/graphqlSupport.ts is physically introduced in PR #37 (feature/oc-030-grpc-unary-protobuf at c5dbae7aa68615a8155df60a440a910ad375bd32) because the parallel protocol agents shared types, execution, and unresolved-variable hunks. PR #43's cc721db5972df232fddc73bb2442c0550a92b1ff commit is still where GraphQL becomes an end-to-end feature: it adds the GraphQL fixtures and live tests and wires the editor, schema round-trip, commands, tree, CodeLens, and Copilot surfaces. Rewriting the lower history now would restack every descendant for review-only ownership cleanup, so I am not doing that.

Verification on the PR #43 branch: npm run compile passed; all 19 branch-era test files passed (375 tests); all 29 branch-era demo files validated. The explicit three-way PR #43 -> PR #44 edge check returned STACK_CLEAN. GitHub currently reports both PRs MERGEABLE/CLEAN, and all PR #43 checks are successful.

[cjohnsto-nz]

Stack maintenance note: a GitButler dependency push made while restoring PR #44 briefly rewound this branch. I immediately restored the exact reviewed head ade2d08; there is no net PR #43 content change.

The restored PR #43 -> PR #44 edge is clean. GitHub has rerun the checks and reports both PRs MERGEABLE / CLEAN with all checks passing.