サーバーはありません。それでもバグはあります。

何を測るか

ページが出すすべての Supabase クエリ

1回の操作あたり何本走り、それぞれ何行返し、レスポンスがどれだけ大きく、どれだけ時間がかかったか。「遅くなった」の正体は、ほぼ必ずここにあります。

ページの速さを、ルートごとに

読み込んだ全員にわたる実際の p75 での LCP、INP、CLS、TTFB — 1台のマシンによるラボの点数ではありません。国別に分解します。あなたのところでは問題ないページが、遅延の大きい場所では使い物にならないことがあるからです。

人が何を押し、それが効いたかどうか

何も起きなかったクリック、同じ操作部品への繰り返しのクリック、そしてページを何百回も描き直す操作。

認証、ストレージ、Edge Function、リアルタイム

Supabase のアプリは1つではなく4つのサービスです。エージェントは各エンドポイントが何をするかを理解していて、いくらかかったかだけを見ているのではありません — だから拒否されたサインイン、存在しないカラム、却下された書き込み、購読に失敗したチャンネルが、それぞれ匿名の「失敗したリクエスト」ではなく、そのものとして届きます。

動く前のコード

ハンドラのないボタン、依存関係のせいで永遠に回り続けることが確定している副作用、後片付けされない購読。これらは実行時に何も出しません — 一度も取り付けられなかったハンドラは測れません — ので、ビルド時にソースから読み取り、そのファイルが実際に受けているトラフィック順に並べます。

何を見つけるか

どれも1つ前のリリースと比較されます。だから検出結果は、日付ではなく変更を名指しします。

フィードに何が届くか

読むためのダッシュボードではありません。検出1件につきカード1枚。数値と、それを変えたリリースと、コーディングエージェントが修正を書くのに必要な証拠が付いています。

導入方法

これは手作業では入れません。Lovable のチャットにプロンプトを1つ貼れば、エージェントが組み込まれます — Vite プラグイン、init の呼び出し、そしてテレメトリを転送するルート。おかげでキーがバンドルに乗ることは一度もありません。ログインすれば、そのプロンプトはあなたのキーを入れた状態で書かれます。

npm install @sixty-sh/supabase

// vite.config.ts
import drift from '@sixty-sh/supabase/vite'
export default defineConfig({ plugins: [react(), drift()] })

// src/integrations/supabase/client.ts — the file every Lovable app has
import { withSixty } from '@sixty-sh/supabase'

export const supabase = withSixty(createClient(URL, ANON_KEY), {
  key: 'sixty_pk_…',
  service: 'my-app',
  endpoint: 'https://ingest.sixty.sh',
})

そのあと2回公開してください。比較は時計ではなく公開に紐づいているので、最初の検出は次の公開のあとに届きます — バージョンが1つだけでは比べる相手がありません。

できないこと

• 公開ビルドからの検出は、クエリとルートを指します。ソースの行は指しません。本番のバンドルは圧縮されていて、それを元に戻すソースマップはまだ読んでいないので、「このファイルの40行目」ではなく「このページのこのクエリ」になります。
• Lovable のプレビューでは足りません。指紋付きのアセットを持たない開発サーバーで動くため、比較を固定できるバージョンが存在しません — 比較には本物の公開が2回必要です。
• ここではサーバーを見張っていません。あなたにサーバーがないからです。あとから自前の Edge Function を足す場合、それが見えるようになるには Node のエージェントが要ります。

これが理由でここに来たのなら