mushi-integration

Mushi Integration Smoke Test

Degree of freedom: MIXED. Pass/fail judgment [HIGH freedom]; Stages 1–6 probes and DB verifies [LOW freedom — run exactly].

How to reason

1. Observe — each stage's CLI output and DB row
2. Interpret — stage failed vs still-pending vs expected-failure (test detected friction)
3. Classify — capture / triage / map / gen / run / pdca
4. Severity — classify-report down outranks optional Stage 7 dashboard drift

Worked example

Observe: mushi test → rep_…; DB still pending at 70s; mushi doctor was green. Interpret: capture wrote; classify-report did not. Classify: Stage 2 fail — check get_logs; do not start story mapping. Verify: summary marks Stage 2 ❌; later stages skipped; diagnose_setup next.

Self-critique before reporting

• Health first — mushi doctor green before Stage 1
• DB verify — each stage checked the row, not only CLI text
• Expected fail ok — Stage 5 failed still counts if the test executed
• Right owner — component down → mushi-health; targeted diagnosis → diagnose_setup

Exercises every stage of the Mushi pipeline end-to-end. Run after setup, after a deploy, or any time you need proof that the whole loop works.

Prerequisites [LOW freedom — run exactly]

• mushi doctor passes (all green) — run mushi-health first if unsure.
• At least one BYOK key for anthropic and firecrawl is active.
• You have the app URL you want to map stories from.

---

Stage 1 — Bug capture [LOW freedom — run exactly]

Send a real test report through the SDK pipeline:

mushi test

Expected: Test report submitted — id: rep_...

Verify in DB (Supabase MCP):

SELECT id, status, severity, category, created_at
FROM reports
ORDER BY created_at DESC LIMIT 1;

Expected: a row with status = classified and a non-null severity within ~30 seconds.
If still pending after 60 s: classify-report edge function failed — check get_logs(service: 'api').