docs(gaps): register GT-654 and GT-655 — two findings that had nowhere to live - #429
Merged
Merged
Conversation
…e to live Both surfaced during the live cross-cluster validation and existed only as an observation in the E2E scenario board, which by design cites gap ids and never owns one. Until now there was no id to cite. GT-654 — three services of one product answer /health in three shapes. core-api returns the ADR-0073 envelope (`data.status = "OK"`); mcp and agent-runtime return bare objects (`status = "ok"`). The nesting differs and so does the case. It is not academic: on 2026-08-03 a cross-cluster probe matched `"status":"ok"` literally and reported two healthy services as unreachable while they were serving. Registered as a DECISION before it is work — the envelope is the Core's stated contract, but /health is what a Kubernetes probe reads and those are configured against today's shape, so the resolution is a written decision and then the surfaces obeying it. GT-655 — four operations declared on all three surfaces have never been invoked by any test. `satellite-create`, `pattern-list`, `pattern-get` and `pattern-list-by-topology` are `exposed: true` on CLI, MCP and REST and the exploration harness has NO binding for any: 48 of 73 operations carry one, these four do not, and no captured response exists for them on any surface. The matrix asserts they exist in three places and nothing has ever asked them to prove it. `satellite-create` is why a binding is not trivial — it provisions a live GitHub repository and writes the local registry, so exercising it needs an effect the harness can undo or a dry-run path it can trust. Measured before writing, not read: the four come from `uncoveredTriangleOps` in a coverage.json re-generated today through `npm run test:exploration`, the absent bindings from bindings.ts, and the three /health payloads from the live services on their node ports. Counters 651 -> 653 and pending 4 -> 6 in both languages, maturity reconciled, executive summary regenerated; guard 46 reports the derived chain at a fixed point and 49 confirms neither id collides with main. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
📊 Bilingual Coverage ImpactPR Changes
Repository Coverage
✅ Good: All EN changes have ES counterparts. Generated by GitHub Actions |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Both surfaced during the live cross-cluster validation and existed only as an observation in the E2E scenario board — which by design cites gap ids and never owns one. Until now there was no id to cite.
GT-654 — three services, three shapes of
/healthcore-api{success, data: {status: "OK", …}, meta}mcp{"status":"ok","transport":"http","protocol":"mcp","probe":"health"}agent-runtime{"status":"ok","service":"agent-runtime-api","version":"0.1.0",…}The nesting differs and so does the case. Not academic: on 2026-08-03 a cross-cluster probe matched
"status":"ok"literally and reported two healthy services as unreachable while they were serving.Registered as a decision before it is work. The envelope is the Core's stated contract, so "all three adopt it" is the obvious answer — and it is not free:
/healthis what a Kubernetes probe and a load balancer read, and those are configured against today's shape. Whichever way it goes, the resolution is a written decision followed by the surfaces obeying it, not three services quietly converging.GT-655 — four operations declared everywhere, invoked nowhere
satellite-create·pattern-list·pattern-get·pattern-list-by-topologyAll four are
exposed: trueon CLI, MCP and REST in the parity matrix, and the exploration harness has no binding for any of them — 48 of 73 operations carry one; these four do not, and no captured response exists for them on any surface.The matrix asserts they exist in three places and nothing has ever asked them to prove it. The harness reports them honestly in
uncoveredTriangleOpsrather than rounding them away — but reporting is not covering.satellite-createis why a binding is not trivial: it provisions a live GitHub repository and writes the local registry (satellite-create.tool.ts:219), so exercising it needs an effect the harness can undo, or a dry-run path it can trust. Its acceptance criterion allows an explicit exemption with a written reason — an untestable operation that says nothing about itself is worse than one declared untestable.Measured before writing, not read
uncoveredTriangleOpsin acoverage.jsonre-generated today vianpm run test:exploration;bindings.ts;/healthpayloads from the live services on their node ports.ci-runner.mjs governance46-validate-derived-artifact-order49-validate-gap-id-allocationorigin/maingitleaks dir .🤖 Generated with Claude Code