Coming soon. A dedicated debugging guide is being written. The existing material lives across a few pages today; the section below points to the most useful starting points.

Where to look first

• Compiler errors. mufl-compile reports type and parse errors with the meta stage enabled. If a transaction fails on an unexpected type, recompile with meta on and the type system will usually tell you where the mismatch is. See The MUFL Type System for what meta enforces.
• Runtime errors from a packet. Transactions can abort with a reason. The reason string is returned to the caller in the transaction result. See The abort Statement.
• Wrapper logs. The ADAPT wrappers take a --logger_config flag with verbosity levels (ERROR | WARNING | INFO | DEBUG_MESSAGES | DEBUG), per-message-ID filters, and stdout/stderr redirection. Start at INFO and step down to DEBUG for a single message type when you are zeroing in on a specific exchange.
• Message broker trace. Setting the broker logger to DEBUG prints every routed envelope, which is the fastest way to confirm whether the failure is in routing or inside the destination packet.

What is planned

A future revision of this page will cover:

• Running a packet locally under the REPL with mufl -r for faster-than-deploy iteration.
• Reproducing a failure from a backup-storage transaction log.
• Inspecting .muflo provenance — confirming you are running the artifact you think you are running, by hash.
• Diagnosing browser-WASM-specific failures (initialisation, attestation, randomness).

If you hit a debugging scenario that is not covered here, please file feedback through Contact Us; the page is being prioritised by what real users report.