nodefony-debug

Diagnoses Nodefony runtime failures using proven recipes for memory flakes, regressions, and test failures.

Updated Dec 19, 2023
One-click install
npx skills add https://github.com/nodefony/nodefony-core --skill nodefony-debug-nodefony
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: nodefony-debug
Source: https://github.com/nodefony/nodefony-core/tree/main/.claude/skills/nodefony-debug
Command: npx skills add https://github.com/nodefony/nodefony-core --skill nodefony-debug-nodefony

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When something breaks in a Nodefony application — a crash at boot, a memory leak, a test that passes alone but fails in a suite, or an unexplained regression — this Skill provides codified diagnostic recipes so you identify the real cause instead of guessing. ## Core Features & Use Cases - Memory flake diagnosis: Distinguishes real heap leaks from GC variance by running tests in isolation, and generalizes the rule that green-alone/red-in-suite means a shared resource, not a code regression. - Regression qualification: Uses a git-stash baseline procedure to prove whether a failure comes from your patch or pre-existing debt before you debug further. - Boot and integration triage: Reads var/last-boot.json via npx nodefony check to see degraded boots, and treats ECONNREFUSED/404 integration failures as a stopped server or wrong runtime mode first. - Use Case: Your integration suite fails with 59 red tests after a patch. The Skill directs you to start the dev server first, then run a stash-baseline comparison to determine whether the failure is yours or a pre-existing flake. ## Quick Start Ask the assistant to diagnose why my Nodefony integration tests fail with ECONNREFUSED and follow the debug recipes.

Frequently Asked Questions about nodefony-debug

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I diagnose a Nodefony memory test that fails only in the full suite?

Run the failing test in isolation with vitest using the -t flag on a freshly started server. If it passes alone, the failure is GC variance or a shared resource between test files, not a real leak, and you should never loosen the heap threshold.

How do I check if a test failure is caused by my patch?

Use the stash baseline procedure: git stash your changes, rebuild the affected module, restart the server, and rerun the suite. If it fails on the clean baseline too, the failure is pre-existing; if it only fails with your changes, it is a real regression.

Why do Nodefony integration tests fail with ECONNREFUSED or 404?

Integration tests require a running Nodefony server on ports 5151/5152, which turbo does not start automatically. Also verify the server runs in development mode, since production mode does not load policy-gated dev modules like @nodefony/test.

How do I see why a Nodefony application failed to boot?

Run npx nodefony check or read var/last-boot.json, which the kernel writes on every boot with the failed phase, cause, skipped bricks, and suggested remediation. Check the reported age of the report since it describes the last boot, not the current moment.

When should I not use this debug skill?

Do not use it for design, refactoring, or new builds; those belong to the framework development skill. It is strictly reactive, triggered by runtime symptoms like crashes, leaks, flakes, and regressions, and delegates specialized work to sibling skills.