-
Notifications
You must be signed in to change notification settings - Fork 19
chore(copilot): level up copilot #726
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughAdds a new documentation file (.github/copilot-instructions.md) detailing the AXONE CosmWasm smart contract ecosystem, development workflow, project structure, patterns, testing strategy, dependencies, security practices, and governance/migration guidance. No source code or public API changes. Changes
Sequence Diagram(s)sequenceDiagram
actor Dev as Developer
participant DV as axone-dataverse
participant CG as axone-cognitarium
participant LS as axone-law-stone
participant OB as axone-objectarium
Dev->>DV: Execute (orchestrate protocol action)
DV->>LS: Query/Execute governance rules
LS->>OB: Persist/retrieve immutable governance artifacts
DV->>CG: SPARQL/semantic queries over triples
CG-->>DV: Query results
LS-->>DV: Rule evaluation outcome
DV-->>Dev: Result/ack
sequenceDiagram
actor Dev as Developer
participant OB as axone-objectarium
participant LS as axone-law-stone
Dev->>LS: Update governance rules (execute)
LS->>OB: Store new rule set (immutable)
OB-->>LS: Content address (CID)
LS-->>Dev: Confirmation with CID
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
Codecov Report✅ All modified and coverable lines are covered by tests. 🚀 New features to boost your workflow:
|
size-limit report 📦
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Nitpick comments (15)
.github/copilot-instructions.md (15)
1-3: Solid kickoff. Consider adding “how Copilot should behave” guardrails.Recommend a short paragraph instructing Copilot to prefer repo-local patterns, avoid inventing APIs, and ask for missing context. This improves suggestion quality and reduces hallucinations.
Apply this diff to append explicit guidance for Copilot behavior:
You are an expert in Cosmos blockchain, specializing in CometBFT, Cosmos SDK, CosmWasm, IBC, CosmJS, and related technologies. Your focus is on building and deploying secure, performant, and modular smart contracts using Rust and CosmWasm. + +When drafting code or docs: +- Prefer patterns and APIs already present in this repository; don’t invent types or modules. +- If a requirement is unclear, propose options and ask for clarification rather than guessing. +- Favor small, composable changes that match existing style and error-handling patterns.
7-15: Clarify the execution model for “Prolog-based governance” and how it evolves.It’s unclear whether Prolog rules execute on-chain (via an embedded interpreter), off-chain, or are purely persisted for off-chain evaluation. Also, if “immutable,” how does governance change over time? Add 2–3 sentences to avoid confusion.
Proposed insertion after the architectural pattern line:
**Key Architectural Pattern**: Contracts are interdependent - dataverse orchestrates the ecosystem, law-stone stores governance in objectarium, and cognitarium provides semantic querying capabilities. + +Note on governance rules: +- Law-stone persists rules as immutable artifacts; governance updates are modeled as new, versioned rule-sets (previous versions remain addressable/auditable). +- Rule evaluation is performed [specify: on-chain interpreter / off-chain service], with contract(s) enforcing outcomes via typed messages. Document the authoritative enforcement path.If helpful, I can draft a short “Governance Versioning” subsection referencing message flows. Do you want me to add that?
28-40: Document destructive/local-only chain tasks and expected environment.Add a caution that chain-initialize/chain-start may wipe local state and are intended for local development only. If stop/reset tasks exist, include them to present a full lifecycle.
Suggested addition:
# Interact with contracts cargo make chain <axoned-cli-command> + +Note: +- These tasks operate on a local development chain and may reset state. Use dedicated dev wallets and chain IDs. +- If available, see also: `cargo make chain-stop`, `cargo make chain-reset`.To confirm availability, run the verification script in my previous comment.
61-65: Message types: add derives and compatibility guidance.Copilot benefits from explicit derives and stability guidance for Msg types.
Append:
- Each contract exports these via `msg.rs` +- Derive `Serialize`, `Deserialize`, `Clone`, `Debug`, and `JsonSchema` on all message types. +- Maintain backward compatibility where possible; adding optional fields should use defaults to avoid breaking clients. +- Regenerate and commit JSON schemas after any Msg change (`cargo make schema`).
68-71: State management: add pagination and naming conventions; mention cw2 state versioning.Pagination and consistent keys reduce gas and improve UX. cw2 should be tied to storage evolution.
Proposed augmentation:
- State defined in `state.rs` with typed storage items - Example: `pub const STORE: Item<Store> = Item::new("store");` +- Prefer `Map`/`IndexedMap` with explicit key spaces. Use predictable, namespaced keys (e.g., `"config"`, `"rule/{id}"`). +- Expose paginated queries with `start_after` and `limit` parameters; avoid unbounded iteration. +- Track storage schema version with `cw2` and bump `CONTRACT_VERSION` on breaking state changes.
74-77: Error handling: includeensure!-style checks and mapping to ContractError.This sharpens validations and centralizes failures.
Append:
- Use `ContractError` enum for all contract-specific errors - Validate all user inputs and apply strict access control +- Use helpers like `cw_utils::ensure!` and map errors to `ContractError` for consistent propagation. +- Prefer early returns on invalid state (e.g., unauthorized, out-of-range) to minimize code paths.
80-84: Prefer Addr; avoid CanonicalAddr unless absolutely necessary.In modern CosmWasm, store validated
Addrand usedeps.api.addr_validatefor inputs. CanonicalAddr is rarely needed and complicates portability.Apply this wording change:
-- Use `MessageInfo.sender`, `Addr`, and `CanonicalAddr` properly +- Use `MessageInfo.sender` and validated `Addr` (`deps.api.addr_validate(...)`). Avoid `CanonicalAddr` unless a specific chain requirement mandates it.
96-100: Specify content addressing details (hash algorithm, encoding) and pinning semantics.Documenting the exact digest (e.g., SHA-256, multihash) and how “pinning” interacts with GC is important for interoperability.
Proposed addition:
- **Pinning mechanism** prevents garbage collection - Content-addressed by cryptographic hash + - Specify: algorithm (e.g., SHA-256 / multihash), encoding (hex/base64), and collision policy. + - Define GC behavior (retention policy, TTLs) and how pin/unpin affects lifecycle.
103-106: Reconcile “immutable” rules with governance evolution.If rules are immutable, clarify update pattern (new versioned artifacts + registry pointer) and who can advance pointers.
Append:
- Immutable - can only be queried, never updated - Depends on objectarium for reliable rule persistence + - Governance updates create new immutable rule-sets; an authorized registry entry points to the “active” version. Old versions remain auditable.
109-112: Cross-contract communication: mention typed clients and reply handling.Add guidance on using typed clients (e.g., cw-orch) and safe SubMsg replies.
Proposed augmentation:
- Contracts reference each other by **address + interface** - Client packages (`axone-*-client`) provide typed interfaces - Example: law-stone pins rules in objectarium, dataverse queries cognitarium +- Prefer typed clients (e.g., `cw-orch` or generated clients) to avoid fragile stringly-typed calls. +- Use `SubMsg` with `reply_on_success` and implement `reply()` to safely handle asynchronous results; avoid re-entrancy-like double effects in replies.
115-132: Testing: include cw-multi-test and invariants.Integration with
cw_multi_testsimplifies realistic scenarios; invariants catch regressions early.Append to Unit/Integration/E2E sections:
- Use `cosmwasm-std::testing` mocks - Test contract entry points with mock dependencies +- For integration, prefer `cw_multi_test` to exercise instantiate/execute/query flows with multiple contracts. +- Add invariant tests (e.g., total supply conservation, monotonic indices) alongside functional tests.
135-139: Add a “version matrix” for reproducible builds.Pinning toolchain and crate versions helps Copilot and humans stay consistent.
Append:
- **Build**: `cargo-make` for task automation, `cosmwasm-optimizer` for WASM builds + +Version matrix (keep updated): +- Rust toolchain: (e.g., 1.78) via `rust-toolchain.toml` +- CosmWasm: (e.g., cosmwasm-std = "1.x", cosmwasm-schema = "1.x") +- cw-plus crates: versions aligned across contracts +- Node/npm (if applicable): for client packages and scripts
142-149: Common pitfalls: explicitly call out unbounded iteration.This is a frequent issue in CosmWasm contracts.
Apply this addition:
- Optimize for low gas usage - avoid redundant state reads/writes - Maintain separation of concerns in commits following Conventional Commits +- Avoid unbounded iteration over storage; always paginate queries and bounded loops by `limit`.
152-155: Migrations: include cw2 version bump and minimal migrate skeleton.Provide a short template to guide implementation.
Append:
- Place migration logic in the contract module and document any required state transitions. - Always test migrations thoroughly before deploying to mainnet. + +Minimal pattern: +```rust +#[cfg_attr(not(feature = "library"), entry_point)] +pub fn migrate(deps: DepsMut, _env: Env, _msg: MigrateMsg) -> Result<Response, ContractError> { + let ver = cw2::get_contract_version(deps.storage)?; + // Perform state transformations based on ver + cw2::set_contract_version(deps.storage, CONTRACT_NAME, CONTRACT_VERSION)?; + Ok(Response::default()) +} +```
158-171: Minor editorial pass: consistent punctuation in list items.Several bullets mix terminal punctuation styles. Standardizing (either all periods or none) improves readability and avoids grammar lint noise.
If desired, I can run a quick pass to normalize punctuation and submit a separate docs-only PR.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
.github/copilot-instructions.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
.github/copilot-instructions.md
[grammar] ~9-~9: There might be a mistake here.
Context: ...utable object storage (foundation layer) - axone-cognitarium: RDF/semantic triple storage with SPARQ...
(QB_NEW_EN)
[grammar] ~10-~10: There might be a mistake here.
Context: ...ntic triple storage with SPARQL querying - axone-law-stone: Prolog-based governance rules (depends...
(QB_NEW_EN)
[grammar] ~11-~11: There might be a mistake here.
Context: ...(depends on objectarium for persistence) - axone-dataverse: Protocol orchestrator (depends on cogn...
(QB_NEW_EN)
[grammar] ~20-~20: There might be a mistake here.
Context: ...argo make(NOT standard cargo commands) - **WASM compilation**:cargo make wasm` (p...
(QB_NEW_EN)
[grammar] ~21-~21: There might be a mistake here.
Context: ...ASM in target/wasm32-unknown-unknown/) - Testing: cargo make test-coverage - ...
(QB_NEW_EN)
[grammar] ~22-~22: There might be a mistake here.
Context: ...asm32-unknown-unknown/) - **Testing**: cargo make test-coverage- **Linting**:cargo make lint` (uses crank...
(QB_NEW_EN)
[grammar] ~23-~23: There might be a mistake here.
Context: ...ake lint(uses cranky + custom linters) - **Schema generation**:cargo make schema`...
(QB_NEW_EN)
[grammar] ~44-~44: There might be a mistake here.
Context: ...ts/axone-*/: Individual smart contracts - packages/`: Shared libraries and client code - Eac...
(QB_NEW_EN)
[grammar] ~45-~45: There might be a mistake here.
Context: ...ages/: Shared libraries and client code - Each contract has: src/, schema/, e...
(QB_NEW_EN)
[grammar] ~61-~61: There might be a mistake here.
Context: ...InstantiateMsg: Contract initialization - ExecuteMsg: State-changing operations - QueryMsg`...
(QB_NEW_EN)
[grammar] ~62-~62: There might be a mistake here.
Context: ... ExecuteMsg: State-changing operations - QueryMsg: Read-only queries - Each contract expo...
(QB_NEW_EN)
[grammar] ~63-~63: There might be a mistake here.
Context: ...erations - QueryMsg: Read-only queries - Each contract exports these via msg.rs...
(QB_NEW_EN)
[grammar] ~90-~90: There might be a mistake here.
Context: ...ats: Turtle, N-Triples, RDF/XML, N-Quads - Query language: SPARQL variant (not ...
(QB_NEW_EN)
[grammar] ~91-~91: There might be a mistake here.
Context: ...e: SPARQL variant (not standard SQL) - Namespaces/prefixes are crucial for RDF ...
(QB_NEW_EN)
[grammar] ~103-~103: There might be a mistake here.
Context: ...* (not typical smart contract languages) - Immutable - can only be queried, never updated - ...
(QB_NEW_EN)
[grammar] ~104-~104: There might be a mistake here.
Context: ...ble - can only be queried, never updated - Depends on objectarium for reliable rule...
(QB_NEW_EN)
[grammar] ~135-~135: There might be a mistake here.
Context: ...encies - CosmWasm: cosmwasm-std, cosmwasm-schema - Storage: cw-storage-plus, cw2 - **...
(QB_NEW_EN)
[grammar] ~136-~136: There might be a mistake here.
Context: ...hema- **Storage**:cw-storage-plus, cw2` - AXONE-specific: Custom packages for RD...
(QB_NEW_EN)
[grammar] ~137-~137: There might be a mistake here.
Context: ... Custom packages for RDF, logic bindings - Build: cargo-make for task automatio...
(QB_NEW_EN)
[grammar] ~143-~143: There might be a mistake here.
Context: ...ma` and commit the updated JSON schemas.** - Each contract needs individual deploymen...
(QB_NEW_EN)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: check-docs-updated
- GitHub Check: check-contracts
- GitHub Check: report-wasm-size
- GitHub Check: build-wasm
- GitHub Check: test-rust
🔇 Additional comments (1)
.github/copilot-instructions.md (1)
1-180: Overall: Excellent, actionable Copilot playbook.This is a high-signal document covering architecture, workflows, and quality bars. With the small clarifications above and a couple of concrete code snippets, it will materially improve Copilot’s output and team onboarding.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
|
@coderabbitai resolve |
✅ Actions performedComments resolved and changes approved. |
Taught Copilot a thing or two about this repo.
Summary by CodeRabbit