Migrating to 0.2.0

Nagi 0.2.0 was released on 2026-10-20. This page describes its HTTP, authentication/authorization, response/rate-budget and SQLite API changes. Published 0.1.x binaries do not provide these APIs. The change avoids preserving policy-free standard HTTP and indefinite issuers through legacy coexistence.

The Host change is included in 0.2.0. Migrate arbitrary Hosts, trailing dots, special port spellings and internal proxy Hosts to explicit registration/rewriting. Setters use move and Result; failure cannot revive earlier Options. APIs use the existing resource registry, checked facts and sealed emission, with the same contract for High, saved Low and handwritten Low.

Local examples set the listener port and wire Host to the same value. The default supervised-service uses port 8090 and localhost:8090. If you change the port, update NAGI_HTTP_AUTHORITY too. This variable is one HTTP Host authority, separate from the HTTPS external origin. Unix:

NAGI_SAMPLE_PORT=8090 NAGI_HTTP_AUTHORITY=localhost:8090 nagic run --project test-nagi-code/library-examples/supervised-service

PowerShell:

$env:NAGI_SAMPLE_PORT = '8090'
$env:NAGI_HTTP_AUTHORITY = 'localhost:8090'
nagic run --project test-nagi-code/library-examples/supervised-service

HTTPS origin and backend Host are separate startup facts. Plaintext loopback serve alone does not complete browser authentication. A local TLS frontend can use origin https://localhost:8443, wire localhost:8080, real peer 127.0.0.1; verify certificate trust, Forwarded stripping and HTTP/1.1 termination in deployment. No Secure Cookie exception or Host-based CSRF exemption is provided. This Host-migration subsection alone does not establish final Origin/CSRF/pre-login acceptance.

Handlers have async (http.Request,shared[S],A)->Result[http.Response,E]. Replace automatic body/query/path extraction with explicit parsing/decoding and http.json responses. Existing CRUD and Result behavior is mapped to migrated native tests. Registration remains fallible: duplicate method/path and ambiguous capture patterns return runtime registration Err before startup. Dynamic paths remain part of the existing standard API; decorator-specific static path checking is not replaced with a new string-inference language specification.

Owned local Option/Result and same-task async calls remain available for AuthScope/Grant. Owned delegation into another Task or Actor is a breaking change rejected by SameTask. Long-running work needs independently authorized business commands rather than a retained request proof queued for future use. Protected operations issue a permit under the invalidation gate after capacity wait. Cancellation/rollback of already admitted commands is not guaranteed.

Minimal HTTP · Authentication and failure table · API reference · Migration test map

Move, Task/spawn semantics and SQLite Pool/Tx acquisition budgets, close, actual join and Outcome are preserved. Unifying old Db/dynamic SQL belongs to SF05. Custom Rust/Axum hosts remain explicit trusted boundaries outside the standard dispatcher guarantee; no compatibility layer automatically falls back to them.

SF07 response and rate migration

• Replace status-first empty/text/bytes/json/html_response calls with a borrowed context from http.response_context(view(request)) as their first argument. Every factory returns Result[Response, Error]; return it directly or use try. Do not wrap a factory Result in a second ok.
• Change both App and route-specific mappers to fn(view[http.ResponseContext], E) -> Result[http.Response, Error]. The business error E and the mapper's own Error are different failures.
• Add explicit response_limits/with_response_limits and rate_limits/with_rate_limits to Options, then rate_policy/rate_route for every route. Use rate_subject only for verified-subject profiles. There is no implicit new budget and no executable unbounded compatibility factory.
• See the API reference for argument order, process-local scope and refusal behavior. The release CI passed all four OSes and browser acceptance. Example budgets remain illustrative, without a production sizing or latency guarantee.

SQLite SF05

Ordinary check needs no SQL engine. Opt-in checks prepare direct Query and Parameters builder chains, leaving unknown structure and actual types/NULL to runtime. FromRow and fixed Rust SQL remain trusted adapter boundaries, without reexporting request-facing dynamic factories. Session generation management is included in SF02. Protected business updates still need session-generation/owner predicates or revalidation in the same Tx and SQLite file; arbitrary adapters are not checked automatically. Adding a Grant to a generic query cannot promise tenant isolation.

SQLite · Protected operations · SF05 contract