-
Notifications
You must be signed in to change notification settings - Fork 4
Changesets
Language: English · 简体中文
A changeset stages several related Wiki mutations in an isolated sparse draft, validates them against the live Wiki, and publishes them atomically. Use it when one logical update must not expose partial knowledge.
Single source, page, or tag commands are already transactional. A changeset is useful only when several commands must succeed together.
- add several Sources and integrate them into shared Pages;
- revise a Page and its strong-tag policy together;
- update Purpose, Schema, and dependent Pages as one contract change;
- publish several linked Pages without temporary broken links;
- prepare a broad replacement with one exact rollback boundary.
Do not create a changeset for a one-command write. The draft lifecycle would add review overhead without improving atomicity.
live Wiki remains readable and unchanged
+
small draft with touched entities and base fingerprints
=
overlay reads used for draft validation
changeset begin does not copy or checkpoint the full live Wiki. It creates a small sparse database bound to the live store identity and base revision. Draft reads see staged changes over the live baseline, while live SQLite and Markdown stay unchanged.
Each draft has its own database, Work directory, and graph sidecar. Work IDs and graph nodes cannot leak between drafts.
lwc --scope project changeset begin architecture-refresh
lwc --scope project --changeset architecture-refresh source add-manifest sources.json
lwc --scope project --changeset architecture-refresh ingest claim <source-id>Keep every dependent read and write under the same --changeset selector. Do not interleave direct live writes to entities the draft will touch.
Project and global changesets are separate. --scope all is invalid for mutation.
The current exact patch set supports:
- Source add;
- ingest claim, analyze, complete, fail, and retry;
- Page put and remove;
- Purpose and Schema replacement;
- tag set, remove, delete, and autoload policy;
- recorded search operations.
Other canonical mutations require an exact inverse and merge rule before they can be published safely. Unsupported actions return changeset_sparse_unsupported or a command-specific changeset_command_not_supported instead of producing a partial commit.
Deployment-local configuration, init, maintenance, checkpoints, and nested changeset commands cannot run inside a draft. Apply independently transactional unsupported mutations outside the changeset only when that separation matches the intended atomic boundary.
lwc --scope project --changeset architecture-refresh lint
lwc --scope project --changeset architecture-refresh search "expected answer" --limit 5
lwc --scope project --changeset architecture-refresh search "natural paraphrase" --limit 5
lwc --scope project changeset show architecture-refreshshow reports base and draft revisions, staged operation counts, action counts, status, and conflict metadata. It does not run lint.
Sparse lint evaluates live baseline + draft delta. A draft Page can keep a valid link to an unchanged live Page, and a tag-only draft does not need to copy the Page body, dependencies, or search index.
Validation should include:
- zero issues introduced by the draft;
- original and paraphrased retrieval returning the expected Page in the top five;
- complete citations and provenance;
- draft graph Work at
succeededandgraph verify ok=truewhen graph state is relevant.
lwc --scope project changeset commit architecture-refreshCommit:
- rejects an empty draft;
- verifies the draft's binding and integrity;
- checks fingerprints for every touched Page, meta record, tag, and Source path;
- lints the overlay;
- freezes the reviewed draft;
- creates a checksummed inverse patch for touched entities;
- applies the merge under the live write lock;
- queues live graph projection when enabled;
- removes draft state and refreshes generated Markdown.
Unrelated live writes survive. If a touched entity changed after the draft first observed it, commit returns changeset_conflict and overwrites neither side. There is no force merge.
Source identifiers allocated independently by draft and live writes are remapped during commit when paths are unrelated. Page citations, ingest state, path heads, graph documents, fingerprints, and rollback data follow that remap.
Do not use --allow-lint-issues to hide draft mistakes. It exists only for audited, pre-existing live debt that the changeset did not introduce, and it requires a reason:
lwc --scope project changeset commit architecture-refresh \
--allow-lint-issues \
--reason "Reviewed pre-existing debt; this draft introduces no new issue"Prefer repairing the issue. A reason records the exception; it does not make broken knowledge valid.
Commit freezes the reviewed draft before live publication. Later staged writes return changeset_frozen.
If a structured error says canonical commit succeeded but graph queueing, cleanup, or materialization failed, do not repeat the knowledge mutations. Run the exact recovery_command in error details. Repeating the same changeset commit <name> is idempotent and can requeue graph projection before cleanup, including recovery from older commit metadata.
lwc --scope project changeset discard architecture-refreshDiscard deletes one uncommitted draft and its isolated Work/graph runtime. It never touches live knowledge. Do not discard a failed draft until its content is no longer needed for diagnosis or recovery.
Commit returns a stable changeset_id and pre-commit checkpoint name:
lwc --scope project changeset rollback <changeset-id>
lwc --scope project work watch <graph-work-id>
lwc --scope project graph verifyRollback restores only the inverse patch's touched entities. It refuses when a later live write changed one of them, preserving that newer work. Source path heads, remapped IDs, Page citations, tags, and document-graph projection are restored consistently.
Rollback is idempotent. If canonical rollback succeeded but later materialization or graph queueing failed, repeat the same rollback command from the structured recovery details.
Repeat the same acceptance against live state:
lwc --scope project lint
lwc --scope project search "expected answer" --limit 5
lwc --scope project search "natural paraphrase" --limit 5
lwc --scope project graph verifyA clean draft is not proof that live materialization and graph projection completed.
A changeset lifecycle is complete when:
- all dependent operations used one draft selector;
- overlay lint and predeclared retrieval checks passed;
- commit returned one stable changeset ID and inverse checkpoint;
- any graph Work reached
succeededand live graph verification passed; - live retrieval repeated the draft acceptance;
- conflict or partial-success errors were handled through their typed recovery contract;
- the draft runtime was cleaned only after canonical publication or explicit discard.
Next: Work system
LWC Wiki
- Home · 首页
- Project overview · 项目简介
- Basic concepts · 基本概念
- Use cases · 应用场景
- Installation and upgrades · 安装与升级
- Quick start · 快速开始
- Persistent memory · 持久记忆体系
- Agent workflow and memory policy · Agent 工作流与主动记忆策略
- Sources and ingestion · 来源与知识整合
- Wiki pages and provenance · Wiki 页面与来源证明
- Search and context · 搜索与上下文载入
- Document knowledge graph · 文档知识图(记忆图网)
- Code graph · 代码图
- Word graph · 词图
- Tags and strong context · 标签与强上下文
- Document conversion · 文档转换
-
MCP server and
lwc_explore· MCP 服务与lwc_explore - Skills, Hooks, and Instructions · Skills、Hooks 与 Instructions
- AgentTarget installation · AgentTarget 安装与集成
- Changesets · Changeset 原子变更
- Work system · Work 任务系统
- Checkpoints and rollback · Checkpoint、恢复与回滚
- Read-only Viewer · 只读可视化界面
- Architecture overview · 总体架构
- Storage and data model · 存储与数据模型
- Retrieval and indexing · 检索与索引设计
- Graph projection and performance · 图投影与性能设计
- MCP, Hooks, and AgentTarget design · MCP、Hook 与 AgentTarget 设计
- Safety and trust boundaries · 安全模型与信任边界
- Maintenance and diagnostics · 维护与诊断
- Troubleshooting and FAQ · 故障排查与常见问题
- Migration and compatibility · 迁移与版本兼容
- Support and issue reporting · 获取帮助与问题反馈
- CLI and configuration reference · CLI 与配置参考
- JSON output and error contract · JSON 输出与错误契约
- Limits and glossary · 系统限制与术语表
- Contributing and development · 贡献与开发指南
- Testing and release process · 测试与发布流程
- Wiki style guide · Wiki 编写规范