Insforge Debug Skill 安全审计

27```bash28npx -y @insforge/cli diagnose --ai "<issue description>"29```

3637All commands run via `npx -y @insforge/cli ...`. The `(command)` shown next to each primitive is the actual CLI command — primitive names are concept labels, **not** CLI subcommand names (e.g., "DB health" is `diagnose db`, not `diagnose db-health`; "Policies" is `db policies`, not `diagnose policies`).38

3233## Edge function deploys3435`function-deploy.logs` captures backend deploy events (compile errors, push failures, registration errors). `functions list` confirms the final state — if the function isn't there or `status != active`, the deploy didn't fully take.36

9```bash10npx -y @insforge/cli diagnose --ai "<issue description>"11```1213The description should include: the error / failing URL / HTTP status / function slug — whatever concrete signal the user has.14

1213The description should include: the error / failing URL / HTTP status / function slug — whatever concrete signal the user has.14

3233Each line has timestamp + source + level + message. When chasing a known-time symptom:34351. Get the approximate timestamp from the user (when did the request fail?)362. Increase `--limit` until the window covers it (start 50, bump to 200 if needed)373. Look for the level (`ERROR` / `WARN`) and message — the message usually names the failing component3839For request-correlated symptoms (single failing URL), look for the request line in `postgREST.logs` (REST calls) or `insforge.logs` (auth/realtime/function dispatch) — both include the URL path.40

6869> Same bug, two surfacings. Writes (INSERT / UPDATE / DELETE) fail loudly with **403**. Reads (SELECT) fail silently with an **empty array** — PostgREST filters denied rows out instead of returning 403, so the request looks successful with zero rows. Diagnosis path is the same except step 1 only applies to the 403 variant.70711. **logs** (`postgREST.logs`) — *403 variant only*: find the policy violation event with table and role context. *Empty-result variant*: skip — no error is logged for silently-filtered rows.722. **policies** — list policies for that table; walk USING / WITH CHECK against the actual request and the JWT claim used.733. **metadata** — verify auth config (which claim feeds `auth.uid()` / `requesting_user_id()`; for third-party auth like Clerk/Auth0, is the provider registered as a JWT issuer?).744. **db query** (`db query "<sql>"`) — *empty-result variant only*: confirm rows that *should* be visible actually exist by querying as service role (not as the user): `npx -y @insforge/cli db query "SELECT id, user_id FROM <table>"`. Distinguishes "RLS filtered everything" from "no matching data exists".75

206207No login required; common PII patterns (emails, credential/key formats, public IPs, home-directory usernames) are redacted locally — pattern-based, so still keep user data out. Use `--component sdk --language <lang>` for SDK defects; `--component docs` or `--component skills` with `--doc` and `--expected` when documentation contradicts reality; `--type feature-request` when the finding is "not supported". Then continue the user's task with the workaround — never block on the report, and never file feedback for problems in the user's own app code or config. Full flag reference: the **insforge-cli** skill's Feedback section.208

192193## When the Root Cause Is InsForge Itself194195Some diagnoses end at an InsForge-side defect, not a project misconfiguration: a platform bug or regression, an SDK call that misbehaves, docs or a skill that contradict observed behavior, or a missing capability. A debug session is exactly where these get confirmed — report them while the evidence is in hand:196

197```bash198npx -y @insforge/cli feedback --json \199  --type bug --component backend --area db \200  --title "<one-line summary>" \201  --detail "<what happened vs expected, minimal repro>" \202  --command "<the failing call>" \203  --error "<verbatim error from logs>" \204  --workaround "<what you did instead>"205```

51```text521. Scan:    diagnose advisor --severity critical --json532. Triage:  pick one issue, read affectedObject + recommendation543. Verify:  inspect the affected object (db query / db policies / metadata)554. Fix:     apply the change (migration / RLS edit / secret rotation / config update)565. Re-scan: diagnose advisor --json — confirm isResolved=true for that ruleId576. Repeat with next critical, then warnings, then info

6162- **Scans are not real-time.** A new scan triggers when the platform schedules it; recommendations lag behind very recent changes. Force a fresh scan if needed.63- **Recommendations are static suggestions, not auto-fixes.** Always validate against current schema state before applying.64- **`affectedObject` is a string, not a typed reference.** It names the object but doesn't link to it — combine with [metadata](metadata.md) / [policies](policies.md) to inspect.65- **Not available when linked via `--api-key`.** Requires `insforge login` (Platform auth).

43441. **Start with severity**: `--severity critical` first; critical issues block launch.452. **Group by category** to keep the fix mode coherent (don't context-switch between RLS edits and index migrations).463. **`affectedObject` tells you where to fix** — it names the concrete schema object.474. **`recommendation` is usually actionable as-is**. Verify it makes sense (the recommendation may be generic), then apply via the appropriate primitive's tooling.48

5051```text521. Scan:    diagnose advisor --severity critical --json532. Triage:  pick one issue, read affectedObject + recommendation543. Verify:  inspect the affected object (db query / db policies / metadata)554. Fix:     apply the change (migration / RLS edit / secret rotation / config update)565. Re-scan: diagnose advisor --json — confirm isResolved=true for that ruleId576. Repeat with next critical, then warnings, then info58```

172   `operation_status` clears before declaring the incident resolved.1732. The resize **restarts the project as part of the change**, which also clears any wedged174   state — there is no separate user-facing restart, and a bare restart would only buy minutes175   before the next spike OOMs again. OOM under real load on the smallest sizes is common and176   expected, not a bug.177

157158If the command is unavailable (older CLI/backend, `--api-key` link mode), confirm manually in159**logs** (`postgres.logs`) via the crash-recovery aftermath — "terminating connection because of160crash of another server process" / "automatic recovery in progress" — **time-correlated with the1615xx burst**: recovery evidence alone only proves an unclean Postgres restart, so the timestamps162must line up before OOM becomes the leading diagnosis163([references/metrics.md](references/metrics.md)). With that evidence the fix is headroom, not a164retry loop:165

1651661. **Upgrade the instance** — `npx -y @insforge/cli projects upgrade-instance <type>`167   (`nano` → `micro` → `small` → `medium` → `large` → `xl`), or dashboard → Project Settings →168   Compute & Disk. On the free plan, upgrade to a paid plan first, then pick the size. The169   resize changes the bill and the CLI asks for interactive confirmation — get the user's170   go-ahead first, then run unattended with the CLI-level `--yes` (the `-y` in `npx -y` is171   npm's install flag, not the confirm-skip). The resize is async — poll `projects get` until172   `operation_status` clears before declaring the incident resolved.1732. The resize **restarts the project as part of the change**, which also clears any wedged