archeology

STARTER_CHARACTER = 🏺

考古

根据留存的证据重建发生过的事情，然后依据这份记录回答问题。

交付文件为 .llmtmp/timeline.md。工作笔记保留在 .llmtmp/ 下。未经要求，不要写入其他内容。

输入

参数为一个或多个问题，以 ? 分隔。将它们编号为 Q1 至 Qn，并在整个运行过程中保持编号不变。如果未提供参数，请至少索要一个问题，并在收到问题之前停止。不要针对未明确提出的问题进行研究。

来源

这些是标签，不是指令。使用环境提供的任何工具访问每个来源。

Jira、Confluence 和 Slack 是种子来源。只有证据指向其他来源时，才去访问它们。 不要询问要使用哪些来源。

• 问题跟踪系统和项目组合看板
• Wiki、设计文档和决策记录
• 聊天
• 邮件、日历和会议记录
• 源代码仓库：提交、拉取请求、审阅者、分支策略、流水线、发布
• 代码本身
• 云端运行时状态
• 成本和账单
• 日志、追踪、监控和事件历史
• 代码质量和扫描历史
• 词典和术语注册表
• Agent 记忆和会话记录
• 外部文档、供应商材料和网络

流程

1. 界定问题。 重述每个问题。说明这些问题涵盖的时间范围。说明范围边界，即这是关于谁的经历，而不是谁的。
2. 种子来源扫描。 并行派遣三个子 Agent，分别查询 Jira、Confluence 和 Slack。向每个子 Agent 提供问题、主题、时间范围、引用格式以及以下证据规则。这三项查询会提供其他查询所需的所有标识符。每个子 Agent 都应返回带日期和引用的发现，以及其确认的锚点：项目键、史诗键、空间键、页面 ID、频道 ID、仓库名称、环境名称，以及记录中提及的所有其他系统。
3. 跟进证据。 每一轮都应开辟新方向。工单提及一个仓库，页面提及一个仪表板，消息提及一个事件或邮箱。针对每个新提及的来源并行派遣一个子 Agent，并持续跟进，直到某一轮没有发现新内容。判断哪些线索值得追查，并继续追查。不要询问要使用哪些来源，也不要止步于种子来源。如果 Agent 一无所获，应报告运行过的查询和空结果；这是受该查询范围限制的缺失证据。
4. 汇总里程碑。 将返回的发现合并为一份时间线。划分为带名称的阶段。为每条与问题相关的记录标注 [Qn]。
5. 解决冲突。 如果来源声明与产物不一致，应同时保留，并说明各自属于哪一类。如果两个产物不一致，应同时保留并指出差异。
6. 撰写报告。 遵循下方示例。每次运行都使用相同标题、相同顺序。
7. 记录方法。 记录每个访问边界、拒绝、结果上限和未经核实的声明。列出已访问的来源，以及本次运行中记录指向但未能访问的来源。

报告示例

每次运行都应采用以下格式。使用相同标题、相同顺序和相同条目形式。

# <Subject>: Evidence Timeline

This is a working document. Each milestone carries a slug, a link, and its supporting evidence.
Amend as new evidence arrives. Last updated YYYY-MM-DD.

Sources so far: <system>, <system>, and <system>.

## Executive summary

<The answer to every question, in prose, for a reader who reads nothing else. Sequence and
measured state. Three to six paragraphs.>

## Summary

<Narrative for a leadership audience. Every figure traces to a section below.>

<Closing paragraph naming what this summary does not assert and which figures are bounded.>

## Purpose

<N> open questions drive this timeline. Entries are tagged `[Q1]` through `[Qn]` where they bear
on one.

**Q1. <Question>?** <What the record establishes.> <What stays open.>

**Q2. <Question>?** <What the record establishes.> <What stays open.>

## Acronyms

Expansions marked **(dict)** come from a terminology registry. Expansions marked **(meta)** come
from project or space metadata. Expansions marked **(record)** are established by artifacts in
this timeline. Unverified entries say so.

| Term | Expansion | Meaning here |
| ---- | --------- | ------------ |
| <ABC> | <Expansion> (dict) | <What it refers to in this record> |
| <XYZ> | <Expansion> (record) | <What it refers to in this record> |

## Cast

| Person | Role | Established by |
| ------ | ---- | -------------- |
| <Name> | <Role> | <Artifact and link> |

## Milestones

### Phase 0: <Name>, <start> to <end>

**YYYY-MM-DD. <Headline>** `[Q1]`
[<ABC-123>](url) | [<Page title>](url)
<Evidence. Quote the source verbatim where the wording carries the claim.>

**YYYY-MM-DD HH:MM TZ. <Headline>**
[<Chat>](permalink)
<Name>: "<verbatim quote>" <What the quote establishes.>

### Phase 1: <Name>, <start> to <end>, <count> <units>

<Entries in date order.>

## <System> record

<One section per system: repo facts, issue-tracker record, runtime state, documentation record,
consumer record, cost. Sub-sections as the evidence requires.>

| <Metric> | <Value> | Source |
| -------- | ------- | ------ |
| <Metric> | <Value> | <Query or link> |

## Findings

1. <One claim, carrying the figure that supports it.>
2. <One claim, carrying the figure that supports it.>

## Open questions

1. <Question.> <What would settle it.>
2. <Question.> <What would settle it.>

## Method

<Every claim above is one of three kinds. Name them: a quoted source is a claim by its author on
that date, a system record is an artifact, a live query result is state observed on that date.
Where a claim and an artifact disagree, both appear.>

- <Query provenance: tool, host, credential, and date for each system.>
- <Result caps, and how counts were taken above the expected row count.>
- <Denials, recorded rather than worked around.>
- <Sources the record named that this run never reached.>
- <What stays unverified.>

证据规则

• 对每条声明，都引用系统、标识符和 URL。
• 来源声明不同于产物。邮件称某个问题已关闭，这是声明。问题的状态转换记录才是产物。说明某项陈述依据的是哪一种。
• 记录所有矛盾。绝不要悄然消解矛盾。
• 在每条未经核实的陈述原处标明其未经核实。
• 将被拒绝的查询记录为拒绝。不要绕过拒绝。
• 绝不输出机密值。可以比较和分类，但不要复述其值。
• 所有查询均为只读。不得执行写入、删除或重启操作。
• Agent 记忆和会话记录不属于独立证据。
• 每次统计都注明结果上限，并使用高于预期行数的上限进行统计。
• 每次统计都应限定在执行该查询的凭据范围内。

表述规则

• 描述，不要评判。“请求了什么”是一个问题。“请求是否合理”则是定论。
• 每项描述都应逐字注明其作者，否则就删掉。
• 不要用引导读者作出判断的趋同措辞来链接来源。
• 每个绝对表述都要限定在搜索范围内，并说明搜索内容。
• 明确标注标价、预测和估算的性质。
• clanker-prose 插件的代写规则同样适用。读者是人类同事。

格式

• 使用 ISO 日期。来源提供时区时，注明时区。
• 每行文字不超过 95 列。
• 表格保持紧凑：竖线内各留一个空格，分隔线的短横线长度与表头文字相当。
• 不要对交付内容运行 md-lint 或 prettier。两者都会破坏本项目的格式。