mobile-crawler-triage

name

mobile-crawler-triage

description

Use after a mobile-autocrawler crawl has produced a report.json, when the user wants the results triaged: failures prioritized by severity, grouped by root cause, with concrete fix suggestions, reproduction steps, and which bugs to tackle first. Trigger phrases: "triage the crawl report", "what should I fix first", "analyze these crashes", "prioritize the bugs from the crawl", "what did the crawler find and how do I fix it". Reads report.json (and screenshots) and produces a prioritized, actionable bug report.

Mobile Crawl Triage

You turn a raw report.json from mobile-autocrawler into a prioritized, fix-oriented bug report a developer can act on immediately.

Inputs

• A report.json path (default ./mobile-crawler-report/report.json).
• Optionally the source repo of the app under test (to map failures to code).

Workflow

1. Load and digest

node scripts/triage-report.mjs ./mobile-crawler-report/report.json

This groups failures by severity and type, clusters likely-duplicate failures (same trigger label / same screen / same error text), and prints replay commands. Also read the report's accessibilityRecommendations and skippedActions.

2. Prioritize

Order work by impact using references/severity-rubric.md:

1. Critical — crashes, can't-launch, blank screens after common actions. These block users; fix first.
2. High — broken login/signup, frozen screens, RN redboxes.
3. Medium — visible errors, failed navigation, stuck loading.
4. Low — navigation loops, unlabeled elements, skipped-unknown. Within a tier, prefer failures at low depth (early in a flow → more users hit them) and those that reproduced on replay.

3. Cluster by root cause

Multiple failures often share one bug. Merge failures that have the same triggerActionLabel + stateName, or the same error text / log signature. Report the cluster once with a count, not N near-duplicates.

4. Diagnose & suggest fixes

For each cluster, use references/fix-playbook.md to map symptom → likely cause → concrete fix. If you have the app's source, grep for the trigger label / screen name / error string to point at the probable file. Inspect the evidence screenshots and logSnippet (e.g. a SIGSEGV or undefined is not an object stack pins it down).

5. Verify before asserting

Don't claim a bug is real on the crawler's word alone — confirm it reproduces:

mobile-autocrawler replay --report ./mobile-crawler-report/report.json --failure failure_001

Mark each finding as confirmed (reproduced) or needs manual check.

6. Output

Produce a single prioritized markdown report:

• A one-line verdict (e.g. "2 critical, 1 high — ship-blocking").
• A ranked table: severity · title · screen · depth · reproduced? · replay cmd.
• Per critical/high finding: root-cause hypothesis, suggested fix, the exact repro steps, and a pointer to the likely code if the repo is available.
• A short "tech debt" section from accessibilityRecommendations (add testIDs).
• An honest coverage note (what wasn't reached, and why).

Don'ts

• Don't invent failures that aren't in the report.
• Don't suggest disabling the safety guard or tapping skipped destructive actions.
• Don't overstate confidence on failures that didn't reproduce.

References

• references/severity-rubric.md — how to rank and what each severity means.
• references/fix-playbook.md — symptom → cause → fix for each detector type.