Minco 1.7.0

Stable release manual

Latest stable release. These pages target Minco 1.7.0 and Rust 1.97.1.View all versions

This manual describes the published 1.7.0 source. It develops the same contract-to-cloud model as the frozen 1.6.0 manual, while keeping later unreleased behavior visibly separate in Next.

The 1.7 release makes Apple Container the fresh local-service default on qualified Apple silicon hosts while retaining lifecycle receipts, exact owned-resource recovery, explicit runtime selection and Docker fallback.

Start with the outcome

The documentation is organized progressively. Begin with one working application, then move to a focused guide, a real scenario, the component catalog, or exact reference when the next decision requires it.

Build an applicationUnderstand the contract-to-cloud path, project layers, and development loop.Use resource APIsImplement create, list, read, update, and delete with one client-facing convention.Serve browser and native clientsUse one API with explicit PKCE, CORS, retry, compatibility, and device-trust boundaries.Author a pluginPackage a statically linked plugin and exercise the public conformance boundary.Develop with coding agentsInstall version-matched Codex and Claude skills and inspect bounded project context.Operate on AWSReview Plan IR, residual cost, exact artifacts, guarded mutation, and recovery evidence.Browse all featuresSee the framework surface by contract, data, runtime, deployment, and evidence plane.Choose built-in pluginsCompare all 19 plugins, adapters, and runtimes by purpose, stability, and cost behavior.Follow practical recipesCombine the pieces for CRUD, background work, feedback, files, and safe AWS delivery.Follow a production blueprintDesign a burst-ready Orders system from traffic pattern through cost, failure, and evidence.

See the whole system

Minco keeps five concerns distinct but traceable. That separation lets a person or coding agent answer “what changes if this operation changes?” without relying on a runtime service locator or an undocumented control plane.

01 · ContractWhat clients may do

OpenAPI operations, schemas, examples, authentication, pagination, idempotency, and public failures.

02 · CodeWhat the business owns

Pure domain rules, use cases, owned ports, authorization decisions, and explicit adapter boundaries.

03 · CapabilitiesWhat the application selects

Statically linked plugins, typed services, facade features, declared dependencies, and explicit composition.

04 · ResourcesWhere code executes

Local processes, Axum HTTP, Lambda HTTP, SQS workers, static delivery, databases, and provider topology.

05 · EvidenceWhat can be claimed

Nearest-boundary tests, Plan IR, artifact digests, change sets, hosted verification, promotion, and rollback.

Real-world path: burst-ready orders

Reference architecture

Start with a mobile-friendly Orders API, then add only the runtime you can justify.

The blueprint connects duplicate-safe order placement, bounded list queries, optimistic concurrency, local SQLite or PostgreSQL, production data choices, optional asynchronous fulfillment, zero provisioned application compute, and exact release evidence.

Open the production blueprint

• TrafficQuiet most of the day, bursty during ordering windows
• SafetyIdempotency keys and required ETags at the HTTP boundary
• CostNo fixed application compute in the minimal AWS profile
• ProofSource, tests, plan, artifact, deployment, and observation stay distinct

What is documented here

Area	Shipped boundary	Use it to answer
HTTP resources	JSON data envelopes, bounded cursor pages, strong entity tags, idempotent create, and Problem Details	What must every client implement consistently?
Browser and native clients	Exact CORS inventories, response metadata, PKCE guidance, bounded retry, and installed-client compatibility	How does one API serve web, iOS, Android, desktop, and automation safely?
Plugins	Archive-visible metadata, static composition, facade features, and public offline conformance reports	What can be added without runtime scanning?
Data	Explicit SQLite, PostgreSQL, and access-pattern-specific DynamoDB adapters	Which persistence model matches the query and cost profile?
Realtime	Subscriber-only AppSync invalidation with authoritative HTTP resynchronization	How can clients refresh without treating events as durable truth?
Local and AI	Graph-derived development, bounded ProjectView, read-only MCP, and accessible workbench projections	What context can a person or agent inspect safely?
Testing	Domain, application, adapter, HTTP, plugin, deployment, and release evidence remain independent	Which claim has actually been exercised?
AWS	Zero provisioned application compute, explicit IAM and wake sources, guarded mutation, and visible residual cost	What will wake, persist, or cost money after deployment?

The golden path

new -> contract -> generate -> dev -> migrate -> seed -> test -> inspect
    -> package -> change set -> migrate target -> deploy -> verify
    -> promote exact artifact -> observe or compatibility-checked rollback

Each arrow is explicit and inspectable. Minco does not add a runtime service locator, Active Record layer, hosted control plane, hidden scheduler, or boot-time production migrations.

Popular topics

• Install Minco and build the first application.
• Use typed configuration, database lifecycle controls, and graph-driven local development.
• Add identity and sessions, browser and native client guidance, events and notifications, files and static sites, the realtime invalidation path, or the client feedback loop.
• Inspect the same bounded project model through ProjectView, MCP, and the local workbench, or select the DynamoDB Orders adapter.
• Set up Codex and Claude Code with project-local, version-matched Minco workflows.
• Review the complete feature catalog, built-in component catalog, and Cargo feature reference.

Continue with the framework tour, browse the exercised examples, or use the current CLI reference when you need exact command behavior.