0.2.0への移行

Nagi 0.2.0は2026-10-20に公開しました。このページはHTTP、認証・認可、応答・rate予算、SQLite APIの変更点をまとめます。0.1.xのバイナリには新APIがありません。旧HTTP/issuerの併存によるpolicy省略・無期限proofの維持を避けるための変更です。

Host変更は0.2.0に含まれます。旧任意Host、末尾dot、特殊port表記、proxy内部Hostは明示登録/書換えへ移行します。設定setterはmove＋Resultで、先のOptionsを失敗時に復活させません。新APIは既resource registry/checked facts/sealed emissionを通り、High・保存Low・手書きLowで同じ契約を使います。

ローカル例ではlistener portとwire Hostを同じ値に設定します。既定supervised-serviceは8090とlocalhost:8090を使います。portを変える場合はNAGI_HTTP_AUTHORITYも合わせます。NAGI_HTTP_AUTHORITYは一つのHTTP Host authorityで、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とbackend Hostは別の起動情報です。serveの平文loopback HTTPだけでbrowser認証を完成と呼びません。ローカルTLS frontendならorigin https://localhost:8443、wire localhost:8080、実peer 127.0.0.1を設定し、証明書のtrust・Forwarded除去・HTTP/1.1終端を配置側で確認します。Secure Cookie例外やHost一致によるCSRF免除はありません。このHost移行の説明単独ではOrigin/CSRF/pre-loginの最終受入を示しません。

handlerは常にasync (http.Request,shared[S],A)->Result[http.Response,E]です。旧自動body/query/path抽出はhandlerで明示的にparse/decodeし、JSON応答をhttp.jsonへ変換します。既存CRUD/Resultの業務動作は移行後のnativeテストへ対応付けています。ルート登録はfallibleです。重複method/pathや曖昧なcapture patternはruntime登録Errになり、起動しません。動的pathの既存標準APIを維持し、旧decorator専用の静的path検査を新しい文字列推論仕様へ置き換えません。

AuthScope/Grantの所有Option/Resultと同task async呼出しは維持します。別Task/Actorへのowned delegationは破壊的変更でSameTask違反です。長い仕事はrequestと独立した業務commandを設計し、request proofをqueueへ保持して後で使うことはできません。容量待機後の保護operationは失効と同じgateでpermitを発行します。発行済みcommandの取消・rollbackは保証しません。

最小HTTP · 認証・認可と失敗表 · API reference · 移行テスト対応表

move/Task/spawnの意味論、SQLite Pool/Txの取得予算・close・actual join・Outcomeを変更しません。旧Db/dynamic SQLの一本化は独立SF05で行います。custom Rust/Axum hostは標準dispatcherの保証外のtrusted境界として残す理由を明記します。旧standard入口をそこへ自動fallbackする互換層はありません。

SF07の応答・rate移行

• status先頭のempty/text/bytes/json/html_responseは、http.response_context(view(request))から借りたContextを第1引数へ追加します。すべてResult[Response, Error]なので直接返すかtryで処理し、factoryのResultをさらにokで包まないでください。
• Appとroute固有のmapperは、どちらもfn(view[http.ResponseContext], E) -> Result[http.Response, Error]へ変更します。業務エラーEとmapper自身のErrorは別の失敗です。
• Optionsへresponse_limits／with_response_limitsとrate_limits／with_rate_limitsを明示し、全routeにrate_policy／rate_routeを設定します。rate_subjectは認証済みsubjectを得るprofileだけで使います。新予算の暗黙defaultや、実行可能な無制限の旧factoryは設けません。
• 引数順・process内の支持範囲・拒否時動作はAPIリファレンスを参照してください。release CIは4 OSとbrowser受入に成功しました。サンプル予算は説明用で、実運用の容量や遅延を保証しません。

SQLite SF05

通常checkへSQL engineを必須にしません。opt-in SQLは直接QueryとParameters builder列をprepare-onlyで検査し、不明構造と実値型/NULLはruntimeへ残します。FromRowとRust固定SQLはtrusted adapter境界で、request用動的factoryを再exportしません。Session世代管理はSF02に含まれます。保護された業務更新には引き続き同じSQLite file・同じTxの世代/owner predicateまたは再確認が必要で、任意adapterを自動検証する保証はありません。汎用queryへGrantを足すだけのtenant保証はありません。

SQLite · 保護操作 · SF05契約