dyno-debuglisted

# Dyno Debug This skill investigates Dynobox failures without losing the original run signal. Assume `dynobox` is the installed public CLI package unless the user explicitly says they are debugging the local Dynobox repository. Treat a matrix run as evidence: rerunning one failed job can be useful, but it can also erase the cross-harness behavior that made the failure important. ## First Response Before rerunning anything, capture the original result: ```bash dynobox run <path> --debug ``` If the user already provided output, summarize: - scenario, harness, model, iteration, and status - failed assertions and expected order/content - observed tool commands - work directories and debug artifact paths, if present - which jobs passed in the same matrix Call out cross-harness differences explicitly. For example, "Claude passed and Codex failed in the same run" is usually more important than the isolated assertion failure. ## Preserve Matrix Context Do not treat isolated reruns as a replacement for the original matrix result. Record both: - original matrix outcome - isolated rerun outcome If an isolated rerun passes after a matrix failure, report it as nondeterminism or run-context sensitivity unless evidence points to a deterministic bug. Useful language: ```text The rerun passed, but that does not invalidate the original matrix failure. The original run captured a same-scenario, cross-harness difference that should be preserved as a first-class debugging artifact.