gear-message-execution
Gear Message Execution
Goal
Provide a focused local path for reasoning about message flow and execution behavior in standard Gear/Vara Sails work.
Inputs
../../references/gear-execution-model.md../../references/gear-sails-production-patterns.md../../references/gear-messaging-and-replies.md../../references/gear-gas-reservations-and-waitlist.md../../references/scale-binary-decoding-guide.md
Route Here When
- replies, timeouts, or error replies are surprising
- delayed work spans future blocks
- reservations or waitlist behavior affect the design
- a builder is mixing raw payload handling into an otherwise standard Sails flow
- raw hex, reply bytes, event bytes, or metadata-vs-IDL decoding path is unclear
Working Model
- Confirm what executes now versus after the next block.
- If raw bytes are involved, classify the source first: constructor, service payload, reply, event, full state, or state-function output.
- Determine whether the bytes are Sails-routed, plain SCALE, or metadata-driven state output.
- Match the decoder artifact to the source: generated client or
.idl,ProgramMetadata, orstate.meta.wasm. - Identify whether the path is fire-and-forget, reply-driven, delayed, or reservation-backed.
- Separate transport failure, timeout, and error reply.
- Check whether rollback should revert local state if a send or reply path fails.
- If the path is in tests, confirm the block-advance pattern and expected reply timing.
Guardrails
- Treat reply, timeout, and late hook execution as distinct states.
- Keep staged payload flows paired with their commit step.
- Treat reservation duration and waitlist expiry as architecture constraints.
- Use
exec::gas_available()when checking available gas during the current execution. - Prefer generated Sails clients unless debugging the route or codec layer.
- If a Sails route is involved, expect route-prefixed encoding rather than a raw struct payload.
- Keep the guidance on the standard Gear/Vara Sails path.
- Prefer local repo references over external skill dependencies.
- Do not start with plain
Decode::<T>on arbitrary bytes when a Sails route may be involved. - Match decode artifact to source: generated client or
.idlfor standard Sails interface paths,ProgramMetadatafor full state, andstate.meta.wasmfor state-function output. - Treat
gear-metaas a debugging fallback, not the first-choice default path.
More from gear-foundation/vara-skills
vara-skills
Use when a builder needs the top-level router for the provisional standard Gear/Vara Sails skill pack across Codex, Claude, or OpenClaw. Do not use for Vara.eth or ethexe work, non-Sails programs, or broad protocol research.
197sails-new-app
Use when a builder is starting a new standard Gear/Vara Sails app and needs the correct greenfield sequence before implementation. Do not use for edits to an established repo, Vara.eth or ethexe targets, or non-Sails templates.
2sails-dev-env
Use when a builder needs to prepare or repair a local macOS, Linux, or Windows machine for standard Gear/Vara Sails Rust development before building, testing, or running a local node. Do not use for live-network deployment, app-specific feature work, or Vara.eth/ethexe-only setup.
2vara-wallet
Use when an agent needs to interact with Vara Network on-chain — deploy programs, call Sails methods, manage wallets, transfer tokens, monitor events. Not for building Sails programs (use vara-skills for that).
2sails-gtest
Use when a builder needs the standard Gear/Vara Sails gtest loop for feature verification, debugging, or regression coverage. Do not use for live-network-only validation, deployment-first workflows, or non-Sails programs.
2task-decomposer
Use when approved spec and architecture artifacts must become an ordered implementation plan for Gear or Vara work. Do not use when the architecture is still unsettled or when the request is only asking for a high-level idea.
2