Skip to content

feat(chat): the maintainer grounding-tool registry, read-only by construction - #10099

Merged
JSONbored merged 1 commit into
mainfrom
feat/maintainer-grounding-registry-9189
Jul 31, 2026
Merged

feat(chat): the maintainer grounding-tool registry, read-only by construction#10099
JSONbored merged 1 commit into
mainfrom
feat/maintainer-grounding-registry-9189

Conversation

@JSONbored

Copy link
Copy Markdown
Owner

First half of #9189 — the grounding catalog #9187's spec confirmed. Six read-only tools returning deterministic JSON from state ORB already holds.

This does not close #9189. Binding GroundingServices to the real readers and wiring the protected route with its authz is the second half, and it deserves its own pass rather than riding along here. Registered in STAGED_AHEAD_OF_CONSUMERS with that reason, which is the mechanism the repo provides for a seam landed ahead of its callers.

Read-only is enforced, not promised

GroundingServices is the tools' entire capability surface, and it holds no Octokit, no token, no mutation. A tool cannot write because there is nothing in scope to write with.

Two tests assert that as a property of the source, not of a runtime object:

  • the interface declaration names no write capability
  • the module imports nothing at all — a tool reaching for its own Octokit would bypass the injected surface entirely

Redaction is structural, and the test proves it is not a blocklist

Every response is built by naming its fields. The distinguishing test feeds each service a payload carrying walletAddress, hotkey, rewardValue, trustScore, privateRanking and authorEmail, then asserts none reaches the serialized result. A blocklist must anticipate every field an upstream type might grow; an allowlisted shape cannot leak one nobody wrote down.

The accuracy union passes through whole rather than flattened — coverage and interval are what make it a claim rather than marketing (requirement 6). That is also why fairness_summary reuses buildProofSummary instead of aggregating again: chat and /proof cannot disagree about a number they compute once.

Determinism

Identical state produces identical bytes, so a retry does not re-ground the model differently and a cache means something. Every list sorts on a stable key; one test drives the same service returning a set in reversed order and asserts the bytes match.

An absent source reports available: false — never an error, never a zero. A deployment without a ledger is not a broken one, and an empty queue would read as "nothing to do".

Two tools deliberately absent

decision_record_by_digest and audit_tail have no reader today — the nearest are loadDecisionRecordCollapsible (by pull number) and the public ledger row endpoint (by sequence). Shipping them would mean inventing SQL inside a chat PR, which requirement 1 explicitly rules out. Recorded on the issue with options; each needs its own authz and redaction review.

Mutation testing

Mutation Result
Spread the config object instead of naming fields 3 failed
Drop a stable sort 2 failed
Flatten accuracy to a bare number 2 failed

Verification

  • 16 new tests; full test/unit suite 25,491 passed
  • typecheck, dead-source-files:check, dead-exports:check, checkers-wired:check, coverage-boltons:check, ui:lint, import-specifiers:check, fixture-clock-races:check, validate:no-hand-written-js green

Refs #9189

…truction

First half of #9189, implementing the catalog #9187's spec confirmed. Six tools
that return deterministic JSON read from state ORB already holds -- grounding,
not generation: a maintainer asking "why is this PR held" gets the recorded
verdict, not a paraphrase of one.

READ-ONLY IS ENFORCED, NOT PROMISED. GroundingServices is the tools' ENTIRE
capability surface, and it holds no Octokit, no token and no mutation. A tool
cannot perform a write because there is nothing in scope to write with. Two tests
assert that as a property of the source rather than of a runtime object: the
interface names no write capability, and the module imports nothing at all -- a
tool that reached for its own Octokit would bypass the injected surface entirely.

REDACTION IS STRUCTURAL. Every response is built by NAMING its fields. The test
that distinguishes this from a blocklist feeds each service a payload carrying
walletAddress, hotkey, rewardValue, trustScore, privateRanking and authorEmail,
and asserts none reaches the serialized result. A blocklist has to anticipate
every field an upstream type might grow; an allowlisted shape cannot leak one
nobody wrote down.

The accuracy union passes through WHOLE rather than being flattened -- coverage
and interval are what make it a claim rather than marketing, which is why
fairness_summary reuses buildProofSummary instead of aggregating again, and why
chat and /proof cannot disagree about a number.

DETERMINISM: identical state produces identical BYTES, so a retry does not
re-ground the model differently and a cache means something. Every list is sorted
on a stable key; a test drives the same service returning a set in reversed order
and asserts the bytes match.

An absent source reports `available: false`, never an error and never a zero. A
deployment without a ledger is not a broken one, and an empty queue would read as
"nothing to do".

Two of the spec's eight candidate tools are deliberately ABSENT.
decision_record_by_digest and audit_tail have no reader today -- the nearest are
by pull number and by sequence respectively -- so shipping them would mean
inventing SQL inside a chat PR, which requirement 1 rules out. Recorded on the
issue with options; each needs its own authz and redaction review.

Registered in STAGED_AHEAD_OF_CONSUMERS because this is a seam landed ahead of
its callers: binding GroundingServices to the real readers and wiring the
protected route with its authz is the second half of #9189, and it deserves its
own pass rather than riding along here.

Mutation-tested: spreading the config object instead of naming fields fails 3,
dropping a sort fails 2, flattening accuracy to a bare number fails 2.

Refs #9189
@loopover-orb

loopover-orb Bot commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

Caution

🛑 LoopOver review result - fixes required

Review updated: 2026-07-31 07:33:10 UTC

3 files · 1 AI reviewer · no blockers · CI failing · unstable

🛑 Suggested Action - Manual Review

Review summary
This adds a self-contained, read-only grounding-tool registry (src/chat/grounding-registry.ts) with six deterministic tools over an injected GroundingServices interface, plus a comprehensive invariant test suite proving no-write, structural redaction, and byte-determinism. It correctly registers itself in STAGED_AHEAD_OF_CONSUMERS since the PR explicitly does not wire the real service implementations or the protected route, deferring that (and its authz) to a stated second PR. The code is well-structured, the tests exercise the real exported functions against realistic fixtures, and the registry's shape (allowlisted response construction, per-tool budgets, stable sorting) matches its stated invariants.

Nits — 6 non-blocking
  • src/chat/grounding-registry.ts: budgetTokens values (2000, 500, 1500, 1000) are magic numbers with no named constants or documented rationale for why each tool gets its specific ceiling.
  • test/unit/grounding-registry.test.ts: the 'no write capability' test greps for substrings like 'token'/'write' in a source slice, which is brittle — a legitimately named read-only field (e.g. a future `tokenBudget`) would false-positive.
  • The codecov/patch check failed at 88.46% vs 99% target; given the repo's stated coverage discipline this should be closed before merge even though the test suite here looks otherwise thorough.
  • src/chat/grounding-registry.ts:145 repo_settings has depth-5 nesting per static analysis — could be flattened for readability but is not a correctness issue.
  • Add a short comment near the budgetTokens literals explaining the relative sizing intent (e.g. queue_snapshot/effective_config carry more fields hence higher ceiling) to preempt the magic-number nit.
  • PR author also opened the linked issue — Link an issue that was opened by a different contributor, or provide a rationale for why this self-authored issue represents genuine discovery work.

CI checks failing

  • codecov/patch — 88.46% of diff hit (target 99.00%)

Decision drivers

  • ✅ Code review — No blockers (1 reviewer)
  • ✅ Gate result — Passing (No configured blocker found.)
Context & advisory signals — never blocks the verdict
Signal Result Evidence
Linked issue ✅ Linked #9189
Related work ✅ No active overlap found No same-issue or scoped active PR overlap found.
Change scope ✅ 20/20 Low review scope from cached public metadata (1 linked issue).
Validation posture ✅ 25/25 PR body includes validation/test evidence.
Contributor workload ✅ 10/10 Author activity: 9 registered-repo PR(s), 8 merged, 355 issue(s).
Contributor context ✅ Confirmed Gittensor contributor JSONbored; Gittensor profile; 9 PR(s), 355 issue(s).
Improvement ✅ Minor risk: clean · value: minor
Linked issue satisfaction

Partially addressed
The PR delivers a well-tested read-only tool registry with structural redaction, determinism, and a zero-writes invariant, but explicitly does not implement per-repo authz enforcement, route wiring, or the feature flag deliverable that the issue requires ("authz on every call" and "route wiring on the protected API, feature-flagged off by default" are deferred to a second PR), and only implements

Review context
  • Author: JSONbored
  • Role context: owner (maintainer lane)
  • Public audience mode: oss maintainer
  • Lane context: Repository is configured for direct PR review.
  • Public profile languages: Python, TypeScript, Ruby, Go, MDX, Shell, Solidity, JavaScript
  • Official Gittensor activity: 9 PR(s), 355 issue(s).
  • PR-specific overlap: none found.
Contributor next steps
  • Start here: Treat this as maintainer-lane context rather than normal contributor-lane activity.
Signal definitions
  • Related work = same linked issue, overlapping active PRs, or title/path similarity.
  • Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
  • Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
  • Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
  • Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.
🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

  • @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
  • @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
  • A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

Decision record
  • action: hold · clause: success
  • config: 27c5c0452f6c40a85d5c586932d045c7a2fc966c4ee90f32e71ecd0601215df7 · pack: oss-anti-slop · ci: failed
  • record: 44acca10b05193b5b0127907e178d0b686c69e363b93303037b5c0414d0f7625 (schema v6, head 58102c5)

🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed


💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

  • Re-run LoopOver review

@superagent-security

Copy link
Copy Markdown
Contributor

Superagent didn't find any vulnerabilities or security issues in this PR.

@JSONbored JSONbored self-assigned this Jul 31, 2026
@codecov

codecov Bot commented Jul 31, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 88.46154% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.88%. Comparing base (eca3b61) to head (58102c5).
⚠️ Report is 15 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
src/chat/grounding-registry.ts 88.46% 0 Missing and 3 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main   #10099      +/-   ##
==========================================
- Coverage   91.88%   91.88%   -0.01%     
==========================================
  Files         930      931       +1     
  Lines      113839   113865      +26     
  Branches    27470    27479       +9     
==========================================
+ Hits       104600   104623      +23     
  Misses       7940     7940              
- Partials     1299     1302       +3     
Flag Coverage Δ
backend 95.66% <88.46%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
src/chat/grounding-registry.ts 88.46% <88.46%> (ø)

@loopover-orb loopover-orb Bot added the manual-review Gittensor contributor context label Jul 31, 2026
@JSONbored
JSONbored merged commit 9f673b8 into main Jul 31, 2026
7 of 8 checks passed
@JSONbored
JSONbored deleted the feat/maintainer-grounding-registry-9189 branch July 31, 2026 07:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

manual-review Gittensor contributor context

Projects

None yet

Development

Successfully merging this pull request may close these issues.

orb(chat): read-only grounding tool registry over maintainer surfaces — authz and redaction enforced by tests

1 participant