Updating Knowledge

Every approved page records which source version it was written from. When a repository moves on or a document is edited, an update compares the new version with that baseline, revises only the affected pages and then moves the baseline forward. Unaffected pages are left alone.

flowchart LR
  ask["You name the scope<br/>and target version"] --> acq["Agent acquires the<br/>fixed new version"]
  acq --> upd["context update<br/>conservative page match"]
  upd --> decide["Agent reads the change<br/>keep / revise / add"]
  decide --> rev["Changed pages<br/>Knowledge Review"]
  rev --> build["Close and build"]
  build --> base["Baseline advances"]

Ask for the update

Name the scope — a whole repository, some modules or specific documents — and, when it matters, the version:

billing-service has moved to the release-2.4 merge. Locate the affected knowledge
and update it. Only the invoicing and refunds modules.

For a single page whose text is wrong, a revision is the better tool. The Agent also tells you when other work is still unfinished in the Context knowledge workspace and asks whether to finish or roll it back before starting an independent update.

How the new version is chosen

Context does not poll platforms or discover remote changes; the Agent uses its own Git and document tools once, for the scope you named.

• For a branch or merge request, it establishes the target branch, merge state and the actual commit on that branch. An unmerged proposal is not the mainline, and a squash or rebase can produce a different commit than the feature branch.
• Intervening commits that touch the registered modules are included; reverts are real changes.
• A new commit with unchanged module trees can conclude "no knowledge change".
• If the old baseline is unavailable after a force push or history cleanup, the Agent says so and compares the current material with approved knowledge instead.
• For documents, a read failure, a deletion and a move are reported differently; none of them is a reason to retire a page.

The update request

scopes:
  - requirement_ref: reader-guide
    source_ref: repo:20261012/billing-service
changes: The selected change adds one public option; inspect its explanation and examples.

The Agent submits this with context update --input <file>. Omitting module references selects the whole confirmed source. The returned candidate list is a conservative match of pages citing the changed material, not a list of pages that must change: the Agent reads the change and the current pages, keeps what is still right, revises what changed and proposes pages for genuinely new topics, which go through structure review first.

Review and the baseline

Changed pages appear in the review report with their changed blocks next to the previous text. The processed baseline advances only after every selected revision is approved, closed and built — or after an explicit conclusion that nothing needs to change. It does not move on acquisition or after the first approved page, so an interrupted update can resume without losing track of what remains.

Only the sources the update needs

Unrelated repositories do not need to be checked out for an update. A note, a document-only change, a wording fix or a navigation change needs no code at all. When required code is missing, the Agent restores only that repository at its pinned commit; see Code Repositories.

更新知识

每个已批准页面都会记录其写作时依据的来源版本。当仓库有了新提交或文档被编辑后，更新会将新版本与该基线对比，只修订受影响的页面，然后推进基线。不受影响的页面保持不变。

flowchart LR
  ask["你指定范围<br/>和目标版本"] --> acq["Agent 获取<br/>固定的新版本"]
  acq --> upd["context update<br/>保守的页面匹配"]
  upd --> decide["Agent 阅读变更<br/>保留 / 修订 / 新增"]
  decide --> rev["变更的页面<br/>知识审核"]
  rev --> build["关闭并构建"]
  build --> base["基线推进"]

发起更新

指定范围——整个仓库、部分模块或特定文档——必要时再说明版本：

billing-service has moved to the release-2.4 merge. Locate the affected knowledge
and update it. Only the invoicing and refunds modules.

如果只是单个页面的文本有误，更适合用修订。如果 Context 知识工作区中还有其他未完成的工作，Agent 也会告诉你，并在开始一次独立的更新之前询问是先完成还是回滚。

如何选定新版本

Context 不会轮询平台，也不会自动发现远端变化；Agent 只会针对你指定的范围，使用它自己的 Git 和文档工具获取一次。

• 对于分支或合并请求，Agent 会确认目标分支、合并状态，以及该分支上的实际提交。未合并的提议不属于主线，而 squash 或 rebase 可能产生与特性分支不同的提交。
• 中间涉及已登记模块的提交都会纳入；revert 也是真实的变更。
• 如果新提交下的模块目录树没有变化，可以得出“知识无需变更”的结论。
• 如果在 force push 或历史清理之后旧基线已不可用，Agent 会说明这一点，并改为将当前材料与已批准的知识进行对比。
• 对于文档，读取失败、删除和移动会分别报告；这些都不能作为下线页面的理由。

更新请求

scopes:
  - requirement_ref: reader-guide
    source_ref: repo:20261012/billing-service
changes: The selected change adds one public option; inspect its explanation and examples.

Agent 通过 context update --input <file> 提交该请求。省略模块引用时，会选中整个已确认的来源。返回的候选列表是对引用了变更材料的页面所做的保守匹配，而不是必须修改的页面清单：Agent 会阅读变更和当前页面，保留仍然正确的内容，修订发生变化的部分，并为真正的新主题提议新页面，这些新页面会先经过结构审核。

审核与基线

变更的页面会出现在审核报告中，变更的区块与之前的文本并排展示。只有当每个选中的修订都已批准、关闭并构建——或明确得出无需变更的结论之后，已处理的基线才会推进。获取新版本时或第一个页面获批后，基线都不会移动，因此中断的更新可以恢复执行，而不会丢失剩余工作的进度。

只需要更新所用的来源

更新时无需检出不相关的仓库。笔记、仅涉及文档的变更、措辞修正或导航变更完全不需要代码。当所需代码缺失时，Agent 只会在固定的提交上恢复那一个仓库；参见代码仓库。