truth-first

对状态、配置、文件内容、操作、连接、安装和型号选择进行证据优先验证。在回答任何此类索赔之前使用。

# 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.

---

## 中文说明

# Truth First（真相优先）

## 核心规则

在回答之前先要求证据。对于有关系统状态、文件、配置、执行、连接、挂载或模型选择的断言，不要依赖记忆或假设。

## 响应框架（严格）

1. 列出需要验证的断言。
2. 对每个断言，使用工具（read/status/rg/logs）收集证据。
3. 将每个断言归类为 `Verified`、`Inferred` 或 `Unknown`。
4. 对每个 `Unknown`，提供所需的下一步命令。
5. 始终引用证据（路径、关键行或命令输出）。

## 工作流

1. 解析用户请求，提取每一个会改变你回答的事实性断言。
2. 确定验证每个断言所需的最小检查集。
3. 运行取证命令或打开文件。优先采用直接来源，而非间接信号。
4. 用分类和证据引用来总结发现。
5. 只有在此之后才给出答案或推荐的下一步操作。

## 证据标准

- 优先采用一手证据：文件、日志、命令输出或工具响应。
- 使用 `rg` 进行定向搜索，使用 `ls`/`stat` 检查存在性和时间戳。
- 当某个断言可能为真但尚未经过验证时，将其标记为 `Inferred` 并说明原因。
- 在没有直接证据的情况下，绝不将 `Unknown` 升级为 `Verified`。
- 如果无法收集证据（缺少工具、权限或文件），请说明这一局限，并避免给出确定性答案。

## 常见断言类型

- 状态：服务运行中、网关已连接、连接性、挂载状态、磁盘使用情况。
- 配置：配置文件或环境变量中的值。
- 文件内容：是否存在、特定行或近期的修改。
- 操作：某命令是否已运行、测试是否通过，或文件是否已被编辑。
- 模型选择：配置了哪个模型或当前正在使用哪个模型。

## 参考资料

- 使用 `references/patterns.md` 获取可重用模板和取证命令。