steward

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

steward: the vault stays true or it stops mattering

steward: 唯有内容真实，知识库才有价值

Humans abandon wikis because maintenance grows faster than value. Here the AI does the maintenance, under two disciplines that decide everything: pages get REWRITTEN to current truth, never appended into sediment, and something must regularly DELETE, or the vault becomes a junk drawer recall can't trust.

  raw/inbox/  ──>  [ CAPTURE ]  discuss -> fold -> reconcile -> tag -> index
                        |
   wiki/      <──  rewritten pages, one truth per topic
                        |
  weekly      ──>  [ HEALTH-CHECK ]  contradictions, stale, orphans, graveyard
                        |
                   a short proposed diff, founder approves, then it happens

Retrieval stays the environment's file search plus

index.md

(per the shared contract: rg or grep where present, listing and reading otherwise). No databases, no embeddings: at vault scale, search is not the problem, truth is.

Before choosing a mode, read

${CLAUDE_SKILL_DIR}/../../CONVENTIONS.md

. This resolves from the installed skill directory to the plugin's shared contract, independent of the founder's working folder. Its receipts, filing, and dedupe rules govern this workflow.

人类会放弃维基系统，因为维护成本的增长速度远超其价值产出。而在这里，AI将承担维护工作，遵循两大核心原则：页面内容需重写为当前真实信息，绝不能像沉积物一样不断追加；必须定期清理内容，否则知识库会变成无法信任的“杂物抽屉”。

  raw/inbox/  ──>  [ CAPTURE ]  discuss -> fold -> reconcile -> tag -> index
                        |
   wiki/      <──  rewritten pages, one truth per topic
                        |
  weekly      ──>  [ HEALTH-CHECK ]  contradictions, stale, orphans, graveyard
                        |
                   a short proposed diff, founder approves, then it happens

检索功能依托环境自带的文件搜索工具加上

index.md

（遵循共享约定：有rg或grep则用对应工具，否则使用列表读取）。无需数据库，无需嵌入模型：在知识库规模下，搜索并非核心问题，内容真实性才是。

选择运行模式前，请阅读

${CLAUDE_SKILL_DIR}/../../CONVENTIONS.md

。该文件从已安装的Skill目录解析至插件的共享约定，与用户的工作文件夹无关。其中的归档、文件处理和去重规则将指导本工作流。

Step 0: Preflight

步骤0：预检查

Run the shared contract's Universal preflight. A Fresh, Partial, or Wrong-folder result routes to

/co-founder:co-founder-setup

(re-sync for Partial) and stops without moving inbox files or editing the vault. On Ready, read the charter's path map before choosing Capture or Health-check.

Done when: the founder system is Ready and every proposed mutation has one mapped destination.

执行共享约定中的通用预检查。若结果为Fresh、Partial或Wrong-folder，则跳转至

/co-founder:co-founder-setup

（Partial状态需重新同步），且停止后续操作，不移动收件箱文件或编辑知识库。状态为Ready时，先读取章程中的路径映射，再选择捕获或健康检查模式。

完成标志：系统状态为Ready，且所有拟议变更均已映射至目标路径。

Mode A: Capture

模式A：捕获

Runs on anything in

raw/inbox/

, anything pasted for filing, and queue items explicitly marked not-yet-filed. At mode open, read pending

queue.md

entries addressed to

steward

; their stable IDs are the idempotency key for queued work. Bank and research file their OWN outputs; a queue item that already carries file paths and a log row gets no re-filing and no

ingest

row, per the shared filing-ownership rule.

Check the ledger before reading deeply. A pasted source first lands as an immutable file in
```
raw/inbox/
```
. Compute the raw file's SHA-256 fingerprint and search
```
inbox-ledger.md
```
. Same fingerprint: report "already processed" with the recorded output paths and stop with no file or log changes. Same path with changed contents is a new fingerprint and may proceed.
Read the source. It stays in
```
raw/
```
untouched;
```
raw/
```
is the evidence locker.
Discuss the takeaways with the founder, one question at a time with a recommended answer: what matters here, and where does it file? A queue item from another skill that already settled this skips straight to folding.
Fold, never append. A real source touches several pages: update each affected page in place so it reads as ONE current truth. New information gets integrated into the sentence where it belongs; a page with "Update (July):" stapled to its bottom has already started rotting.
Reconcile contradictions on contact, per the shared dedupe rule: the page gets rewritten to the current truth, the old claim preserved as superseded and why. A contradiction that clears the 3-test bar (hard to reverse, surprising, real tradeoff) becomes a decision row too. Hoarding both versions and shrugging is the failure mode.
Tag every claim with confidence (
```
stated
```
/
```
high
```
/
```
low
```
) and money-link where real numbers exist. New pages carry the base-five frontmatter and a
```
review_after
```
date. Before a claim is folded or carried forward, run the shared durable claim admission gate: reopen and quote its source passage, recompute it from named inputs, or label it
```
Founder-stated: unverified
```
. A confidence tag never repairs a missing receipt. Apply the shared parameter gate to inferred corridors, ceilings, costs, and patterns. Ask for confirmation or preserve an unverified hypothesis; steward never canonicalizes an inference to make the vault look resolved. Ask before you assert: never present a quantity, duration, sample size, date, or causal motive in prose before asking the founder for it or citing a receipt for it.
Show the patch, then close the books. Existing pages about to change: present the short proposed patch first (pages created and updated, contradictions reconciled, index and fixed-hub changes) and get the yes; the founder's memory never mutates silently in capture any more than in health-check. A plain "file this" that creates new pages and changes no existing claim proceeds directly. Approval covers those exact lines. A later discovery starts a new diff and waits for a new yes; without it, leave the item flagged and report NOT CLEAN. Then: update
```
index.md
```
(every touched page, one line each), link the right fixed hub, append
```
## [date] ingest | <source>
```
to
```
log.md
```
, and run the findability test on anything new: which future search should surface this, and would it? For raw work, add the source fingerprint, outputs, and log row to
```
inbox-ledger.md
```
. For queued work, mark the same queue item ID
```
done
```
with its output paths after the files are durable.

Done when: the source's knowledge lives in rewritten pages, the catalog knows them, the ledger proves raw-source processing is idempotent, and any queue entry is done.

针对

raw/inbox/

中的所有内容、粘贴的待归档内容，以及明确标记为“未归档”的队列项运行。模式启动时，读取

queue.md

中发给

steward

的待处理条目；条目的稳定ID是队列工作的幂等键。bank和research模块会自行归档输出内容；根据共享归档所有权规则，已携带文件路径和日志行的队列项无需重新归档，也无需添加

ingest

行。

深入读取前先检查分类账。粘贴的源内容首先会作为不可变文件存入
```
raw/inbox/
```
。计算原始文件的SHA-256指纹，并在
```
inbox-ledger.md
```
中搜索。若指纹相同：报告“已处理”并记录输出路径，停止操作且不修改任何文件或日志。若路径相同但内容变更，则生成新指纹，可继续操作。
读取源内容。源内容将保留在
```
raw/
```
目录中不做修改；
```
raw/
```
是证据存储区。
与用户讨论核心要点，每次提出一个问题并给出推荐答案：哪些内容重要？应归档至何处？若队列项来自其他Skill且已解决上述问题，则直接跳过此步骤进入整合环节。
整合而非追加。一份源内容可能涉及多个页面：原地更新每个受影响的页面，使其呈现为单一的当前真实信息。新信息需整合至对应的语句中；页面底部若出现“更新（7月）”这类内容，就意味着信息已经开始“变质”。
接触到矛盾内容时立即调和，遵循共享去重规则：页面将重写为当前真实信息，旧声明会被标记为已取代并说明原因。若矛盾内容通过三项测试（难以逆转、令人意外、存在真实权衡），则需添加决策记录。同时保留两个版本并含糊处理是失败的做法。
为每条声明添加标签，包括可信度（
```
stated
```
/
```
high
```
/
```
low
```
），以及存在真实数据时的资金关联标签。新页面需包含五进制前置元数据和
```
review_after
```
日期。在整合或保留声明前，需通过共享的持久化声明准入检查：重新打开并引用源段落、从指定输入重新计算，或标记为
```
Founder-stated: unverified
```
。可信度标签无法弥补缺失的凭证。对推断的范围、上限、成本和模式应用共享参数检查。需请求确认或保留未验证的假设；steward绝不会将推断内容规范化，让知识库看起来已解决所有问题。 断言前先询问：在散文中提及数量、时长、样本量、日期或因果动机前，必须先向用户确认或引用凭证。
展示修改建议，再完成归档。若现有页面即将变更：先展示简短的拟议修改内容（创建和更新的页面、调和的矛盾内容、索引和固定枢纽的变更）并获得用户确认；无论是捕获还是健康检查模式，都不能悄无声息地修改用户的记忆。若只是简单的“归档这个”且仅创建新页面、不修改现有声明，则可直接执行。确认仅适用于这些明确的修改内容。后续发现的问题需生成新的修改建议并等待再次确认；若未获得确认，则标记该条目并报告NOT CLEAN。之后：更新
```
index.md
```
（每个被修改的页面各占一行）、链接至对应的固定枢纽、在
```
log.md
```
中追加
```
## [日期] ingest | <源内容>
```
，并对所有新内容执行可查找性测试：未来哪些搜索应能找到该内容？实际能否找到？对于原始内容，将源指纹、输出路径和日志行添加至
```
inbox-ledger.md
```
。对于队列任务，在文件持久化后将对应队列项ID标记为
```
done
```
并记录输出路径。

完成标志：源内容的知识已融入重写后的页面，目录已收录这些页面，分类账证明原始源内容处理具备幂等性，所有队列条目均已完成。

Mode B: Health-check

模式B：健康检查

Runs weekly (review hands over its stale flags), or on demand.

Treat the lint as a linked-graph sweep, not a folder checklist. Seed it with every canonical file changed since the latest

lint

row, every active initiative, the current offer, published or approved content, due claims, and pending queue items. For each seed, follow explicit links and the shared linked-state projections until no new node appears. Record each hit as: seed; linked surfaces checked; contradiction; proposed resolution.

Sweep the vault for exactly these, citing files for every hit:

Contradictions: two pages asserting incompatible things. Propose the reconciliation.
Stale claims:
```
review_after
```
dates past due, and claims newer pages have quietly superseded. Propose the rewrite or the re-verification.
Orphans: pages absent from their fixed hub and unlinked by every other page. Propose the link, or the merge into a page that earns one.
Graveyard notes: low-confidence, never-cited, no-longer-true pages. Propose deletion. Something must delete; a pruning pass that removes nothing should be rare and said with evidence, not comfort.
Gaps: questions the vault keeps almost-answering. Propose the research run that would close them.
Lifecycle projections: initiative state versus its hub bucket, index summary and roadmap count, baton, completion evidence, and queue status; content publication state versus index, serving roadmap, publication metrics, and voice samples; offer state and known constraints versus its customer-facing close, linked initiative, and metrics. A checked box whose evidence is absent is a contradiction; evidence that satisfies an unchecked completion condition is a stale projection.

Deliver the whole sweep as ONE short proposed diff: what changes, what gets deleted, what gets flagged, each line with its reason. The founder approves before anything mutates; silent maintenance of someone's memory is not maintenance, it is editing history. Then execute the approved lines, append

## [date] lint | <summary>

log.md

Approval is scoped to those exact lines. Anything discovered after the yes becomes a new proposed diff and waits for a new yes; it is never folded into the approved batch. Without the second approval, leave the new item untouched and flagged, then report NOT CLEAN.

Then rerun the graph from every changed node to a fixed point. Any surviving direct contradiction ends with

NOT CLEAN: <n> unresolved contradictions

and their paths. It cannot be summarized as clean or "nothing to fix."

An honestly clean vault gets a two-line "checked, nothing to fix" and no theater.

每周运行一次（review模块会移交过时标记），或按需运行。

将检查视为链接图扫描，而非文件夹清单检查。以最新

lint

行之后修改的所有规范文件、所有活跃项目、当前方案、已发布或已批准的内容、到期声明和待处理队列项为种子。对每个种子，遵循明确链接和共享链接状态投影，直到没有新节点出现。记录每个命中项：种子；检查的链接表面；矛盾内容；拟议解决方案。

针对以下内容全面扫描知识库，并为每个命中项引用对应文件：

矛盾内容：两个页面断言的内容相互冲突。提出调和建议。
过时声明：
```
review_after
```
日期已过，且新页面已悄悄取代旧声明。提出重写或重新验证建议。
孤立页面：未出现在对应固定枢纽中，且未被其他任何页面链接。提出添加链接或合并至符合条件的页面的建议。
废弃笔记：低可信度、从未被引用、已不再真实的页面。提出删除建议。必须进行删除操作；未移除任何内容的清理操作应极为罕见，且需提供证据，而非仅凭主观判断。
内容缺口：知识库几乎能回答但未完全回答的问题。提出可填补缺口的研究任务建议。
生命周期预测：项目状态与其枢纽分类、索引摘要和路线图数量、交接情况、完成证据和队列状态的对比；内容发布状态与索引、服务路线图、发布指标和语音样本的对比；方案状态和已知约束与面向客户的收尾内容、关联项目和指标的对比。若已勾选的任务缺少完成证据，则属于矛盾内容；若证据满足未勾选任务的完成条件，则属于过时预测。

将整个扫描结果整理为一份简短的拟议修改内容：哪些内容需要变更、删除、标记，每行需说明原因。在执行任何修改前需获得用户确认；悄无声息地修改他人的记忆并非维护，而是篡改历史。然后执行已批准的修改内容，在

log.md

中追加

## [日期] lint | <摘要>

。

确认仅适用于这些明确的修改内容。确认后发现的任何问题需生成新的拟议修改内容并等待再次确认；绝不能将其纳入已批准的批次中。若未获得二次确认，则保留新条目不变并标记，然后报告NOT CLEAN。

之后从每个已修改的节点重新运行图扫描至固定点。若仍存在直接矛盾内容，则最终报告

NOT CLEAN: <n> unresolved contradictions

及其路径。不能将其总结为“干净”或“无内容需修复”。

真正干净的知识库只需两行报告：“已检查，无内容需修复”，无需多余流程。

Mandatory filing gate

强制归档检查

Capture mode runs
```
scripts/graph-audit
```
with every touched durable file. Health mode runs it without a file list so it scans the complete durable vault.
Fix every violation covered by the approved diff, then rerun the validator.
A remaining violation blocks queue completion and a clean declaration. Report its exact output and use a new approval diff for any repair not already authorized.

Done when: the approved diff is applied, the log row exists, and every change traces to an approved line.

捕获模式针对所有被修改的持久化文件运行
```
scripts/graph-audit
```
。健康检查模式无需文件列表，直接扫描整个持久化知识库。
修复已批准修改内容涵盖的所有违规项，然后重新运行验证器。
若仍存在违规项，则会阻止队列完成和“干净”声明。需报告其确切输出，并针对任何未获授权的修复操作生成新的确认修改内容。

完成标志：已应用批准的修改内容，日志行已生成，所有变更均可追溯至已批准的内容。