ZeroClaw

ZeroClaw finds a missing verifier above intent constraints

A ZeroClaw report says verifiable-intent checks caller-supplied constraints against caller-supplied fulfillment without first verifying the credential chain. Two related records show the project tightening policy language: protected documentation literals need context, and test-only changes in high-risk paths need deterministic review precedence.

← Back to homeOriginal source ↗

zeroclaw-labs/zeroclaw issue #9328 is the inspected primary source: “[Bug]: verifiable-intent evaluates constraints without verifying the credential chain.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- zeroclaw-labs/zeroclaw issue #9328 was created 2026-07-24T04:12:48Z and was open at inspection; its title is “[Bug]: verifiable-intent evaluates constraints without verifying the credential chain.” - zeroclaw-labs/zeroclaw PR #9659 was created 2026-08-02T19:05:04Z and was open at inspection; its title is “fix(docs): disambiguate contextual protected literals.” - zeroclaw-labs/zeroclaw issue #9530 was created 2026-07-29T08:59:14Z and was open at inspection; its title is “RFC: Define risk precedence for test-only changes in high-risk paths.” - The repository reported 32525 stars, 706 open issues, default branch master, and last push 2026-08-07T00:59:04Z. - The latest tagged-release baseline checked was v0.8.4 published 2026-08-02T21:00:00Z.

What changed

zeroclaw-labs/zeroclaw issue #9328 reports: vi_verify's evaluate_constraints checks L2 constraints against a fulfillment object, and both come from the caller. In the VI reference implementation, check_constraints only runs on values a chain verifier has already established cryptographically. src/verifiable_intent/verification/chain.py (about 1,000 lines) verifies the ES256 signatures across L1, L2 and L3, the sd_hash bindings between layers, the mandate pairing for Immediate and Autonomous modes, the VCT and typ headers, and the cnf presence rules. Only then are constraints checked. ZeroClaw has issuance, crypto, types and verification, but no chain verifier. CredentialChain is declared in crates/zeroclaw-runtime/src/verifiable_intent/types.rs and nothing populates it. So evaluate_constraints checks caller-supplied constraints against a caller-supplied fulfillment, with a model in the caller position. The reachable consequence, an empty {} fulfillment satisfying allowed_merchant or allowed_payee, is fixed in #9327 by failing closed on an absent subject. That closes the constraint checker. This issue is about the verification layer that should

zeroclaw-labs/zeroclaw PR #9659 reports: Summary **Base branch:** master **What changed and why:** Treat ambiguous registry display names such as Signal and Filesystem as protected literals only when the source entry supplies product context. Preserve standalone product labels, known identifiers, matching Markdown channel links, nearby channel-specific nouns within the same table cell, adjacent product-list peers, and the actual delayed filesystem watcher catalog shape while allowing ordinary prose to be translated. Rename two generic table headers to Condition and Routing signal, plus the generic sandbox heading to File access, so gettext no longer merges those uses into standalone product-label entries. Add regressions for generic prose and link labels, actual catalog references, Markdown links, distant list peers, table-cell boundaries, identifiers, possessives, and hyphenated references. **Scope boundary:** This PR does not change registry data, translation catalogs, or matching for unambiguous protected terms. **Blast radius:** The shared mdBook protected-literal matcher used by translation prompting

zeroclaw-labs/zeroclaw issue #9530 reports: Problem The current maintainer and contributor docs give conflicting guidance for test-only changes inside high-risk source paths. docs/book/src/maintainers/labels.md is the canonical operational risk-label source. It defines risk:low as “No high-risk paths touched, small change,” defines risk:high as “Touches a high-risk path,” and includes crates/zeroclaw-runtime/src/** in the canonical high-risk path set. At the same time: docs/book/src/maintainers/pr-workflow.md says small tests that leave behavior unchanged belong in the maintenance fast lane and are usually risk:low. docs/book/src/maintainers/reviewer-playbook.md lists tests under risk:low, while also mapping the canonical high-risk path set to risk:high. docs/book/src/contributing/agent-guidelines.md describes tests without behavior changes as low risk. 9522 is a concrete example. It changes only #[cfg(test)] code inside crates/zeroclaw-runtime/src/agent/loop_.rs to repair an intermittent parallel-test failure. No production code is compiled differently. The maintenance-lane guidance points toward risk:low, but the canonical path rule points toward risk:high. Either classification can be a defensible policy. The docs do not

Why it matters

Failing closed on an empty subject fixes one constraint edge, not the absent signature and binding layer above it. The feature is disabled by default, which limits current exposure but does not turn a latent payment-policy gap into proof. The operator test is whether authority, persisted state and the visible outcome still describe the same event after retries, restarts or delegation.

Current

The primary record was open when captured on 2026-08-07. The release baseline was v0.8.4 published 2026-08-02T21:00:00Z. Repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts row were checked. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/zeroclaw-labs/zeroclaw/issues/9328. Supporting records are https://github.com/zeroclaw-labs/zeroclaw/pull/9659 and https://github.com/zeroclaw-labs/zeroclaw/issues/9530. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Keep the feature off until chain verification establishes signatures, hashes, mandate pairing and headers; make automated risk labels report-only when evidence is ambiguous. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.