Skip to main content
If a step fails, you do not need to understand the whole system to investigate it. Read the error, find the closest match below, and check that one thing first. An error code is a short label for what went wrong. Start with the exact command, package version, operating system, and reported error code. Keep the source commit and relevant artifact references. Remove credentials and unrelated private context before sharing a report.

​
Installation and local State

The published code resolves local objects only. A repository URL in --repository is not a download instruction.

​
Context selection

​
Review and execution

An insufficient_evidence review is a valid outcome. Add the missing material or narrow the objective before defining another attempt. The 0.1.0a4 adapters check specific CLI versions and protocols. Confirm the configured and installed versions agree. A protocol failure is not evidence of a Windows scheduling failure. If the Instance is already running, inspect its existing execution. Do not clear its lock merely to get another attempt started. The Windows file lock and the saved execution record answer different questions: whether another local execution owns admission, and what task outcome was durably recorded. If a start record exists without a terminal record, or the result reports incomplete persistence, inspect known work and artifact references before repeating an operation. A reporting failure can occur after useful work was completed.

​
Memory and remote transport

A local checkpoint is not a remote backup. Confirm the synchronization result establishes the intended remote State. An uncertain transport outcome requires inspection and reconciliation; repeatedly pushing or rerunning a model does not resolve the uncertainty by itself.

​
A useful issue report

Include the release version, OS, Python/Git versions, exact relevant commit, minimal command or API call with sensitive values removed, error code, and the expected versus observed result. For review issues, include which context was selected and whether the result was an adapter observation or durably saved evidence.

​
Public reference

State errors, Context errors, Execution provenance.

​
The worker says finished, but the coordinator sees nothing

Verify the result branch and report were pushed to the intended remote. Compare the exact commit and report path. If the upload is missing, publish the existing work rather than rerunning it. If a report is stale, read the newer evidence before choosing another task.

​
A hook or launcher appears configured but does nothing

Configuration, loading, triggering, and execution are separate facts. Obtain the entry signal, last successful phase, stdout, stderr, exit status, and actual OS/shell before changing quoting or retrying. Test the real executing shell. Keep a stable hook entry and develop behind it when the runtime supports that pattern. This is troubleshooting guidance, not a claim of automatic hooks in 0.1.0a4.