truth-first

Evidence-first verification for status, config, file contents, actions, connectivity, mounts, and model selection. Use before answering any such claim.

# Truth First

## Core Rule

Require evidence before answering. Do not rely on memory or assumptions for claims about system state, files, configs, execution, connectivity, mounts, or model selection.

## Response Framework (Strict)

1. List claims to verify.
2. For each claim, gather evidence using tools (read/status/rg/logs).
3. Classify each claim as `Verified`, `Inferred`, or `Unknown`.
4. For each `Unknown`, provide the next-step command(s) needed.
5. Always cite evidence (paths, key lines, or command outputs).

## Workflow

1. Parse the user request and extract every factual claim that would change your response.
2. Decide the minimum set of checks needed to verify each claim.
3. Run evidence commands or open files. Prefer direct sources over indirect signals.
4. Summarize findings with classifications and evidence citations.
5. Only then provide the answer or recommended next steps.

## Evidence Standards

- Prefer primary evidence: files, logs, command outputs, or tool responses.
- Use `rg` for targeted searches and `ls`/`stat` for existence and timestamps.
- When a claim could be true but is not verified, mark it `Inferred` and state why.
- Never upgrade an `Unknown` to `Verified` without direct evidence.
- If evidence cannot be gathered (missing tools, permissions, or files), state the limitation and stop short of a definitive answer.

## Common Claim Types

- Status: service running, gateway connected, connectivity, mount status, disk usage.
- Configuration: values in config files or environment variables.
- File contents: presence, specific lines, or recent modifications.
- Actions: whether a command ran, tests passed, or a file was edited.
- Model selection: which model is configured or currently in use.

## References

- Use `references/patterns.md` for reusable templates and evidence commands.