CAROOT

Photo analysis runs in a server-side edge function. The API key is an edge secret, and so are the system prompt and the response schema — the client cannot swap either, which is what keeps the model's scope fixed. The function also enforces the per-tier daily limit, because a limit checked on the device is not a limit.写真解析はサーバー側のEdge Functionで動きます。APIキーはEdge Secretで、system promptとレスポンススキーマも同様にサーバー所有です。クライアント側から差し替えられないので、モデルの扱う範囲が固定されます。プラン別の1日あたり上限もこの関数で判定します。端末側で確認する上限は上限ではないためです。

When an estimate is wrong, the corrected figures are stored against the normalised dish name and reapplied every time that dish appears. It also learns the alias: if the model calls something 醤油つけ麺 and you rename it, the correction is keyed to what the model said and mapped to what you called it, so the next photo of it comes back with your name and your numbers. Corrections with nothing in them are not learned, and saving a total without a breakdown clears the old breakdown rather than leaving it to contradict the total.推定が違っていたら、直した数値を正規化した料理名に紐づけて保存し、その料理が出るたびに再適用します。別名も学習します。モデルが「醤油つけ麺」と呼んだものを別の名前に直した場合、モデルが言った名前をキーに、ユーザーが付けた名前を値として保存するので、次に同じ料理を撮ると名前も数値もユーザーのものが返ります。中身が空の補正は学習せず、内訳なしで合計だけ保存したときは古い内訳を消します。合計と矛盾した内訳が残らないようにするためです。

Every write goes into a typed queue in local storage first, then to the server; it is removed only on success. Failures — offline, app killed, a transient error — are retried FIFO on the next write, on foreground, and at launch. While the queue is not empty, syncing down from the cloud is suspended, because the cloud is known to be behind. Before this, a failed write vanished silently and the next launch rolled local data back.書き込みはまずローカルに型付きのキューとして積み、それから送信し、成功したときだけ取り除きます。オフライン、アプリの強制終了、一時的なエラーで失敗した分は、次の書き込み時・フォアグラウンド復帰時・起動時にFIFOで再送します。キューが残っているあいだはクラウドからの取り込みを止めます。クラウドのほうが古いと確定しているからです。これがないと、失敗した書き込みは黙って消え、次回起動時にローカルが巻き戻されていました。

Photo analysis, barcodes and label reading can all fail — a bad photo, an unlisted product, a label that will not read — so search and manual entry are first-class paths rather than fallbacks. The app stays fully usable when the analysis service is unreachable, which is also why the food tables ship inside the app instead of behind an API.写真解析もバーコードもラベル読み取りも失敗しえます（写真が悪い、未収録の商品、読めないラベル）。そのため検索と手入力は代替手段ではなく対等な経路として用意しています。解析サービスに到達できなくてもアプリは問題なく使え、食品データをAPIの向こうではなくアプリ内に同梱しているのも同じ理由です。

Rows are separated per user by row-level security in the database. The subscription tier lands there from the store's webhook and is write-protected, so it cannot be set from the app — the paywall is a consequence of the data, not a check in the UI. Invite rewards work the same way: redeeming a code runs as a database function that refuses a second redemption, rather than as a client that promises not to ask twice.データはデータベースの行レベルセキュリティでユーザーごとに分離しています。課金プランはストアのWebhook経由で書き込まれ、書き換えから保護されているので、アプリ側からは設定できません。ペイウォールはUIのチェックではなく、データの結果として成立します。招待の報酬も同じ考え方で、コードの引き換えはデータベース関数として実行し、2回目を関数側で拒否します。クライアントが二重に要求しないと約束する形にはしていません。