@laitszkin/apollo-toolkit 2.5.0 → 2.6.0

package/AGENTS.md

@@ -32,6 +32,7 @@ This repository enables users to install and run a curated set of reusable agent
 - Users can learn new or improved skills from recent Codex conversation history.
 - Users can audit and maintain the skill catalog itself, including dependency classification and shared-skill extraction decisions.
 - Users can summarize mistakes into a learning error book and render it to PDF.
+- Users can build or review marginfi protocol integrations using official SDK, CLI, protocol, and The Arena documentation.
 - Users can create or maintain `AGENTS.md` so project constraints stay aligned with the repository.
 - Users can turn novel content into a loopable short-form video with generated assets.
 - Users can publish structured GitHub issues or feature proposals with auth fallbacks.
@@ -42,7 +43,9 @@ This repository enables users to install and run a curated set of reusable agent
 - Users can process GitHub pull request review comments and resolve addressed threads.
 - Users can perform repository-wide code reviews and publish confirmed findings as GitHub issues.
 - Users can schedule a bounded project runtime window, stop it automatically, and analyze module health from captured logs.
+- Users can build and maintain Solana programs and Rust clients using official Solana development workflows.
 - Users can add focused observability to opaque workflows through targeted logs, metrics, traces, and tests.
+- Users can build against Jupiter's official Solana swap, token, price, lending, trigger, recurring, and portfolio APIs with an evidence-based development guide.
 - Users can debug software systematically by reproducing causes, validating fixes, and testing outcomes.
 - Users can generate 30-60 second short videos directly from text prompts.
 - Users can prepare and publish versioned releases with changelog and tag workflows.

package/CHANGELOG.md

@@ -4,6 +4,18 @@ All notable changes to this repository are documented in this file.
 
 ## [Unreleased]
 
+## [v2.6.0] - 2026-03-20
+
+### Added
+- Add `jupiter-development` for building Jupiter-based Solana integrations from current official docs, including swap, token, price, lend, trigger, recurring, and portfolio surfaces.
+- Add `marginfi-development` for building or reviewing marginfi integrations with official SDK, CLI, protocol, and The Arena references.
+- Add `solana-development` for native Solana Rust programs and Rust client workflows grounded in official Solana documentation.
+
+### Changed
+- Update `learn-skill-from-conversations` to prefer inventorying the current skill catalog, weighting user corrections and error-driven lessons more heavily, and tightening when to update an existing skill versus creating a new one.
+- Update `codex-memory-manager` so memory reports include already-stored relevant preferences when users ask what memory exists or why a known preference was omitted.
+- Refresh new protocol reference snapshots against current official Jupiter, marginfi, and Solana docs before release.
+
 ## [v2.5.0] - 2026-03-19
 
 ### Changed

package/README.md

@@ -21,8 +21,10 @@ A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer t
 - generate-spec
 - harden-app-security
 - improve-observability
+- jupiter-development
 - learn-skill-from-conversations
 - learning-error-book
+- marginfi-development
 - maintain-project-constraints
 - maintain-skill-catalog
 - novel-to-short-video
@@ -34,6 +36,7 @@ A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer t
 - review-change-set
 - review-codebases
 - scheduled-runtime-health-check
+- solana-development
 - systematic-debug
 - text-to-short-video
 - version-release

package/codex-memory-manager/SKILL.md

@@ -114,6 +114,8 @@ python3 ~/.codex/skills/codex-memory-manager/scripts/sync_memory_index.py \
   - which categories were created or updated
   - whether a new category was introduced
   - whether the AGENTS memory index changed
+- When the user asks what memory exists or asks why a known preference was not mentioned, include the already-stored preferences that are directly relevant to the question instead of summarizing only newly added entries.
+- When a stable preference already existed and was still reinforced by recent chats, say that it remains stored and point to the category where it lives.
 - If no durable preferences were found, say so explicitly and avoid creating placeholder memory files.
 
 ## Guardrails

package/jupiter-development/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: jupiter-development
+description: Build integrations against Jupiter's official Solana APIs and SDKs, including Ultra Swap, Metis Swap, Tokens API V2, Price API V3, Lend, Trigger, Recurring, and Portfolio. Use when implementing Jupiter-based swaps, token search, pricing, lending, DCA, limit-order, or portfolio features, or when updating code that depends on Jupiter official developer docs.
+---
+
+# Jupiter Development
+
+## Dependencies
+
+- Required: none.
+- Conditional: none.
+- Optional: none.
+- Fallback: If official Jupiter docs are unavailable, stop and report the missing source instead of guessing endpoint behavior.
+
+## Standards
+
+- Evidence: Treat `https://dev.jup.ag/llms.txt` and linked official pages as the source of truth; re-check them when the task depends on current API behavior.
+- Execution: Identify the exact Jupiter product first, then implement against the narrowest official API or SDK that fits the job.
+- Quality: Prefer the default happy-path integrations before custom transaction assembly, and call out routing, auth, fee, and rate-limit tradeoffs explicitly.
+- Output: Leave the user with working integration changes plus a short note covering which Jupiter surface was used and which official docs were followed.
+
+## Goal
+
+Implement Jupiter-backed Solana features safely by following the current official developer documentation instead of relying on stale examples or assumptions.
+
+## Required Workflow
+
+### 1) Reconfirm the official surface before coding
+
+- Start from `https://dev.jup.ag/llms.txt` to discover the current product map and page URLs.
+- Read only the product pages needed for the task.
+- If the task depends on exact request or response fields, follow through to the linked API reference or OpenAPI page before editing code.
+
+### 2) Choose the right Jupiter integration path
+
+- For token swaps, default to Ultra Swap.
+  - Use `GET /ultra/v1/order` plus `POST /ultra/v1/execute` for the standard path with the least integration work.
+  - Use Metis Swap only when the app must own quote-to-transaction construction, compose instructions, or integrate through CPI/Flash Fill style flows.
+- For token discovery and token metadata, use Tokens API V2.
+  - Use search for symbol, name, or mint lookup.
+  - Use tag/category/recent endpoints for discovery experiences such as verified lists, trending tokens, or newly tradable assets.
+- For USD token pricing, use Price API V3.
+  - Expect `null` or missing prices for assets that Jupiter considers unreliable.
+  - Do not invent fallback prices without telling the user.
+- For lending, use Jupiter Lend.
+  - Use the REST API for Earn when HTTP access is enough.
+  - Use `@jup-ag/lend` and `@jup-ag/lend-read` when the task needs instruction building, on-chain composition, flashloans, Borrow flows, or read-side analytics.
+- For advanced trading automations, use the product-specific APIs instead of overloading Swap.
+  - Trigger for limit-order and stop-style flows.
+  - Recurring for DCA.
+  - Portfolio for wallet position aggregation.
+
+### 3) Apply Jupiter-specific guardrails while implementing
+
+- Treat Jupiter hostnames and auth rules as time-sensitive.
+  - Current official docs still show some `lite-api.jup.ag` quick-start examples.
+  - Current migration and Portal docs recommend `api.jup.ag` with `x-api-key`.
+  - Reconfirm the exact hostname and auth rule for the chosen product before coding.
+- Respect Jupiter Portal rate limits and keep API keys in configuration rather than source control.
+- Do not add optional swap parameters blindly.
+  - Payer, referral, fee, and router-selection fields can change routing, fee behavior, or gasless support.
+  - Re-read the exact product page before shipping these options.
+- Match the fee model to the integration path.
+  - Ultra handles the quote and execution flow end to end.
+  - Metis gives more transaction control but also pushes more assembly responsibility onto the integrator.
+- Treat Jupiter token and price data as curated but evolving.
+  - Tokens V2 responses can change as Jupiter improves the schema.
+  - Price V3 intentionally withholds unreliable prices.
+- For Jupiter Lend advanced recipes, expect versioned transactions, address lookup tables, and sometimes extra compute budget.
+- Never commit private keys. Use environment variables, wallet adapters, secure signers, or managed key systems.
+
+### 4) Verify the integration path end to end
+
+- Confirm the base URL, auth header, and required parameters match the official docs you used.
+- Verify that any routing, payer, referral, or fee assumptions still hold after optional parameters are added.
+- When building transactions manually, verify quote endpoint compatibility, instruction order, compute budget, address lookup tables, and signing flow.
+- When the task involves on-chain actions, report any remaining environment needs clearly, such as API keys, RPC endpoints, or wallet secrets that were intentionally not embedded.
+
+## Reference Files
+
+- Read `references/official-docs.md` for the condensed official guidance and page map before diving into deeper Jupiter pages.
+
+## Output Expectations
+
+When finishing a Jupiter task:
+
+- state which Jupiter product surface was used
+- mention the main official pages consulted
+- call out any known tradeoffs such as rate limits, routing restrictions, null prices, or SDK versus REST constraints

package/jupiter-development/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Jupiter Development"
+  short_description: "Build against Jupiter's official Solana APIs and SDKs."
+  default_prompt: "Use $jupiter-development to build or update this Jupiter integration by confirming the current official docs first, choosing the correct Jupiter API or SDK surface, and implementing with the right routing, auth, rate-limit, and transaction-construction guardrails."

package/jupiter-development/references/official-docs.md

@@ -0,0 +1,157 @@
+# Jupiter Official Docs Reference
+
+Snapshot source: official Jupiter developer docs reviewed on 2026-03-20 from `https://dev.jup.ag/llms.txt` and linked first-party pages.
+
+## 1. Always refresh from these official entry points
+
+- Docs index: `https://dev.jup.ag/llms.txt`
+- Get started: `https://dev.jup.ag/get-started`
+- Developer portal and API keys: `https://dev.jup.ag/portal/setup.md`
+- Rate limits: `https://dev.jup.ag/portal/rate-limit.md`
+- Ultra docs root: `https://dev.jup.ag/docs/ultra-api`
+- Swap docs root: `https://dev.jup.ag/docs/swap/index.md`
+- Tokens docs root: `https://dev.jup.ag/docs/tokens/v2/token-information.md`
+- Price docs root: `https://dev.jup.ag/docs/price/index.md`
+- Lend docs root: `https://dev.jup.ag/docs/lend/index.md`
+
+If a task depends on exact schemas, jump from those pages into the matching OpenAPI reference before coding.
+
+## 2. Product selection cheatsheet
+
+| Need | Official Jupiter surface | Notes |
+| --- | --- | --- |
+| Best default swap flow | Ultra API `/ultra/v1/order` + `/ultra/v1/execute` | Current get-started docs point new integrators here first. |
+| Custom swap transaction or CPI composition | Metis Swap API | Use the lower-level swap docs only when the app must own quote/build behavior or compose instructions manually. |
+| Token search, metadata, verification, discovery | Tokens API V2 | Search by symbol, name, mint, tag, category, or recency. |
+| USD token prices | Price API V3 | Heuristic price engine; unreliable tokens may return `null`. |
+| Deposit-and-earn yield | Jupiter Lend Earn API or SDK | REST is enough for simple Earn flows; SDK gives instruction-level control. |
+| Borrow, repay, flashloan, or CPI lending | `@jup-ag/lend` plus `@jup-ag/lend-read` | Use SDK and product docs for instruction building and analytics. |
+| Limit orders / TP-SL style automation | Trigger API | Trigger V2 uses JWT auth; Trigger V1 remains documented for legacy flows. |
+| DCA | Recurring API | Time-based recurring orders. |
+| Wallet position aggregation | Portfolio API | Beta status. |
+
+## 3. Auth and operational rules
+
+- Current official docs say `api.jup.ag` requires `x-api-key`.
+- Current get-started examples still show public `lite-api.jup.ag` usage for some flows, while Jupiter's update/migration docs say deprecation was postponed and migration toward `api.jup.ag` is in progress.
+- Treat hostname choice as a time-sensitive implementation detail and refresh the exact product page before coding.
+- Generate keys at `https://portal.jup.ag`.
+- Rate limits are per account, not per key.
+- Free tier: 60 requests per 60 seconds.
+- Pro tiers: 10-second sliding windows; the Price API gets its own bucket on Pro.
+- Do not assume that creating more API keys increases throughput.
+
+## 4. Ultra and Metis swap essentials
+
+Primary docs:
+
+- `https://dev.jup.ag/get-started`
+- `https://dev.jup.ag/docs/ultra-api`
+- `https://dev.jup.ag/docs/swap/index.md`
+- `https://dev.jup.ag/docs/swap/get-quote`
+- `https://dev.jup.ag/docs/swap/build-swap-transaction`
+- `https://dev.jup.ag/docs/swap/build-swap-transaction#build-your-own-transaction-with-flash-fill-or-cpi`
+
+### Default path: Ultra API
+
+- Current get-started guidance points integrators to `GET /ultra/v1/order` and `POST /ultra/v1/execute`.
+- Use this path for the least integration work and the official default trade flow.
+
+### Advanced path: Metis Swap API
+
+- Use the lower-level swap docs when the integrator must own quote handling, transaction assembly, CPI composition, or Flash Fill style flows.
+- Reconfirm the current endpoint family on the exact swap page you use because Jupiter has been migrating between public and Portal-backed hosts.
+
+### Routing and option guardrails
+
+- Optional payer, referral, fee, or router-selection parameters are not neutral.
+- Re-read the exact product page before enabling them because they can affect routing, fees, or gasless support.
+- Do not assume all examples on older swap pages still describe the default production path.
+
+## 5. Tokens API V2 essentials
+
+Base URL: `https://api.jup.ag/tokens/v2`
+
+Primary docs:
+
+- `https://dev.jup.ag/docs/tokens/v2/token-information.md`
+- `https://dev.jup.ag/docs/tokens/organic-score.md`
+
+Important behaviors:
+
+- Search supports symbol, name, and mint-address lookup.
+- Tag queries support curated groups such as `verified` and `lst`.
+- Category queries support discovery sets such as `toporganicscore`, `toptraded`, and `toptrending`.
+- Recent tokens are keyed off first pool creation time, not token mint time.
+- Responses include metadata and market-quality signals such as organic score, holder count, market cap, liquidity, and trading stats.
+- The docs explicitly warn that the response schema may change as the API evolves.
+
+Organic score is meant to represent genuine token activity and health using wallet, liquidity, and trading signals while filtering out bot-like or wash-trade patterns.
+
+## 6. Price API V3 essentials
+
+Base URL: `https://api.jup.ag/price/v3`
+
+Primary docs:
+
+- `https://dev.jup.ag/docs/price/index.md`
+- `https://dev.jup.ag/docs/price/v3.md`
+- `https://dev.jup.ag/guides/how-to-get-token-price.md`
+
+Important behaviors:
+
+- Price V3 derives prices from the last swapped price and validates them with liquidity and market-health heuristics.
+- Up to 50 mint addresses can be queried per request according to the official guide.
+- Missing or `null` prices are expected for tokens that fail Jupiter's reliability checks.
+- Do not treat missing prices as transient transport errors by default.
+
+## 7. Jupiter Lend essentials
+
+Primary docs:
+
+- `https://dev.jup.ag/docs/lend/index.md`
+- `https://dev.jup.ag/docs/lend/api-vs-sdk.md`
+- `https://dev.jup.ag/docs/lend/program-addresses.md`
+- `https://dev.jup.ag/docs/lend/advanced/index.md`
+
+Packages mentioned by the official docs:
+
+- `@jup-ag/lend`
+- `@jup-ag/lend-read`
+- `@solana/web3.js`
+
+Practical split:
+
+- Use the REST API for straightforward Earn deposit and withdrawal flows.
+- Use the SDK when you need Borrow flows, CPI, flashloans, batched operations, address lookup tables, or read-side analytics.
+- For advanced recipes such as multiply, unwind, vault swap, and flashloans, expect large multi-instruction transactions and add compute budget when needed.
+- Public RPC endpoints are not recommended for production; the docs suggest dedicated providers.
+
+## 8. Other important Jupiter APIs
+
+### Trigger
+
+- Docs root: `https://dev.jup.ag/docs/trigger/index.md`
+- Trigger V2 uses a challenge-response auth flow and returns a JWT for subsequent requests.
+- Use it for single price orders, OCO, and OTOCO flows.
+
+### Recurring
+
+- Docs root: `https://dev.jup.ag/docs/recurring/index.md`
+- Use it for time-based DCA orders.
+- Jupiter keeper bots handle recurring execution after setup.
+
+### Portfolio
+
+- Docs root: `https://dev.jup.ag/docs/portfolio/index.md`
+- Beta API for wallet positions across Solana protocols, including Jupiter-specific positions.
+
+## 9. Implementation checklist
+
+- Confirm the exact Jupiter product surface first.
+- Confirm the latest official page and API version before editing code.
+- Confirm whether the chosen host requires `x-api-key`, and keep any key out of source control.
+- Preserve the default routing path unless the product requirement truly needs advanced payer, fee, or router controls.
+- Treat `null` token prices as a valid product outcome.
+- Use SDK flows for Jupiter Lend borrow, CPI, flashloan, and analytics work.
+- Report any remaining API-key, RPC, or wallet requirements explicitly.

package/learn-skill-from-conversations/SKILL.md

@@ -15,7 +15,7 @@ description: Learn and evolve the local skill library from recent Codex conversa
 ## Standards
 
 - Evidence: Extract recent Codex session history first and derive reusable lessons only from actual conversation patterns.
-- Execution: Prefer creating a new skill unless the overlap with an existing skill is clearly strong, then apply the change through `skill-creator`.
+- Execution: Inventory the current skill catalog before editing, prioritize repeated requests, user corrections, and reported errors, then prefer a focused update to the strongest related skill or create a new skill only when the overlap is weak.
 - Quality: Take no action when there are no recent sessions, avoid unrelated broad refactors, and validate every changed skill.
 - Output: Report the analyzed sessions, extracted lessons, created or updated skills, and the reasoning behind each decision.
 
@@ -46,16 +46,25 @@ python3 ~/.codex/skills/learn-skill-from-conversations/scripts/extract_recent_co
 ### 2) Derive reusable lessons
 
 - Identify repeated user needs, recurring friction, and repeated manual workflows.
+- Give extra weight to moments where the user corrected the agent, rejected an earlier interpretation, or pointed out a missing preference or requirement.
+- Give extra weight to user-reported errors, regressions, or avoidable mistakes, then ask how a skill can prevent repeating that failure mode.
 - Ignore one-off issues that do not provide reusable value.
+- Distinguish between:
+  - repeated trigger intent that deserves a new skill
+  - repeated workflow fragments across multiple skills that should be extracted into a shared skill
+  - skill gaps that are better handled by tightening an existing skill's guardrails
 
 ### 3) Decide new skill vs existing skill (default: new skill)
 
+- First read the relevant skills already present in the working repository so you do not create a duplicate under a different name.
 - Prefer creating a new skill.
 - Edit an existing skill only when the lesson is strongly related.
 - Treat relation as strong only when all three conditions hold:
   - Same primary trigger intent.
   - At least 70% workflow overlap.
   - The update does not dilute the existing skill's scope.
+- When the recurring lesson is mainly about preventing a known mistake, prefer updating the existing skill that should have prevented it instead of creating a parallel skill.
+- When several skills repeat the same narrow workflow fragment, prefer extracting that fragment into a dedicated shared skill instead of copying the same guidance again.
 - If uncertain, create a new skill instead of expanding an old one.
 
 ### 4) Apply changes through skill-creator
@@ -76,7 +85,7 @@ python3 ~/.codex/skills/.system/skill-creator/scripts/quick_validate.py <skill-p
 
 ### 6) Report result
 
-- Summarize analyzed sessions, extracted lessons, created/updated skills, and why each decision was made.
+- Summarize analyzed sessions, repeated needs, user corrections, error-driven lessons, created/updated skills, and why each decision was made.
 
 ## Guardrails
 

package/marginfi-development/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 LaiTszKin
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/marginfi-development/README.md

@@ -0,0 +1,31 @@
+# Marginfi Development
+
+`marginfi-development` is a reusable skill for building or reviewing integrations on the marginfi protocol with official documentation as the source of truth.
+
+It helps an agent:
+
+1. Choose the correct marginfi development surface.
+2. Reconfirm official addresses, groups, and environment details.
+3. Implement or explain deposits, borrows, repayments, withdrawals, flash loans, liquidations, or permissionless banks.
+4. Map raw `mfi-v2` instructions and errors when SDK helpers are not enough.
+
+## Repository layout
+
+- `SKILL.md`: trigger rules, workflow, and guardrails
+- `agents/openai.yaml`: agent-facing metadata
+- `references/official-development-notes.md`: condensed official development guidance
+- `references/source-index.md`: quick source routing for official docs
+
+## Main use cases
+
+Use this skill for:
+
+- marginfi SDK integration work
+- Solana bots or backends that interact with marginfi
+- bank configuration and The Arena permissionless-bank flows
+- flash-loan or liquidation implementation reviews
+- raw instruction or error mapping against `mfi-v2`
+
+## License
+
+MIT. See `LICENSE`.

package/marginfi-development/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: marginfi-development
+description: Build or analyze integrations on the Solana-based marginfi protocol using the official TypeScript SDK, Rust CLI, and protocol docs. Use when implementing or reviewing marginfi deposits, withdrawals, borrows, repayments, flash loans, liquidations, permissionless banks, bank configuration, account-health logic, or raw instruction mapping, and ground the work in official marginfi documentation before coding.
+---
+
+# Marginfi Development
+
+## Dependencies
+
+- Required: none.
+- Conditional: `answering-questions-with-research` when the user needs marginfi guidance combined with fresh external verification or local repository discovery.
+- Optional: none.
+- Fallback: If official docs do not confirm a requested parameter, address, or workflow, say so explicitly instead of guessing.
+
+## Standards
+
+- Evidence: Start from official marginfi docs and official source links, and re-check time-sensitive values before hardcoding them.
+- Execution: Pick the correct integration surface first (TypeScript SDK, Rust CLI, or raw program instructions), then scope the exact bank, group, account, and environment involved.
+- Quality: Preserve Solana and Anchor conventions, validate margin account health assumptions, and never invent bank config or oracle defaults.
+- Output: Provide copy-pastable implementation steps, the exact official source pages consulted, and concrete caveats for unresolved risks.
+
+## Goal
+
+Build or review marginfi integrations with the smallest correct implementation that still respects the protocol's account model, bank risk parameters, oracle rules, and operational constraints.
+
+## Workflow
+
+### 1) Classify the task before coding
+
+Map the request to one of these paths:
+
+- application integration with the TypeScript SDK
+- operational/admin work with the Rust CLI
+- raw on-chain instruction work against `mfi-v2`
+- permissionless bank creation in The Arena
+- liquidations, health, or risk-model analysis
+- flash loan composition
+
+Then load only the matching reference sections from `references/official-development-notes.md`.
+
+### 2) Reconfirm official docs when values can drift
+
+Re-check live official docs when the task depends on:
+
+- current program or group addresses
+- package names or environment configs
+- current bank parameters or listing rules
+- The Arena flows or permissionless-bank requirements
+
+Use `references/source-index.md` to jump to the right official page quickly.
+
+### 3) Choose the correct development surface
+
+#### TypeScript SDK
+
+Use for frontends, bots, services, scripts, or integration tests.
+
+- Start with `MarginfiClient.fetch(getConfig(...), wallet, connection)`.
+- Fetch or create the authority's marginfi account before user actions.
+- Resolve banks by token symbol, mint, or public key before depositing, borrowing, repaying, or withdrawing.
+- Prefer SDK helpers for instruction construction, transaction processing, flash loans, and account reloads.
+
+#### Rust CLI
+
+Use for operator workflows, group or bank administration, and quick protocol interaction from the terminal.
+
+- Configure the correct profile and environment first.
+- Use the CLI for account creation, deposits, borrows, repayments, withdrawals, transfers, emissions setup, and bank-management flows.
+- When creating or updating banks, provide explicit config values; do not infer hidden defaults.
+
+#### Raw program work
+
+Use when you need exact instruction names, account constraints, or error mapping.
+
+- Read the `mfi-v2` instruction and error sections first.
+- Keep flash-loan state transitions and end-instruction indexing exact.
+- Map protocol errors back to the user-visible cause instead of returning opaque Solana failures.
+
+### 4) Apply the task-specific playbook
+
+#### Deposits / borrows / withdrawals / repayments
+
+- Confirm the target group and bank.
+- Load or create the user's marginfi account.
+- Fetch fresh bank data and oracle-backed pricing before reasoning about health.
+- Use SDK or CLI helpers instead of hand-writing instructions unless the task explicitly needs raw instruction control.
+
+#### Flash loans
+
+- Treat flash loans as a begin/end instruction pair or use the SDK helper that builds the full transaction.
+- Ensure the end instruction index is correct and that every temporary borrow is repaid within the same transaction.
+- Watch for flash-loan-specific errors such as illegal nesting or missing end instructions.
+
+#### Permissionless banks / The Arena
+
+- Collect the mint, oracle setup, risk tier, asset/liability weights, deposit and borrow limits, operational state, and rate configuration before coding.
+- Use the official The Arena guidance and listing criteria as the source of truth.
+- Surface any missing config explicitly; never invent safe-looking defaults.
+
+#### Liquidations and health analysis
+
+- Distinguish collateral, borrow-only, and isolated assets.
+- Explain how asset weights, liability weights, utilization-based rates, and oracle staleness checks affect account health.
+- Use official terminology when describing liquidatable states and liquidation flows.
+
+### 5) Respect protocol guardrails
+
+- marginfi relies on Pyth and Switchboard oracle feeds with confidence and staleness checks; do not assume any quoted price is always usable.
+- Interest rates are utilization-based and piecewise; account economics depend on bank config, not just spot balances.
+- Current docs describe verified builds, audits, fuzz testing, and bug-bounty coverage; do not bypass those assumptions when proposing deployment or upgrade steps.
+
+### 6) Output expectations
+
+When finishing marginfi work:
+
+- name the exact official pages consulted
+- state the chosen integration surface
+- list the concrete accounts, banks, and env values the implementation needs
+- call out any unverified addresses, parameters, or bank settings
+- keep examples minimal and directly runnable when possible
+
+## References
+
+- `references/official-development-notes.md`: condensed marginfi development guidance from official docs.
+- `references/source-index.md`: official page index and when to consult each source.

package/marginfi-development/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Marginfi Development"
+  short_description: "Build or review integrations on the marginfi protocol"
+  default_prompt: "Use $marginfi-development to ground the task in official marginfi docs, choose the correct development surface (TypeScript SDK, Rust CLI, or raw program instructions), load the relevant reference sections, and then implement or explain the smallest correct marginfi integration without guessing bank config, oracle setup, or protocol addresses."

package/marginfi-development/references/official-development-notes.md

@@ -0,0 +1,191 @@
+# Official Marginfi Development Notes
+
+Checked against official marginfi docs on 2026-03-20.
+
+## Canonical official sources
+
+- Docs home: `https://docs.marginfi.com/`
+- TypeScript SDK docs: `https://docs.marginfi.com/ts-sdk`
+- Rust CLI docs: `https://docs.marginfi.com/rust-sdk`
+- Protocol design: `https://docs.marginfi.com/protocol-design`
+- Program docs (`mfi-v2`): `https://docs.marginfi.com/mfi-v2`
+- The Arena docs: `https://docs.marginfi.com/the-arena`
+
+## 1. Protocol model to keep in mind
+
+marginfi is a pooled-balance lending protocol on Solana. The main developer objects are:
+
+- `MarginfiGroup`: protocol-wide configuration and shared state for a deployment.
+- `Bank`: the per-asset pool with oracle config, risk weights, limits, and utilization-driven rates.
+- `MarginfiAccount`: the user's margin account that holds deposits and liabilities across banks.
+
+Important protocol-design facts from the official docs:
+
+- Risk is controlled by asset weights, liability weights, and loan-to-value style constraints.
+- Oracles come from Pyth and Switchboard, with confidence and staleness checks before prices are accepted.
+- Docs mention a maximum oracle staleness of 60 seconds and a 95% confidence interval requirement.
+- Pyth EMA pricing is described as roughly 5,921 slots (about 1 hour) for smoothing.
+- Interest rates use a two-segment utilization curve: rates rise with utilization, then increase more aggressively after the optimal-utilization threshold.
+- Asset risk tiers include collateral-style assets, borrow-only assets, and isolated assets.
+
+Use these facts when reasoning about account health, liquidations, and bank config; do not reduce health checks to simple spot-price math.
+
+## 2. Official addresses and environments
+
+The official docs currently expose these environment values across the docs home and protocol-design pages:
+
+- Mainnet program: `MFv2hWf31Z9kbCa1snEPYctwafyhdvnV7FZnsebVacA`
+- Mainnet group: `FCPfpHAjHn9R6vWQbtyzcN8PjjobJABQj9rChmC6Cv5j`
+- Staging program: `stag8sTKDs4Df2RehcgddBVAtDx6gbDp7YkA94R6HvK`
+- Staging group: `2rpQwP4ofD6P2AojSeyjc9kUCzjscX4oMtd2N4eySe7W`
+
+Treat these as time-sensitive. Re-check the docs page before hardcoding them in new work.
+
+## 3. TypeScript SDK essentials
+
+Official docs point to the npm package `@mrgnlabs/marginfi-client-v2` plus `@mrgnlabs/mrgn-common` helpers.
+
+Core setup flow from the docs:
+
+1. Create a Solana `Connection`.
+2. Build a wallet adapter or `NodeWallet`.
+3. Load `getConfig("production")` or another environment config.
+4. Call `MarginfiClient.fetch(config, wallet, connection)`.
+5. Fetch existing marginfi accounts for the authority, or create one.
+6. Resolve the target bank, then perform actions.
+
+Minimal example pattern:
+
+```ts
+import { Connection } from "@solana/web3.js";
+import { MarginfiClient, getConfig } from "@mrgnlabs/marginfi-client-v2";
+import { NodeWallet } from "@mrgnlabs/mrgn-common";
+
+const connection = new Connection(process.env.RPC_URL!, "confirmed");
+const wallet = NodeWallet.local();
+const config = getConfig("production");
+const client = await MarginfiClient.fetch(config, wallet, connection);
+
+const accounts = await client.getMarginfiAccountsForAuthority();
+const account = accounts[0] ?? (await client.createMarginfiAccount());
+const bank = client.getBankByTokenSymbol("SOL");
+if (!bank) throw new Error("SOL bank not found");
+
+await account.deposit(1, bank.address);
+```
+
+Useful SDK objects and methods called out in the docs:
+
+- Client bootstrap: `MarginfiClient.fetch`, `getConfig`
+- Bank lookup: `getBankByTokenSymbol`, `getBankByMint`, `getBankByPk`
+- Oracle helpers: `getOraclePriceByBank`
+- Account discovery: `getMarginfiAccountsForAuthority`
+- Account creation: `createMarginfiAccount`
+- Permissionless-bank support: `createLendingPool`
+- Transaction helper: `processTransaction`
+- Margin-account actions on `MarginfiAccountWrapper`: `deposit`, `withdraw`, `borrow`, `repay`, `reload`
+
+Prefer these helpers before assembling raw instructions manually.
+
+## 4. Flash-loan development notes
+
+Official TS SDK docs describe `buildFlashLoanTx` as the preferred helper for building full flash-loan transactions.
+
+The program docs describe flash loans as:
+
+- `lending_account_start_flashloan`
+- user instructions that consume the temporary liquidity
+- `lending_account_end_flashloan`
+
+Important implementation rules:
+
+- Flash loans must begin and end in the same transaction.
+- The end instruction must reference the correct end index.
+- Nested or malformed flash-loan flows are rejected.
+- Relevant program errors include `AccountInFlashloan`, `IllegalFlashloan`, `IllegalFlag`, and `NoFlashloanInProgress`.
+
+If you need raw control, mirror the exact begin/end instruction ordering from the official docs.
+
+## 5. Rust CLI essentials
+
+The Rust CLI docs describe profile-based configuration through `marginfi profile` and account or bank operations through `marginfi group` and `marginfi account` subcommands.
+
+Representative CLI flows from the docs:
+
+- profile and authority setup: `marginfi profile create`, `marginfi profile set`
+- account flows: `marginfi account create`, `deposit`, `borrow`, `withdraw`, `repay`
+- bank and admin flows: `marginfi group add-bank`, `configure-bank`, `collect-fees`, `setup-emissions`, `update-emissions`
+- permissionless-bank creation: `marginfi group add-bank-permissionless`
+
+Use the CLI when the job is operational, administrative, or quick to script from the terminal. Use the TS SDK when embedding marginfi into apps or bots.
+
+## 6. Permissionless banks and The Arena
+
+The Arena docs describe a permissionless flow where developers can create marginfi banks from listed tokens.
+
+Important configuration areas surfaced in the official docs:
+
+- `asset_weight_init` / `asset_weight_maint`
+- `liability_weight_init` / `liability_weight_maint`
+- deposit and borrow limits
+- interest-rate curve parameters such as optimal utilization, plateau rate, max rate, and fees
+- `risk_tier`
+- `operational_state`
+- `oracle_setup`
+
+The official TS docs also show `BankConfigOpt`, `InterestRateConfigOpt`, `OracleSetup`, `RiskTier`, and `OperationalState` in the permissionless-bank example.
+
+When implementing bank creation:
+
+- treat every config field as an explicit input
+- validate the oracle source and required feed accounts
+- keep listing-criteria and The Arena docs open while coding
+- do not fabricate safe defaults for weights or limits
+
+## 7. Program instruction map
+
+The `mfi-v2` docs expose the on-chain instruction set and typed errors.
+
+Key instruction families to consult before raw program work:
+
+- marginfi-group initialization and configuration
+- bank creation and configuration
+- margin-account creation
+- deposit / withdraw
+- borrow / repay
+- emissions setup and update
+- liquidate
+- flash-loan begin / end
+- account transfer flows
+
+Useful error names exposed in the docs include:
+
+- `Unauthorized`
+- `BankNotFound`
+- `MarginfiAccountNotFound`
+- `OperationWithdrawOnly`
+- `IllegalLiquidation`
+- `IllegalFlashloan`
+- `AccountInFlashloan`
+- `NoFlashloanInProgress`
+- `SwitchboardStalePrice`
+- `CannotCloseOutstandingEmissions`
+
+When surfacing failures to users, translate these into the failed business condition instead of echoing raw Solana logs only.
+
+## 8. Security and operational notes
+
+The docs highlight:
+
+- Halborn and Sec3 audits
+- fuzz testing
+- a bug-bounty program
+- verifiable-build support via `solana-verify`
+
+The official verification example is:
+
+```bash
+solana-verify verify-from-repo -um --program-id MFv2hWf31Z9kbCa1snEPYctwafyhdvnV7FZnsebVacA https://github.com/mrgnlabs/marginfi-v2
+```
+
+Use these references when the task touches deployment verification, trust assumptions, or upgrade review.

package/marginfi-development/references/source-index.md

@@ -0,0 +1,31 @@
+# Marginfi Official Source Index
+
+Use this file to jump to the official page that matches the task.
+
+## Primary docs
+
+- `https://docs.marginfi.com/`
+  - Read for current program IDs, group IDs, lookup-table references, and top-level navigation.
+- `https://docs.marginfi.com/ts-sdk`
+  - Read for TypeScript integration, SDK classes, helper methods, and flash-loan or permissionless-bank examples.
+- `https://docs.marginfi.com/rust-sdk`
+  - Read for CLI workflows, operator tasks, profiles, group commands, and bank administration.
+- `https://docs.marginfi.com/protocol-design`
+  - Read for risk model, oracle rules, utilization-based interest design, and liquidation reasoning.
+- `https://docs.marginfi.com/mfi-v2`
+  - Read for raw instruction names, account schemas, and error definitions.
+- `https://docs.marginfi.com/the-arena`
+  - Read for permissionless-bank flows and links to listing criteria.
+
+## When to open which source
+
+- App, bot, backend, or frontend integration: start with `ts-sdk`, then `protocol-design`.
+- CLI or ops automation: start with `rust-sdk`.
+- Custom Anchor or raw Solana instruction work: start with `mfi-v2`.
+- Health checks, liquidation analysis, or risk explanations: start with `protocol-design`, then confirm relevant instruction behavior in `mfi-v2`.
+- Permissionless bank creation: start with `the-arena`, then open `ts-sdk` or `rust-sdk` depending on the chosen toolchain.
+- Address or deployment verification: start with the docs home page, then follow its linked source or verification references.
+
+## Working rule
+
+If the request depends on a value that can change over time, reopen the live official page even if this skill already contains a summary.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@laitszkin/apollo-toolkit",
-  "version": "2.5.0",
+  "version": "2.6.0",
   "description": "Apollo Toolkit npm installer for managed skill linking across Codex, OpenClaw, and Trae.",
   "license": "MIT",
   "author": "LaiTszKin",

package/solana-development/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: solana-development
+description: Build or maintain Solana applications in Rust using official Solana development docs. Use when users ask for native Solana programs, Rust SDK clients, account modeling, instruction design, PDAs, CPIs, local testing, deployment, upgrades, or Solana-specific debugging in Rust codebases.
+---
+
+# Solana Development
+
+## Dependencies
+
+- Required: none.
+- Conditional: `systematic-debug` when the task is about failing Solana tests, runtime errors, or observed-vs-expected on-chain behavior.
+- Optional: none.
+- Fallback: If the repository pins Solana crates or CLI behavior that differs from the latest official docs, follow the repository's pinned versions and document the mismatch explicitly.
+
+## Standards
+
+- Evidence: Ground commands, crate choices, and account-model decisions in the current repository plus official Solana docs under `solana.com/docs`.
+- Execution: Classify the task as on-chain Rust, off-chain Rust client work, or both before changing code.
+- Quality: Prefer minimal account surfaces, explicit instruction schemas, deterministic PDA seeds, and tests for every state transition or authority check.
+- Output: Deliver Rust-focused changes with touched accounts, instructions, test commands, deployment notes, and any cluster or authority assumptions.
+
+## Goal
+
+Implement Solana Rust work in a way that matches the official execution model: accounts and instructions first, then PDAs/CPIs, then testing and deployment safety.
+
+## Required Reference
+
+- Read `references/official-solana-rust.md` before making non-trivial Solana changes.
+- Refresh the linked official pages when crate versions, CLI commands, or deployment behavior appear different from the reference snapshot.
+
+## Use This Skill For
+
+- Native Solana programs written directly in Rust
+- Rust clients, indexers, or operational tools built with the Solana Rust SDK
+- Account modeling, authority rules, PDA design, and CPI orchestration
+- Local validator workflows, Rust-native tests, build/deploy/upgrade flows
+- Solana-specific debugging such as signer, owner, writable, rent, compute, and instruction-data issues
+
+## Workflow
+
+### 1) Classify the repository shape first
+
+- Identify whether the codebase contains on-chain programs, Rust clients, or both.
+- Detect whether the repository uses native Solana Rust or a higher-level framework already. Do not rewrite framework conventions unless the user asks.
+- Locate program IDs, deploy scripts, test harnesses, keypair handling, and cluster configuration before editing.
+
+### 2) Design the instruction and account contract up front
+
+- List each instruction, the accounts it needs, which accounts must be signer or writable, and which program owns each account.
+- Record PDA seeds, bump handling, rent expectations, realloc rules, and close authorities before implementing handlers.
+- Reject invalid ownership, signer, and writable assumptions explicitly instead of relying on downstream runtime failures.
+
+### 3) Keep native Rust program structure explicit
+
+- Follow the official native Rust flow: `entrypoint` receives the program call, instruction parsing is explicit, and processor logic is separated from account data definitions.
+- Keep serialization and versioning explicit for any state stored inside accounts.
+- Prefer custom program errors over panics so failures remain diagnosable.
+
+### 4) Use PDAs and CPIs deliberately
+
+- Use PDAs for program-controlled state or authorities that should not require a private key.
+- Use `invoke` for regular cross-program calls and `invoke_signed` only when the current program must sign as one of its PDAs.
+- Treat signer and writable privileges as inherited, not escalated; verify every CPI account list carefully.
+
+### 5) Choose the correct Rust crates for the job
+
+- For on-chain code, center the implementation around `solana-program`.
+- For off-chain Rust clients and tooling, use `solana-sdk` for transaction primitives and `solana-client` for RPC access.
+- When a project mirrors CLI behavior, inspect whether it also depends on `solana-cli-config` or `solana-clap-utils`.
+
+### 6) Validate locally before deploy
+
+- Prefer fast Rust-native tests first, then run the repository's validator or end-to-end flow if available.
+- Build with the repository's pinned toolchain when present; otherwise use the current official Solana build/deploy workflow from the reference.
+- Exercise account initialization, authority checks, PDA signing, and failure paths instead of only happy-path success.
+
+### 7) Deploy and upgrade safely
+
+- Confirm target cluster, payer, program ID, and upgrade authority before deploy.
+- Call out any action that makes a program immutable or permanently closes program state.
+- When deployment changes operational assumptions, summarize the exact commands and authority implications in the final handoff.
+
+## Final Checklist
+
+- Account ownership, signer, writable, and PDA assumptions are explicit
+- Instruction data and state serialization are version-aware where needed
+- Local tests cover success and failure paths for state transitions
+- Deployment or upgrade commands match the target cluster and authority setup
+- Any mismatch between repo-pinned Solana versions and current docs is documented

package/solana-development/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Solana Development"
+  short_description: "Build Solana Rust programs and clients from official docs"
+  default_prompt: "Use $solana-development to inspect the repository, determine whether the task is on-chain Rust, off-chain Rust client work, or both, follow the official Solana model for accounts, instructions, PDAs, CPIs, testing, and deployment, and deliver concise Rust-focused implementation notes grounded in current Solana docs."

package/solana-development/references/official-solana-rust.md

@@ -0,0 +1,199 @@
+# Official Solana Rust Development Reference
+
+Snapshot date: 2026-03-20 (Asia/Hong_Kong).
+
+Use this file when building, reviewing, or debugging Solana work in Rust. It condenses the most important development guidance from the official Solana documentation so the main skill can stay concise.
+
+## Official source map
+
+- Core accounts: `https://solana.com/docs/core/accounts`
+- Core instructions: `https://solana.com/docs/core/instructions`
+- Core transactions: `https://solana.com/docs/core/transactions`
+- Core fees: `https://solana.com/docs/core/fees`
+- Program Derived Addresses: `https://solana.com/docs/core/pda`
+- Cross Program Invocation: `https://solana.com/docs/core/cpi`
+- Native Rust programs overview: `https://solana.com/docs/programs/rust`
+- Native Rust program structure: `https://solana.com/docs/programs/rust/program-structure`
+- Program deployment and upgrades: `https://solana.com/docs/programs/deploying`
+- Official Rust SDK overview: `https://solana.com/docs/clients/official/rust`
+
+If any page changes structure, search `site:solana.com/docs <topic>` and refresh this reference before locking in version-sensitive commands.
+
+## 1. Core execution model you must preserve
+
+- Solana programs operate by receiving instruction data plus an ordered account list. Most implementation mistakes are really account-contract mistakes.
+- Accounts are the durable storage boundary. Before editing logic, identify each account's owner, mutability, signer requirement, lamports behavior, and serialized data layout.
+- Transactions package one or more instructions and execute atomically. Design instruction handlers with atomic state transitions in mind.
+- The official fees model separates:
+  - base fee, currently documented as `5000` lamports per signature
+  - prioritization fee, computed from compute-unit limit and compute-unit price
+- When performance or cost matters, review compute usage per instruction and avoid unnecessary account writes.
+
+## 2. Native Rust program structure
+
+The official native Rust docs and program-structure page emphasize a small, explicit layout:
+
+- `entrypoint.rs`: Solana entrypoint and handoff into program logic
+- `instruction.rs`: instruction enum / decoding
+- `processor.rs`: instruction handlers and business logic
+- `state.rs`: account data structs and serialization
+- `error.rs`: custom program errors
+
+Keep the logic readable and explicit:
+
+- parse instruction data up front
+- validate account shape before mutation
+- separate state serialization from business logic
+- return `ProgramError`-compatible failures instead of panicking
+
+The official Rust-program walkthrough currently documents these setup details:
+
+- create a library crate
+- add `solana-program` as the primary on-chain dependency
+- set `[lib] crate-type = ["cdylib", "lib"]`
+- build SBF output with the Solana build flow documented on the page
+
+As of the 2026-03-20 snapshot, the official examples show `solana-program@2.2.0` in native Rust setup examples. Re-check before pinning new projects because Solana crate versions move.
+
+## 3. Instruction and account design checklist
+
+Before writing handlers, lock down:
+
+- instruction enum and binary format
+- per-instruction account list order
+- which accounts are signer
+- which accounts are writable
+- which program owns each account
+- PDA seeds and bump strategy
+- account initialization, realloc, close, and rent expectations
+
+Useful rule: every handler should be reviewable from a table with columns for account, owner, signer, writable, PDA seeds, and failure conditions.
+
+## 4. Program Derived Addresses (PDAs)
+
+Official PDA guidance centers on these ideas:
+
+- A PDA is a deterministic address derived from seeds plus a program ID.
+- PDAs are intentionally off the Ed25519 curve, so they have no private key.
+- Programs use PDAs for program-controlled authorities and state accounts.
+- The same seeds plus the same program ID must derive the same PDA every time.
+- The bump seed exists to find a valid off-curve address.
+
+The official PDA page also documents practical limits to remember:
+
+- up to 16 seeds per derivation
+- each seed can be up to 32 bytes
+
+Design advice:
+
+- Use stable, domain-specific seeds such as fixed prefixes plus relevant public keys.
+- Keep seed schemes obvious and documented near the instruction that consumes them.
+- Prefer one clear PDA purpose per seed scheme instead of overloading one PDA for unrelated roles.
+
+## 5. Cross Program Invocation (CPI)
+
+Official CPI guidance highlights:
+
+- Solana programs can invoke instructions in other programs.
+- Use `invoke` when no PDA signature is required.
+- Use `invoke_signed` when the current program must sign on behalf of one of its PDAs.
+- Signer and writable privileges extend from the caller into the callee; CPI does not create new privileges.
+
+Practical implications:
+
+- Validate the entire downstream account list before the CPI.
+- Never assume a callee can write to an account unless the outer instruction passed it as writable.
+- When debugging CPI failures, inspect signer propagation, writable flags, PDA seed correctness, and program ownership first.
+
+The official page notes a practical limit of 16 PDA signers in `invoke_signed`.
+
+## 6. Fees and compute-budget awareness
+
+The official fees page is the baseline for performance-sensitive work:
+
+- base fee is charged per signature
+- prioritization fee depends on compute-unit limit and compute-unit price
+- transactions can set compute budget explicitly when needed
+
+When implementing Rust clients or relayers:
+
+- size transaction account lists carefully
+- avoid unnecessary signatures
+- consider compute budget instructions only when the workflow truly needs them
+
+When implementing programs:
+
+- keep account validation linear and obvious
+- avoid redundant serialization passes
+- separate expensive CPIs from cheap pure-validation paths when possible
+
+## 7. Local testing workflow
+
+Official Solana docs currently show a Rust-native local test flow for native programs.
+
+From the current documentation snapshot:
+
+- official examples show `litesvm@0.6.1` and `solana-sdk@2.2.0` as dev dependencies in the Rust testing walkthrough
+- the docs position LiteSVM as a fast local execution harness for native Rust programs
+
+Recommended execution order:
+
+1. unit-test pure helpers and serialization logic
+2. run Rust-native program tests for instruction/state behavior
+3. run validator-backed integration flow only when the repository or task needs cluster realism
+
+Test the following explicitly:
+
+- initialization and duplicate-initialization rejection
+- authority checks
+- signer and writable enforcement
+- PDA derivation and PDA signing flows
+- state transitions, close flows, and realloc paths
+- failure paths for malformed instruction data or wrong account order
+
+## 8. Deployment, upgrades, and irreversible operations
+
+The official deployment docs cover the core operational loop:
+
+- local development often starts with `solana-test-validator`
+- deploy with `solana program deploy ...`
+- visibility can lag by roughly one slot after deployment
+- a program becomes immutable when its upgrade authority is removed
+- `solana program close` permanently closes the program and the same program ID cannot be reused for redeployment
+
+Before any deploy or upgrade:
+
+- confirm cluster URL
+- confirm payer keypair
+- confirm intended program ID
+- confirm upgrade authority ownership
+- confirm whether the deploy changes any downstream configuration or address registry
+
+For production-facing tasks, always surface immutable or close operations as explicit risk points in the handoff.
+
+## 9. Official Rust SDK crate roles
+
+The official Rust SDK overview maps the common crates this way:
+
+- `solana-program`: on-chain program primitives
+- `solana-sdk`: transactions, instructions, keypairs, signatures, and shared primitives for Rust clients
+- `solana-client`: RPC access for off-chain Rust applications
+- `solana-cli-config`: reuse CLI config from Rust tools
+- `solana-clap-utils`: CLI-oriented helper utilities
+
+Default crate choice:
+
+- on-chain program logic: `solana-program`
+- Rust service/tool that talks to RPC: `solana-sdk` + `solana-client`
+- Rust CLI that should mirror Solana CLI config behavior: add `solana-cli-config`
+
+## 10. When to refresh the official docs before coding
+
+Refresh the linked pages instead of relying on this snapshot when:
+
+- the repository pins newer or older Solana crate versions
+- CLI subcommands or flags differ from this reference
+- the task depends on recently changed runtime features
+- the repository uses Anchor or another framework that wraps native Solana APIs
+
+When docs and code disagree, preserve the repository's actual pinned behavior and note the divergence.