meteor-debugginglisted

# Debug Meteor applications Find the first failing boundary before changing behavior. Produce a stable reproduction, evidence for one cause, and a verification target. Then use the skill that owns the repair. ## Diagnosis loop 1. Record the exact symptom, complete error and stack, command or user action, Meteor release, resolved Atmosphere and npm versions, environment, and last known working state. 2. Reproduce with the narrowest stable command or action before editing. 3. Classify the first uncertain boundary with the table below. 4. Read existing evidence before adding instrumentation. Compare client and server output, recent changes, and passing versus failing environments. 5. Add one targeted observation only when current evidence cannot answer the question. Do not combine a diagnostic change with a speculative fix. 6. State one falsifiable hypothesis and the observation that would reject it. 7. Change one variable, reproduce, and trace a bad value or event backward to its origin. 8. Fix the confirmed cause through the owning skill. Add a regression at the lowest reliable layer when the failure can recur. 9. Re-run the focused reproduction, then the affected suite or production-like check. Remove temporary diagnostics and artifacts. If several evidence-backed hypotheses fail, revisit the boundary map and assumptions before stacking mitigations or widening the change. ## Select the boundary | Symptom | First evidence | Read | |---|---|---| | Bui