api-design
FreeBest practices for designing CosmWasm smart contract APIs. Use when defining message types, designing execute/query interfaces, or optimizing API ergonomics.
The English summary is being prepared. Showing the original description.
Domain-driven modeling patterns for Axone contracts. Use when introducing domain concepts, encoding invariants, or deciding boundaries between domain, handlers, services, gateways, queries, and state.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Keep business invariants in explicit domain types instead of scattering them across handlers, query builders, or storage code.
domain/ owns business concepts and invariants.handlers/ decode messages, orchestrate use cases, and shape responses.services/ compose domain logic with environment-dependent enrichment or cross-module coordination.gateway/ isolates external module interaction and protocol-specific I/O.queries/ build external query payloads or request strings; they should not become the home of business rules.state/ persists data and reconstructs domain values; it should not silently redefine domain invariants.new or try_new that reject invalid states up front.TryFrom when validating a parsed or transport-level representation into a domain type.from_state.Case::new and TryFrom<Term> validate that a case is a ground Prolog dict before it can circulate as a domain object.Constitution::try_new validates UTF-8, required predicates, and engine feedback before a constitution exists as a valid domain value.Constitution::from_state reconstructs a previously validated value from storage without re-running external validation.Decision::new captures an immutable decision snapshot from already validated inputs.Authority::new canonicalizes a bech32 account into the DID form exposed by the contract.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Best practices for designing CosmWasm smart contract APIs. Use when defining message types, designing execute/query interfaces, or optimizing API ergonomics.
The English summary is being prepared. Showing the original description.
Guide for writing Rust doc comments that produce accurate generated contract documentation. Use when editing Instantiate/Execute/Query/Response types or any public schema-facing API.
The English summary is being prepared. Showing the original description.
Guide for writing conventional commit messages. Use when committing changes, writing commit messages, or reviewing commit history.
The English summary is being prepared. Showing the original description.
Axone contract structure and Abstract SDK patterns. Use when scaffolding or refactoring contracts, deciding layer boundaries, wiring AppContract entrypoints, or adding module metadata and replies.
The English summary is being prepared. Showing the original description.
Axone deployment workflows with cargo-make, cw-orch, and Abstract. Use when publishing modules, installing them on accounts, running local chain tasks, or inspecting deployments.
The English summary is being prepared. Showing the original description.
Guide for regenerating Axone contract schemas and rendered Markdown docs. Use when contract APIs or metadata change, when checking generated-doc drift, or when preparing documentation commits.
The English summary is being prepared. Showing the original description.