Support / setup

Keep the setup
boring and clear.

Forge is intentionally local-first. When something breaks, start with the smallest observable check instead of guessing about a hidden service.

Open a GitHub issue

01 / first checks

Diagnose from the bottom up.

Copy the output, redact credentials, and include the command that produced it.

01

Environment

Confirm Python, uv, Git, and the project environment before inspecting providers.

shell
python3 --version
uv --version
git status
02

Forge runtime

Check the package, local ledger, and verifier without starting a hosted service.

shell
uv run forge status
uv run pytest -q
03

Optional integrations

Only then check provider credentials, Neatlogs delivery, or AO readiness. Their status is not the same as a passed Forge run.

Read integration boundaries

02 / common paths

Questions with
short answers.

Why does reflection fail with missing credentials?

The base verifier does not need a provider. The reflection path does. Add the required local values to `.env`, never to source or command arguments, then rerun the explicit reflection command.

Why is the AO section not a live tracker?

Because a healthy daemon or a listed session is not proof of an artifact-producing, independently verified completion. Forge keeps that proof point visible as unverified until it is observed.

Why is a generated skill still marked candidate?

Reflection proposes a skill. Forge requires applicability, A/B benefit, and held-out no-regression evidence before promotion. One successful run is not generalized learning.

How do I report a reproducible issue?

Include your OS, Python and uv versions, the exact command, sanitized output, run ID if one exists, and whether the failure is in the local verifier, provider reflection, Neatlogs, or AO boundary.