Restoring a Version

Restoring brings a Context knowledge workspace back to a saved state in Git: its files and the sources they need. It does not reset the whole repository, rewind source repositories, or bring back ignored runtime progress. An explicit restore request needs no second approval when the target and the affected files are clear.

mermaid

flowchart LR
  target["Resolve the target<br/>commit SHA and path scope"] --> clear["End unfinished work"]
  clear --> files["Restore agreed paths"]
  files --> src["Restore pinned sources"]
  src --> check["Verify and stop"]

1. Resolve the target

The Agent inspects Git history for the workspace path and turns your request into a concrete commit SHA and path scope:

You say	Target
Nothing specific	The latest commit that saved the workspace — this undoes uncommitted results
"The previous version"	The preceding saved state of the workspace, not simply `HEAD~1` of a large repository
A SHA	That SHA, after validation
A date	Interpreted in your timezone and meaning (for example, as of the end of that day); ambiguous candidates are confirmed with you

It then compares the target with current tracked, untracked and staged files. Files added since the target are proposed for removal; unrelated files, existing staged work and ignored source checkouts are kept. Moves and renames are accounted for.

2. Restore files and sources

Wait for any running Context writer, then abandon unfinished work with the task-state preview and apply described in Preparing a Workspace. Old Routes are not reused afterwards.
Restore only the agreed paths, preserving branch history:
bash
```
git restore --source=<sha> --worktree -- <paths>
```
Files added since the target are deleted explicitly. reset --hard and clean -fdx are never used as a shortcut.
Use the restored source records to restore pinned repository versions, module paths, document snapshots and attachments. Newer remote content cannot stand in for a lost old snapshot, and usable sources are not recloned.

Old build output does not describe the restored version. If you want output, the Agent runs the current close and build; until then it reports existing output as stale. It does not start full indexing just because the old configuration is back, and if the historical format is incompatible it reports the migration or tool-version choice instead of rewriting pages silently.

3. Verify and stop

The Agent compares the restored files with the target commit, confirms unrelated changes and index entries survived, and checks that sources are ready and no old task state remains. If only some sources could be restored, it reports partial completion with the missing access or version. Nothing is committed, rewritten or pushed automatically; commit the result separately with Committing Results.

恢复版本

恢复会把 Context 知识工作区带回 Git 中保存过的某个状态：包括它的文件和这些文件所需的来源。它不会重置整个仓库、回退来源仓库，也不会找回被忽略的运行时进度。当目标和受影响的文件都明确时，明确的恢复请求无需二次批准。

mermaid

flowchart LR
  target["确定目标<br/>提交 SHA 和路径范围"] --> clear["结束未完成的工作"]
  clear --> files["恢复约定的路径"]
  files --> src["恢复固定版本的来源"]
  src --> check["验证并停止"]

1. 确定目标

Agent 查看知识工作区路径的 Git 历史，把你的请求转换为具体的提交 SHA 和路径范围：

你说	目标
没有具体说明	最近一次保存知识工作区的提交——这会撤销未提交的结果
“上一个版本”	知识工作区上一个保存过的状态，而不只是大仓库的 `HEAD~1`
一个 SHA	校验通过后的该 SHA
一个日期	按你的时区和含义解释（例如截至当天结束）；有歧义的候选会与你确认

随后它将目标与当前已跟踪、未跟踪和已暂存的文件进行比较。目标之后新增的文件会被建议删除；无关文件、已有的暂存工作和被忽略的来源检出都会保留。移动和重命名也会被考虑在内。

2. 恢复文件和来源

等待任何正在运行的 Context 写入进程结束，然后用准备知识工作区中描述的任务状态预览和应用来放弃未完成的工作。之后不会复用旧的 Route。
只恢复约定的路径，保留分支历史：
bash
```
git restore --source=<sha> --worktree -- <paths>
```
目标之后新增的文件会被显式删除。绝不会用 reset --hard 和 clean -fdx 走捷径。
用恢复后的来源记录恢复固定的仓库版本、模块路径、文档快照和附件。更新的远程内容不能替代丢失的旧快照，可用的来源也不会被重新克隆。

旧的构建产出并不对应恢复后的版本。如果你需要产出，Agent 会运行当前的 close 和构建；在此之前，它会把现有产出报告为已过期。它不会仅仅因为旧配置回来了就启动全量索引；如果历史格式不兼容，它会报告需要在迁移和工具版本之间做出的选择，而不是悄悄重写页面。

3. 验证并停止

Agent 将恢复后的文件与目标提交进行比较，确认无关的变更和索引条目都完好保留，并检查来源已就绪、没有残留旧的任务状态。如果只有部分来源能够恢复，它会报告部分完成，并说明缺少的访问权限或版本。不会自动提交、重写或推送任何内容；请另行使用提交结果提交结果。

Restoring a Version ​

1. Resolve the target ​

2. Restore files and sources ​

3. Verify and stop ​

恢复版本 ​

1. 确定目标 ​

2. 恢复文件和来源 ​

3. 验证并停止 ​