Gear gstd API Map

Goal

Keep design work API-first: start from gstd, then drop to gcore or gsys only when you need to confirm limits, gas shape, or low-level behavior.

Inputs

• ../../references/gear-execution-model.md — execution model and block lifecycle
• ../../references/gear-messaging-and-replies.md — message flow and reply semantics
• ../../references/gear-gas-reservations-and-waitlist.md — gas reservations and waitlist
• ../../references/gear-gstd-api-and-syscalls.md — full API surface and syscall mapping

Route Here When

• a spec or architecture note needs to know whether a Gear program can send, await replies, self-schedule, reserve gas, or create child programs
• a builder is choosing between typed payloads, raw bytes, staged push-plus-commit, or input-forwarding APIs
• a design depends on #[gstd::async_main], _for_reply flows, delayed work, ReservationId, or prog::*
• a debugging pass needs to confirm which gr_* syscall family a high-level API actually reaches