guardian-contract-change

Propagate Guardian server contract changes across Rust and TypeScript clients, SDKs, examples, and docs.

Updated Aug 20, 2026
One-click install
npx skills add https://github.com/hduoc2003/leviathan-guardian --skill guardian-contract-change-hduoc2003
Or copy as Structured Prompt for Agentā–¼
Please help me install this Agent Skill.
Skill: guardian-contract-change
Source: https://github.com/hduoc2003/leviathan-guardian/tree/main/.agents/skills/guardian-contract-change
Command: npx skills add https://github.com/hduoc2003/leviathan-guardian --skill guardian-contract-change-hduoc2003

SYSTEM DOCUMENTATION & REQUIREMENTS

šŸ’” This Skill includes references (resource) components.

What problem does it solve? Changing the Guardian server contract (gRPC proto, HTTP JSON payloads, status enums, auth requirements) without updating every downstream consumer leads to broken clients, mismatched semantics between Rust and TypeScript SDKs, and stale documentation. This Skill enforces a server-first propagation workflow so contract changes stay consistent across the entire repository. ## Core Features & Use Cases - Server-first workflow: Classifies the change as gRPC-only, HTTP-only, or shared behavior, then updates guardian.proto or the HTTP/service modules before touching any client. - Cross-stack propagation: Guides updates through the Rust client, TypeScript client (server-types.ts, conversion.ts, http.ts), both multisig SDKs, examples, and docs. - Guardrails and validation: Flags high-risk changes (auth, proposal status, JSON optionality), forbids permissive parsing fallbacks, and defines a minimum test set (cargo test -p guardian-server, cargo test -p guardian-client, guardian-client npm tests) with expansion rules. - Use Case: You add a field to a proposal response in guardian.proto. The Skill walks you through updating the Rust client mappings, TypeScript conversion layer, multisig SDK proposal handling, example harnesses, and the matching spec/docs, then reports every surface touched. ## Quick Start Use the guardian-contract-change skill to propagate my change to guardian.proto across the server, both clients, the multisig SDKs, examples, and docs.

Frequently Asked Questions about guardian-contract-change

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I update the Guardian API contract across server and clients?ā–¼

Update the server contract source first (guardian.proto for gRPC or http.rs for HTTP JSON), then propagate outward to the Rust client, TypeScript client, multisig SDKs, examples, and docs. Never infer the contract from client adapters.

What files define the Guardian server contract?ā–¼

The primary sources are crates/server/proto/guardian.proto, crates/server/src/api/http.rs, crates/server/src/api/grpc.rs, and the backing service and domain modules. The references/contract-surfaces.md file maps every downstream consumer.

When do Guardian contract changes affect the multisig SDKs?ā–¼

Multisig SDKs must be updated when proposal metadata, proposal status semantics, ack data, or state fields used by multisig sync change. Both the Rust miden-multisig-client and the TypeScript package must be inspected.

Which tests should I run after a Guardian contract change?ā–¼

The minimum set is cargo test -p guardian-server, cargo test -p guardian-client, and npm test in packages/guardian-client. Expand to multisig client tests, demo tests, and smoke-web typecheck/build when the change crosses layers.

What contract changes are considered high-risk in Guardian?ā–¼

Auth changes, proposal status changes, and JSON field optionality changes are treated as high-risk. These require expanded validation and must keep Rust and TypeScript client semantics aligned without permissive parsing fallbacks.