Skip to main content
Contributions should improve one concrete reusable behavior and its evidence while preserving the full design target. Passing a small component suite does not redefine a larger requirement as complete.

​
Source changes

Read repository AGENTS.md and the owning crate/SDK contract. Preserve unrelated work. Keep integration selection with agents and concrete validation in code. Prefer existing Meerkat/Meta owners over parallel runtime, policy or persistence authorities. The root Rust workspace contains the standalone package and store crates. Use ./scripts/repo-cargo test --workspace --all-features --locked to include the artifact and recipe functionality. python3 scripts/verify-local records formatting, tests and Clippy against that workspace’s actual source and graph. The three native integration crates remain required work in the explicit native-candidate workspace. Use python3 scripts/verify-local --manifest-path native-candidate/Cargo.toml with the exact reviewed prerequisite checkouts and lockfile. That graph retains local development paths and can fail before compilation. A root workspace pass does not certify native integration, and an older passing snapshot does not establish current compatibility.

​
Evidence levels

Retain failures and corrections alongside final receipts. State the exact backend and environment tested. An in-memory substitute cannot establish a claimed durable backend, and a simulated physical device cannot establish actual actuation.

​
Connector and frontend acceptance

Service checks cover account isolation, schemas/results, pagination, limits, rate errors, redirects, cancellation/cleanup, explicit policy and uncertain writes. Frontend checks additionally cover forged inputs, two users/conversations, replay, audience change, permitted output, queued delivery, pause/removal and uncertain multipart outcomes. Use actual runtime dispatch and observations for claims about native tools, including restoration and every supported spawn path. Keep proposed startup protocol tests separate from released SDK behavior. The complete design also needs cross-host activation, injected-store recovery, custom device/live cases and generic-host retirement evidence.

​
Documentation-only validation

From the repository root:
This standard-library checker validates site navigation, frontmatter, local links/anchors, assets and ASCII hyphens. It does not compile SDK examples or establish runtime behavior. Use Node 22 or 24 for the pinned Mintlify CLI. Node 24.19.0 is the locally validated preview choice. From docs/site/:
Mintlify validation parses the actual MDX/configuration. Inspect representative pages in the preview for navigation, tables, callouts, code, tabs and Mermaid rendering. A successful parser check alone is not visual verification.

​
Update claims with changes

When changing an operation, update the corresponding SDK reference and examples. When changing a recipe, update its version and evidence, compiled registration if intended, and catalog inventory. When changing readiness or native composition, recheck availability, readiness and the affected host guides. Keep public pages concise and audience-focused. Detailed private reviews, validation captures, source snapshots and requirement ledgers remain outside docs/site/. The repository’s docs/DOCUMENTATION.md contains the maintainer source map and site workflow.