new open-source release: a route-first AI debugging router, plus the seven-family map behind it

[onestardao]

New release: a route-first AI debugging router, and the seven-family atlas behind it

hello everyone,

today I want to share a new open-source release from the WFGY line.

This one is built for a pain point that many AI builders, vibe coders, agent developers, and workflow engineers already feel every day:

AI can generate code very fast, but debugging still breaks because the first cut is often wrong.

The model sounds confident.
The fix sounds plausible.
The conversation feels productive.
But the repair path slowly drifts.

One patch creates two more issues.
The system gets messier.
The logs get longer.
The root cause stays blurry.
And after enough wasted cycles, you realize the biggest cost was not the final bug itself.

It was the first wrong repair move.

That is the exact problem this release is trying to reduce.

---

60-second entry

If you just want the fastest possible way to try it, start here:

1. Download the Router TXT Pack

Download troubleshooting-atlas-router-v1.txt

2. Drop it into your usual AI workflow

You can use it with ChatGPT, Claude, Gemini, Cursor, Copilot, or whatever workflow you already use for AI debugging.

3. Keep building normally

4. When debugging starts feeling vague, messy, or suspiciously overconfident

Let the model route the failure first before it starts throwing repairs around.

That is the whole quick-start flow.

If you want a practical walkthrough right away, use this:
Router Usage Guide

If you want the larger product-facing entry first, use this:
Problem Map 3.0 Troubleshooting Atlas

No install.
No signup.
No special infra.

Just a compact route-first layer you can load once and pressure-test on real cases.

---

What this release is trying to improve

A lot of AI debugging waste comes from one boring but very expensive problem:

the system starts repairing the wrong layer first.

For example:

• what looks like a reasoning problem may actually be a grounding problem
• what looks like a memory problem may actually be an observability problem
• what looks like hallucination may actually be retrieval anchor drift
• what looks like execution trouble may actually begin with readiness, ordering, hidden contracts, bridge integrity, or closure failure
• what looks like a policy or safety discussion may actually still be a diagnosability problem because the failure path is not exposed clearly enough yet

If the first cut is wrong, the model can still sound smart while moving in the wrong direction.

That is where a lot of hidden debugging time gets burned.

So the goal here is not “solve everything automatically.”

The goal is narrower and more useful:

make the first routing cut more honest, more structural, and less wasteful

---

What this actually is

The Router TXT Pack is the first compact executable surface built from the broader Atlas system.

The short version is:

route first
repair second
prefer structural failure over topic similarity
prefer earliest decisive failure over downstream consequence

This is not a magic one-shot repair prompt.

It is a route-first debugging layer designed to help humans and AI systems avoid walking into the wrong repair path too early.

If you want the full product-facing page, start here:
Problem Map 3.0 Troubleshooting Atlas

If you want the system hub behind it:
Atlas Hub

---

Why I want to show the seven-family classification clearly

I do not want people to read this as “just another prompt trick.”

The Router is only the fast executable surface.

Behind it is a broader failure classification system. That matters because the real problem in AI debugging is often not “missing one label.” The real problem is that multiple labels look plausible at the same time, and once the wrong family absorbs the case too early, the first repair move usually becomes cosmetic, rhetorical, or downstream.

That is exactly what the Atlas is trying to reduce.

The seven-family map is the classification spine behind the router.

If you want the frozen core behind this structure, read:
Atlas Final Freeze v1

If you want the teaching layer for how major cuts should be made, read:
Canonical Casebook v1

---

The seven-family map

F1. Grounding and Evidence Integrity

This family covers failures where the system loses correct alignment with external evidence anchors, truth anchors, world anchors, or semantic targets.

Broken invariant: evidence or truth coupling is broken

Typical examples:

• retrieval grounding failure
• semantic grounding mismatch
• OOD grounding failure
• synthetic truth grounding failure
• train-deploy grounding gap

Typical first repair direction:

• re-grounding
• evidence verification
• source-anchor checks
• target versus proxy separation

---

F2. Reasoning and Progression Integrity

This family covers failures where the reasoning chain, decomposition chain, recursive chain, or collapse-recovery path loses continuity, controllability, or recoverability.

Broken invariant: progression continuity is broken

Typical examples:

• interpretation collapse
• long-chain continuity failure
• collapse and recovery failure
• symbolic reasoning strain
• recursive horizon instability

Typical first repair direction:

• decomposition reset
• checkpoint insertion
• recovery scaffolds
• continuity guards
• collapse detectors

---

F3. State and Continuity Integrity

This family covers failures where memory, role, ownership, session thread, agent thread, or continuity thread no longer stays stable across steps, sessions, or interacting entities.

Broken invariant: state continuity is broken

Typical examples:

• memory continuity failure
• role contamination
• ownership discontinuity
• viable state-space collapse
• multi-agent continuity instability

Typical first repair direction:

• persistence guards
• role fencing
• ownership tracing
• continuity restoration
• provenance checks

---

F4. Execution and Contract Integrity

This family covers failures where readiness, ordering, bridge integrity, liveness, closure, protocol, or enforcement skeletons fail to close correctly.

Broken invariant: execution skeleton closure is broken

Typical examples:

• bootstrap ordering failure
• deployment deadlock
• pre-readiness execution failure
• bridge failure
• cross-layer liveness degradation

Typical first repair direction:

• readiness validation
• ordering checks
• liveness watchdogs
• closure path tracing
• bridge checks

---

F5. Observability and Diagnosability Integrity

This family covers failures where the system cannot stably expose, trace, audit, interpret, or anticipate the structures required to understand and intervene in the failure.

Broken invariant: diagnosability visibility is broken

Typical examples:

• failure path opacity
• oversight coverage failure
• interpretability pressure
• fragility signature blindness
• regime-shift warning delay

Typical first repair direction:

• observability insertion
• trace exposure
• fragility probes
• warning horizon extension
• audit-route enhancement

---

F6. Boundary and Safety Integrity

This family covers failures where goal, control, incentive, collective, or regime boundaries drift, erode, fragment, or become captured.

Broken invariant: boundary integrity is broken

Typical examples:

• alignment boundary drift
• control boundary erosion
• incentive misalignment drift
• coordination-boundary fragmentation
• collective regime overshoot

Typical first repair direction:

• alignment guards
• control-path audit
• incentive rebalancing
• legitimacy repair
• safe-corridor monitoring

---

F7. Representation and Localization Integrity

This family covers failures where symbolic shells, formal containers, layouts, local anchors, explanations, or synthetic structures fail to preserve structure faithfully.

Broken invariant: representation container fidelity is broken

Typical examples:

• symbolic representation fidelity failure
• logic descriptor fidelity failure
• formal container adequacy failure
• localization and layout anchoring failure
• explanation fidelity distortion

Typical first repair direction:

• descriptor fidelity audit
• symbolic preservation
• layout validation
• local-anchor repair
• hierarchy checks

---

Why this classification matters in real debugging

Many real debugging cases are expensive because several families can look plausible at once.

For example:

• F1 vs F7
  Is the main damage loss of alignment with external truth anchors, or distortion of the symbolic or formal container carrying the task?

• F5 vs F6
  Is the main issue still lack of visibility and diagnosability, or has the actual boundary structure already drifted?

• F3 vs F4
  Is this continuity-thread failure, or is the operational closure skeleton itself broken?

• F2 vs F7
  Is the reasoning chain failing, or is the reasoning container already malformed?

This is why the Atlas treats boundary cuts seriously.

Bad routing is often just bad boundary reading.

And once the wrong family absorbs the case too early, the first repair move usually becomes cosmetic, rhetorical, or downstream.

That is the waste this system is trying to reduce.

---

What makes the Router different from a generic prompt

The Router is built around a strict sequence.

It asks the model to do the following in order:

1. normalize the case structurally
2. identify the earliest decisive failure
3. choose one honest primary family
4. test the nearest competing family
5. name the broken invariant
6. suggest the first repair direction
7. warn against likely misrepair
8. stay coarse if evidence is weak

The required output is intentionally compact:

• primary_family
• secondary_family
• why_primary_not_secondary
• broken_invariant
• best_current_fit
• first_fix_direction
• misrepair_risk
• confidence
• evidence_sufficiency

That structure matters because it forces the model to do more than say “maybe it is a prompt issue.”

It has to actually commit to a route and defend the cut.

If you want to use it immediately, go here:
Download troubleshooting-atlas-router-v1.txt

If you want the practical usage notes, go here:
Router Usage Guide

---

What this is not

To keep the claim honest, this release is not:

• full autonomous debugging
• full autonomous repair
• a benchmark cheat code
• a replacement for tests, traces, logs, or observability tooling
• a claim that all failures are already exhaustively solved
• a claim that the Atlas is the final closed map forever

The intended claim is smaller and stronger:

if the first routing cut becomes more honest and more structural, a meaningful amount of downstream debugging waste can shrink with it

If you want the broader context behind that claim, start here:
Problem Map 3.0 Troubleshooting Atlas

---

How I suggest people test it

The best way to evaluate this release is not by reading slogans.

The best way is to try it on real cases.

Especially useful cases include:

• messy failures with multiple plausible causes
• cases where the model keeps sounding right but keeps fixing the wrong thing
• cases where neighboring family cuts are genuinely hard
• cases where there is a lot of output but very little real diagnosability
• cases where the first repair move made the system worse
• agent, tool-calling, RAG, or workflow cases where the system keeps drifting instead of converging

A very simple test loop looks like this:

1. take a real failure case
2. load the Router TXT Pack
   Download troubleshooting-atlas-router-v1.txt
3. ask the model to route the case before repairing it
4. compare the route against your own diagnosis
5. compare the first repair move against what you would normally do
6. see whether the route reduced wasted motion or made the case clearer

Good routes are useful.
Misroutes are useful too.

Both help sharpen the system.

---

If you want to help pressure-test this release

If you try it, feel free to reply with:

• the case
• the route it chose
• where it helped
• where it failed
• which family boundary felt unclear
• what kind of first-fix direction would have been better

If you want to look at the evidence layer as well, see:
AI Eval Evidence

If you want to see official repair-direction examples, see:
Official Flagship Demos

---

Full navigation

Fast entry

Download troubleshooting-atlas-router-v1.txt

Practical walkthrough

Router Usage Guide

Main landing page

Problem Map 3.0 Troubleshooting Atlas

System hub

Atlas Hub

Frozen core

Atlas Final Freeze v1

Teaching layer

Canonical Casebook v1

Evidence layer

AI Eval Evidence

Demo layer

Official Flagship Demos

---

One-line version

This release is a compact route-first debugging surface for AI systems, backed by a seven-family troubleshooting atlas designed to reduce wrong-first-fix behavior.