Skip to content

docs(gaps): register GT-654 and GT-655 — two findings that had nowhere to live - #429

Merged
beyondnetPeru merged 1 commit into
developfrom
docs/register-gt-654-655
Aug 4, 2026
Merged

docs(gaps): register GT-654 and GT-655 — two findings that had nowhere to live#429
beyondnetPeru merged 1 commit into
developfrom
docs/register-gt-654-655

Conversation

@beyondnetPeru

Copy link
Copy Markdown
Contributor

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 /health

Service Response
core-api ADR-0073 envelope — {success, data: {status: "OK", …}, meta}
mcp bare — {"status":"ok","transport":"http","protocol":"mcp","probe":"health"}
agent-runtime bare — {"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: /health is 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-topology

All four are exposed: true on 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 uncoveredTriangleOps rather than rounding them away — but reporting is not covering.

satellite-create is 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

  • the four ids from uncoveredTriangleOps in a coverage.json re-generated today via npm run test:exploration;
  • the absent bindings from bindings.ts;
  • the three /health payloads from the live services on their node ports.
Guard Result
ci-runner.mjs governance ✅ 17 scripts · 653 gaps EN/ES · 629/629 catalog sections
46-validate-derived-artifact-order ✅ chain current and at a fixed point
49-validate-gap-id-allocation ✅ 531 ids, 0 collisions vs origin/main
gitleaks dir . ✅ exit 0

🤖 Generated with Claude Code

…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>
@beyondnetPeru
beyondnetPeru requested a review from a team as a code owner August 4, 2026 19:52
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown

📊 Bilingual Coverage Impact

PR Changes

  • Paired EN/ES files modified: 3
  • New EN files needing ES translation: 0

Repository Coverage

Metric Value
Total EN files 527
Total ES files 501
Paired files 0
Coverage 0%

Good: All EN changes have ES counterparts.


Generated by GitHub Actions

@beyondnetPeru
beyondnetPeru merged commit a6d3c54 into develop Aug 4, 2026
32 checks passed
@beyondnetPeru
beyondnetPeru deleted the docs/register-gt-654-655 branch August 4, 2026 20:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant