Troubleshooting in One starts from the exact failing subject and preserves the
evidence needed to explain it. Do not begin by deleting .one/, regenerating a
lock, widening authority, switching providers, or retrying a possibly
dispatched effect.
Start with disposition and definition
one status
one inspect <SubjectRef>
one inspect command:<command-name>Human diagnostics lead with the failed user action, owner stage, source span, smallest conflict, and safe next action. Machine output retains the diagnostic code and schema revision, exact subjects, structured details, source maps, proof obligation, and evidence references.
Follow definition links from a clause, package, trait, profile, command, provider, plan field, artifact, observation, or receipt to its exact defining package and revision. When a snapshot is stale or its defining evidence is unavailable, navigation says so rather than resolving against current but different content.
Diagnose by failure class
| Result | Meaning | Safe next action |
|---|---|---|
| Invalid source or type | Current authored bytes do not form an accepted owner value | Fix the exact source diagnostic and rerun the owning check |
| Unresolved dependency | Source, lock, package, resolver, or tool coordinate is absent or ambiguous | Inspect candidates; review one sync rather than accepting a guessed name |
| Incompatible change | The requested revision violates a compatibility obligation | Inspect impacted roots and author an explicit evolution plan |
Unsupported | No selected implementation provides the requested semantics | Add or select a real implementation; do not simulate success |
Unsatisfied | Candidates exist but none meet all hard requirements | Inspect rejected alternatives and change the requirement or eligible realization explicitly |
| Missing evidence | A claim cannot currently be trusted for this scope | Acquire or refresh the exact required evidence |
| Denied or pending | Policy rejected the action or required approval is absent | Request the exact approval; do not widen the subject or grant |
| Stale | Source, lock, observation, plan, or transaction base changed | Refresh, review the new delta, and produce a new exact record |
| Outcome unknown | Dispatch may have occurred but no terminal proof exists | Reconcile the existing operation identity; never issue a fresh blind retry |
| Internal defect | One violated its own contract | Preserve the bounded diagnostic reference and relevant evidence for support |
Partial results retain the successful subjects and independent failures. A batch does not collapse them into one generic exit status.
Inspect locks, plans, and releases
Useful questions include:
one inspect why <SubjectRef>
one inspect <PlanRef>
one inspect <OperationRef>
one observe <environment>Check that source revisions match the accepted lock, provider evidence is admitted and fresh, the Build consumed the selected plan, approval and grant subjects match, and observed postconditions belong to the same release and fence. A healthy process or provider response cannot substitute for a missing owner receipt.
Handle an interrupted effect
If a command ended after possible dispatch, retain its operation identity:
one reconcile operation:<OperationId>Reconciliation queries journal, fence, provider, receipt, and observation state. It may conclude committed, not dispatched, safely retryable, compensatable, or still unknown. Closing a terminal, cancelling a future, losing the daemon, or timing out does not prove rollback.
Use debug access deliberately
one debug <SubjectRef>A debug session is capability-scoped, time-bounded, attributable, and separate from production authority. Its observations do not silently become semantic truth or release evidence. Secret values remain redacted unless the exact debug capability explicitly authorizes their protected boundary.
For daemon-backed clients, verify the explicit endpoint with one daemon status. Stale daemon diagnostics may be shown as stale but cannot authorize
an edit, Build, plan, or release. Direct and daemon-backed commands resolve the
same project and owner contracts.
Clean only reconstructible state
one clean removes reconstructible projections and work directories. one gc
collects unreachable cache/CAS objects while retaining everything reachable
from locks, artifacts, plans, journals, evidence, snapshots, and sessions.
one reset local requires an explicit disposition for durable data,
unresolved effects, and protected evidence.
Corrupt caches may be evicted. Corrupt locks, plans, grants, journals, and evidence fail closed and use their owner's restore or recovery operation; they must not be treated as disposable cache.
See the failure model, recovery and continuity, and inspect and operate.