Debug Configuration

When Amara ignores a setting, skips your memory file, or behaves differently than you expect, the fastest fix is to see what Syntic Code actually loaded rather than what you think it loaded. This page covers the diagnostic switches that make the CLI’s behavior visible.

Verbose and debug output

Syntic Code can report what it is doing in far more detail than the normal transcript shows. Running with verbose output surfaces the steps it takes, the commands it runs, and the responses it receives — enough to see where a task goes wrong. Debug logging goes further, recording internal detail useful when you need to file an issue or trace a subtle fault. Turn these on when reproducing a problem so the evidence is captured while it happens, rather than trying to recall it afterward.

Diagnosing configuration

Most configuration surprises come from precedence: settings and SYNTIC.md memory are merged from several locations, and a value you set in one place may be overridden by a closer one. When behavior does not match your expectation, check every level that could contribute — project, user, and any directory-level files — and confirm which one is winning. Verbose output will show you which memory files were loaded and in what order, which usually reveals the culprit immediately.

Isolating the problem

To tell a configuration issue apart from a genuine bug, reduce the variables. Try the same task in a clean directory, or temporarily set aside your memory files, and see whether the behavior changes. If it does, the cause is in your configuration; if it does not, the cause is elsewhere. Once you have isolated it, capture the verbose or debug output for that minimal case — a small, reproducible example with logs is the most valuable thing you can bring to a support request.