memdsl

memdsl

English | 中文

English

将 Agent 记忆作为 Agent 自行读取的源代码。

带有实验性 Edge 的 0.9 发布线

0.9.0 版本新增了可选择启用的 memdsl.workspace.v3 一等显式 Edge 实验。它不会改写冻结的 0.8 契约：旧版关系和权限保持兼容，显式 Edge 提案始终需要人工审核，而显式 supersedes 仅用于图谱。源文件仍是运行时权限的依据；审核/审计是工作流契约，而非不可绕过的授权记录账本。请参阅第 6 阶段设计与风险矩阵和发布范围证据冻结。

稳定的 0.8 兼容性契约

0.8 契约结合了此前未发布、现已随 0.9.0 提供的导航和 View 功能；0.7.0 和 0.8.0 均未单独发布。稳定的公共契约包括 v1 兼容性/权限接口、Catalog v1、Trace v1、带索引的查询/搜索跟踪、报告诊断、公共可重建的 CompiledWorkspace / compile_workspace、memdsl.workspace.v2、精确的 use、通用的 dialect_mapping 能力、ViewContext/ResolvedView，以及显式选择启用的 v2 读取模式。Map v1 在整个 0.8 发布线上仍受支持，且在 1.0 之前不会重新考虑是否移除。

软件版本为 0.9.2，对应标签 v0.9.2。该版本为默认只读的 memdsl-mcp 服务新增了官方 MCP Registry 元数据，以及基于 UV 的 MCPB 安装程序。解析器、模式、审核、查询、权限和 MCP 工具契约均与 0.9.1 保持一致。此补丁版本和软件包级别的发布均不会将可选启用的 Edge 接口提升为稳定版，也不会让自动 Edge 生成具备权限。

quarantine/strict、方言候选学习以及由宿主证明的主体集成，在真实场景中的部署质量仍处于实验阶段，且均为可选功能。其安全不变量并非实验性的：授权发生在聚合之前，不完整的硬规则评估绝不会得出 ALLOW，非权威边不会获得权限，修复途径始终开放。CompiledWorkspace 是公共的可重建句柄；其缓存/索引布局、编译器契约字符串和合成计时常量仍属于实现细节。Workspace-v3 的一等 Edge 处于实验阶段。当前未提供自动方言学习、自动 Edge 候选、推断权限以及冷历史/增量编译。宿主提取/净化以及私有模式/策略/示例均不属于 memdsl 范畴，也不是发布门槛。

memdsl 源于一次检索失败。一个基于 RAG 构建的记忆系统未能检索到它明明存有的记忆；而一个指向同一批原始记忆文件的编码 Agent，只用几步就找到了问题所在。模型相同，差异在于上下文契约。Agent 知道记忆存在，并能继续读取来找到它；检索器却只能给出一次相似度猜测，猜错时看起来就和记忆不存在一样。

memdsl 将这种差异变成了产品。长期记忆保存在易读、可执行 lint 检查、可审核的 .mem 源文件中，每个运行时接口都围绕自行读取记忆的 Agent 构建：

• 有界记忆目录（memdsl catalog、MCP memory_catalog / memdsl://catalog、Python build_memory_catalog）：按页浏览模块/类型/主题/ 状态，设有条目数和字节数预算，游标绑定修订版本，且不会重复提供结构化/文本表示。对于大型工作区，推荐在会话开始时使用此入口。
• 兼容的记忆映射（memdsl map、MCP memory_map / memdsl://map）：现有的 v1 完整索引仍可供旧版客户端使用，不会被悄然改成目录。
• 能说明未命中原因的索引查询（每个序列化包中的 search_trace）：确定性词法倒排表保留 v1 EvidencePack 的排序和权威性层级，同时公开 View/来源身份、候选池计数、被筛选条件隐藏的匹配项、有界词汇建议以及安全的重试查询。建议不会写入别名，也不会让候选符号重定向检索。
• 有界关系追踪（memdsl trace、MCP memory_trace、Python trace_memory）：确定性地按入向/出向/双向进行 BFS 导航，支持关系筛选，显式标记循环/回溯/跨边，设置严格的深度/节点/边/字节预算，游标绑定修订版本。连通性用于导航，不构成证明。
• 仅报告的链接诊断（memdsl lint、MCP memory_lint 和 memdsl://status）：明确列出重复 ID、目标不明确/前缀错误/悬空、未知关系、修订循环和 supersede 分叉。循环边不会导致所有参与项消失，分叉永不择定赢家，默认 Map/查询权威性与 v1 保持兼容。
• 原始来源是基础（memdsl://file/{file_id}）：Agent 始终可以进一步读取实际声明，就像编码 Agent 读取代码一样。

最初促使本项目诞生的故障模式，如今会明确报错——记忆确实存在，只是被筛选条件隐藏了，而追踪会准确说明这一点：

$ memdsl query examples/domains/coding -q "force push main" \
    --type coding.bug_pattern --json
  "missing": [
    "no active declarations matched query terms: ['force', 'push', 'main']",
    "1 active declaration(s) matched the query but were excluded by type/subject filters"
  ],
  "search_trace": {
    "excluded_by_filters": [
      {"id": "coding.project_rule:git.no_force_push", ...}
    ], ...
  }

$ memdsl query examples/domains/coding -q "force push main"
MUST
- [coding.project_rule:git.no_force_push] Never force-push the main branch. (exceptions: []) [status=active; runtime_role=constraint; lifecycle={"status":"active"}]

两分钟内用 Claude Code 试用

核心库和 CLI 支持 Python 3.9+。MCP 附加组件和 memdsl-mcp 服务要求 Python 3.10+，因为上游 MCP SDK 有此要求。

# Python 3.10+
pip install "memdsl[mcp]"
claude mcp add memdsl -- memdsl-mcp --workspace ~/memory   # or an examples/ dir

该服务会指示 Agent 首先读取 memory_catalog，后续操作只能使用绑定到相同 Source/View 和筛选条件的游标；将 no_match 视为重试信号；仅将 memory_trace 用于有界的显式关系导航；并使用 memory_check，依据 MUST 约束预检影响重大的草稿。旧版 memory_map 仍已注册，供兼容客户端使用。

DeepSeek Harness

DeepSeek Harness 可以通过其官方 MCP 客户端挂载相同的 stdio MCP 服务。推荐的覆盖配置仅授予 read:summary,read:search，因此模型可以编目、查询、追踪、解释并检查已批准的来源记忆，但无法创建提案。请参阅 DeepSeek Harness 集成指南中的已测试覆盖配置和验证步骤。

受治理的类型化记忆

第二大支柱：让记忆可以像代码一样审查，而不强迫所有用户采用某位作者的本体。0.8 版保留了 0.5 版引入的双层类型架构和 0.6 版的生命周期安全审查契约，并新增有界编译导航和显式 workspace-v2 Views：

core memory record     claim / evidence / scope / confidence / lifecycle /
                       access policy / relations

domain type system     coding.project_rule / assistant.commitment /
                       writing.voice_preference / your own memory types

核心负责稳定的行为契约，工作区拥有自己的词汇表。编码 Agent、个人助手和写作系统不应仅仅因为 memdsl 的作者选择了这些词，就都必须把同一概念称为 preference、boundary 或 fact。

两层结构

核心层提供通用字段和五种稳定的运行时角色：

运行时角色	EvidencePack 行为
symbol	定义可供其他记忆引用的主体
constraint	生效的声明会显示在 MUST 中，并参与合规性检查
guidance	生效的声明会显示在 SHOULD 中
assertion	相关的生效声明会显示在 CONTEXT 中
question	生效的声明会显示在 MISSING 中，而不是作为事实

所有可搜索的非生效命中项都会隔离在 PROVISIONAL 下，与运行时角色无关。候选 symbol 不能重定向查询，候选约束也不能进入 MUST 或合规性检查。

同一权威边界也适用于关系。只有当 supersedes 关系的源处于生效状态，且其完整 ID 或唯一的裸目标能够准确解析时，才能隐藏目标。候选、已撤回、已归档、有歧义、重复或前缀错误的 superseder 都不能改变查询、MUST 或合规性检查。这是 0.8 保留的 v1 兼容性权威规则。选择启用的 ResolvedView 路径使用相同的故障安全基础，并且仅增加显式的 v2 隔离机制。

核心还支持诸如 requires_evidence、searchable、temporal、enforceable、guardable、exceptions_recommended 等能力，以及显式的审核选择加入项 auto_approvable。

领域层定义有意义的记忆类型，并将每种类型编译为一个运行时角色。随附示例包括：

• 编码：coding.project_rule、coding.bug_pattern、coding.tool_preference
• 个人助手：assistant.routine、assistant.commitment、 assistant.relationship_context
• 写作：writing.voice_preference、writing.taboo_topic、 writing.style_example

内置的 memdsl.standard@1 包可让现有的 entity、fact、 preference、boundary、principle、decision、state 和 open_issue 工作区继续运行。这些名称是兼容性默认值，而非人类记忆的通用本体。

定义领域词汇表

工作区通过 memdsl.json 选择启用架构：

{
  "schema_version": "memdsl.workspace.v1",
  "schemas": ["coding.memschema.json"]
}

架构定义领域类型、字段、角色和能力：

{
  "name": "coding",
  "version": "1",
  "types": {
    "project_rule": {
      "runtime_role": "constraint",
      "required_fields": ["claim", "evidence", "scope"],
      "optional_fields": ["rationale", "owner"],
      "search_fields": ["rationale", "owner"],
      "capabilities": [
        "requires_evidence",
        "searchable",
        "enforceable",
        "guardable",
        "exceptions_recommended"
      ],
      "defaults": {"force": "hard", "status": "active"},
      "allowed_forces": ["hard"],
      "allow_extra_fields": false
    }
  }
}

project_rule 会成为命名空间类型 coding.project_rule：

module coding.memory

entity Repository.Memdsl {
  canonical_name: "memdsl"
  status: active
}

coding.project_rule git.no_force_push {
  subject: Repository.Memdsl
  claim: "Never force-push the main branch."
  scope: repository("memdsl")
  confidence: high
  exceptions: []
  rationale: "Published history must remain auditable."
  guard {
    when_any: ["push", "git", "main"]
    deny_any: ["force-push", "--force", "--force-with-lease"]
  }
  lifecycle { status: active }
  access_policy {
    readers: [developer, coding_agent]
    writers: [maintainer]
    reviewers: [maintainer]
    export: internal
  }
  evidence {
    source: AGENTS.md
    quote: "Do not force-push unless the user explicitly asks."
  }
}

严格架构会拒绝未声明的字段。未知记忆类型会在 lint 检查中报错 unknown_memory_type，不会悄然获得临时行为。

精确导入与工作区自有方言

现有工作区保持兼容：没有清单且使用 memdsl.workspace.v1 时，会保留旧版全局链接。工作区可以通过 v2 显式审核或强制执行导入：

{
  "schema_version": "memdsl.workspace.v2",
  "schemas": ["workspace-dialect.memschema.json"],
  "linking": {"visibility": "report"}
}

整个工作区建立索引后才会解析 use X，因此声明顺序无关紧要。X 是一个精确模块或一个精确的生效 symbol 名称。不支持通配符、前缀、别名，也没有模块优先于 symbol 的规则。报告模式会保留旧版链接并生成迁移诊断；严格模式会移除未导入关系、主体路由和方言路由的效果。不会为 v1 工作区推断出严格模式。

方言仍由 Source 所属的工作区管理。架构类型通过通用 dialect_mapping 能力选择加入；虚构的可运行示例位于 examples/dialect/。只有生效、公开、有效且无歧义的正向映射才会进行路由。候选、待处理、私有、有歧义和负向映射均不会进行路由。未匹配时可以返回 search_trace.dialect_candidate 模板，但不会写入任何内容：仍需提供证据、提交提案、审核、批准并重新编译。

选择启用隔离区强制执行

Workspace v2 可以单独启用 v2 读取门控：

{
  "schema_version": "memdsl.workspace.v2",
  "schemas": ["workspace-dialect.memschema.json"],
  "linking": {"visibility": "report"},
  "enforcement": {"mode": "quarantine"}
}

省略 enforcement 或选择 report，都会保留 v1 读取行为。 quarantine 和 strict 是显式选择启用的模式；它们会将 Source 分类为权威、暂定、隔离或排除，并使用新的 v2 query/list/explain/check/Catalog/Trace 信封。空结果会区分 no_match、quarantined、unauthorized、compiler_error 和预算限制。 身份关键错误会以关闭方式失败，而关系/使用/方言/类型错误则会在最小安全的声明、文件或修订族范围内隔离。Lint、源代码编辑、提案、审查和审计仍可用于修复。

Map 仍是 v1 兼容层，并会在显式强制执行时返回 unsupported_view。请改用 Catalog、query、list、explain 或 Trace。 待处理的提案仍不会进入持久化 View，候选/私有/有歧义的方言映射也绝不会通过隔离获得路由权限。

安装和检查

基础软件包支持 Python 3.9+：

pip install memdsl                 # or: pip install -e . from a checkout
memdsl --version
memdsl types examples/domains/coding
memdsl lint examples/domains/coding --json
memdsl catalog examples/domains/coding --json
memdsl map examples/domains/coding
memdsl query examples/domains/coding -q "force push main"
memdsl trace examples/alex decision:aurora.pricing_free_tier --both --depth 2 --json
memdsl check examples/domains/coding \
  -t "push main" \
  -c "git push --force origin main"

memdsl types 会显示所有已加载的标准类型和领域类型，以及它们的运行时角色、必需字段、能力、架构版本和来源。如果其他工具需要发现类型系统，请使用 --json。

memdsl lint --json 会在 memdsl.lint.v1 信封中报告与文本输出相同的发现：包含每条诊断的代码、严重级别、文件、行和声明 ID，以及计数和 status，其值为 ok、errors 或 strict_warnings，并与退出代码一致。

自定义编码规则的行为与 MUST 约束完全相同，无需任何 Python 代码知道 coding.project_rule 这个名称：

MUST
- [coding.project_rule:git.no_force_push] Never force-push the main branch. [status=active; runtime_role=constraint; lifecycle={"status":"active"}]

合规性检查会返回 BLOCK，并引用同一条领域声明。未受保护或不可强制执行的约束会安全地转为 NEEDS_REVIEW，而不会被擅自推断。

分层查询约定

查询返回的是 EvidencePack，而非扁平的命中列表：

• MUST：适用的 constraint 声明
• SHOULD：相关的 guidance 声明
• CONTEXT：相关的 assertion 声明
• PROVISIONAL：经评分的非活跃可搜索声明
• CONFLICT：所选记忆之间声明的冲突
• MISSING：相关的 question 声明和已知缺口

每个条目都包含稳定的声明 ID、类型、运行时角色、能力、主张、主体、范围、置信度、生命周期、访问策略、证据和源位置。领域语义保持灵活，同时运行时行为保持可预测。

JSON 输出仍为 memdsl.evidence_pack.v1；在 0.6 中新增的 provisional 字段在 0.8 中仍是增量添加的。经评分的 CONTEXT 和 PROVISIONAL 条目包含 score 和 matched_terms，每个声明条目也都包含明确的生命周期状态和运行时角色。

参考检索器刻意采用词法检索，并使用可重建的倒排词项索引。生产系统可以在相同的 EvidencePack 约定下使用 BM25、嵌入、图或数据库索引。

导航：先查看有界目录，再查询并逐步深入

memdsl 的存在，是因为由 Agent 驱动的阅读胜过盲目的相似度匹配： 知道某条记忆存在的 Agent 可以逐步深入查看，而未能找到目标的检索器 只会返回空结果。以下四种方式支持这一流程：

• 有界目录（memdsl catalog、MCP memory_catalog / memdsl://catalog、Python build_memory_catalog）：按模块／类型／主题／状态筛选 的模块摘要。默认分页为 20 项／8192 个规范紧凑 UTF-8 JSON 字节。truncated、 next_cursor、returned_items、精确总数，以及词汇总数／截断元数据均会明确提供。 游标绑定 Source 指纹、仅用于报告的 View、筛选条件、顺序和表示形式； Source 变更时会返回 cursor_stale。
• Map v1 兼容模式（memdsl map、MCP memory_map / memdsl://map、 Python build_memory_map）：仍会为现有客户端返回完整且可服务的声明索引。 不建议在大型工作区的会话开始时使用此方式。在明确启用 workspace-v2 强制执行时， 它会返回 unsupported_view；Map 和 Catalog 用于导航，而非引用。
• 搜索轨迹（序列化包中的 search_trace）：查询的解读方式、运行了哪些索引、 筛选前后的候选池，以及类型／主题筛选排除了哪些匹配声明。无匹配结果时， 可能会添加有界词法 vocabulary_suggestions 和 retry_queries；候选、模糊或 受访问限制的词汇绝不会成为自动路由。
• 有界轨迹（memdsl trace、MCP memory_trace、Python trace_memory）：通过确定性 BFS 跟踪明确解析的关系。默认深度为 3、节点数为 20、 边数为 40，字节数为 8192。无状态游标绑定 Source/View、锚点、方向、关系筛选条件、 深度和临时可见性。回边／环边／跨边会明确标出；图的连通性不是证据或证明。

预检约束

任何由 schema 定义的 constraint 都可以参与 memdsl check。若要运行确定性 防护，其类型必须同时声明 enforceable 和 guardable。短语和正则防护会生成 ALLOW 或 BLOCK；仅以自然语言描述的约束会生成 NEEDS_REVIEW。 声明的例外必须通过 --exception 明确断言。

标准 v0.4 boundary 类型采用相同的通用流程。为兼容客户端，仍支持 boundary_id 和 applicable_must 等旧 JSON 别名。

运行可复现的标准套件或自定义领域套件：

memdsl eval compliance examples/compliance \
  --cases examples/compliance/cases.jsonl --json

memdsl eval compliance examples/domains/coding \
  --cases examples/domains/coding/cases.jsonl --json

用作 MCP 服务

MCP 服务需要 Python 3.10+：

# Python 3.10+
pip install "memdsl[mcp]"
memdsl-mcp --workspace examples/domains/coding --inspect
memdsl-mcp --workspace ~/memory

MCP 服务提供：

• 工具：memory_catalog、memory_map、memory_types、memory_query、memory_trace、memory_check、 memory_explain、memory_list、memory_lint、memory_propose、 memory_review_list
• 资源：memdsl://status、memdsl://catalog、memdsl://map、memdsl://types、 memdsl://files、memdsl://file/{file_id}

Agent 应在会话开始时读取 memory_catalog，以便随着工作区扩大，导航仍保持有界， 然后使用 memory_query 和有界 memory_trace 进行局部深入查看。memory_map 仍供 v1 客户端使用。提出声明之前，请调用 memory_types 或读取 memdsl://types。这样 可以发现工作区的词汇，而不是凭空创造类型，或假定标准包是唯一有效的世界观。

可通过 --scopes 或 MEMDSL_MCP_SCOPES 缩小访问范围（默认值： read:summary,read:search,write:candidate）。核心会表示并传递声明级别的 access_policy。对于强制执行的 View，嵌入式宿主只能在构造 MemdslMCPService 时注入可信主体和角色；MCP 工具参数不能自行声明身份。 过滤会在计数、词汇、诊断、图遍历和原始文件资源处理之前进行。memdsl 不提供身份 提供方，因此宿主必须对主体进行身份验证并映射角色。

门控写入

每次 MCP 写入仍然只是提案。必须使用已加载的类型，通过解析，并通过针对实时工作区的 lint 检查。无效提案会被拒绝；与待处理项或已批准项完全重复的提案会返回 no_op；其他提案要么进入队列，要么根据由主机认证的策略进行范围严格受限的自动批准。

默认仍是全部由人工处理。初始化一个有效但已禁用的策略：

memdsl review policy init memory
memdsl review policy show memory
memdsl review policy validate memory

生成的 JSON 中，客户端和规则均为空，且每日限额为零。若要启用自动化，工作区所有者必须明确将 auto_approvable 添加到某个候选断言类型，为精确类型配置规则和可信主机客户端，设置正数每日限额，并授予非默认的 write:auto 范围：

memdsl-mcp --workspace memory \
  --scopes read:summary,read:search,write:candidate,write:auto

内置的 workspace_file_quote 验证器要求 evidence.source 指向已加载工作区根目录内的文件，并且 evidence.quote 必须在该 UTF-8 文件中原样出现。问题、指导、约束、符号、活动、全局、已警告、破坏性或未经验证的提案始终会进入队列。若没有 write:auto，有效策略会以影子模式运行：写入仍保持待处理状态，同时由 eligible_route 记录策略原本会采取的操作。

人工操作和质量反馈仍需明确执行：

memdsl review list memory
memdsl review approve memory PROPOSAL_ID --into memory/approved.mem
memdsl review reject memory PROPOSAL_ID --reason "not durable"
memdsl review digest memory
memdsl review stats memory
memdsl review audit memory PROPOSAL_ID --verdict confirm

review list、review show 和 review audit 支持 --json，与现有的 policy show、digest 和 stats JSON 输出一样，因此队列仪表板或 CI 作业无需解析人类可读文本即可读取队列。批准和拒绝仍是纯文本决策。

进程内主机使用权威路径：

from memdsl import (
    ProposalContext,
    ReviewStore,
    Workspace,
    load_policy,
    staging_dir_for,
)

workspace = Workspace.load(["memory"])
store = ReviewStore(staging_dir_for(["memory"]))
policy = load_policy(store.staging_dir, registry=workspace.registry)
assert policy is not None
context = ProposalContext(client_id="mcp-client")

result = store.submit(
    ["memory"],
    proposal_source,
    policy=policy,
    context=context,
    write_auto_granted=True,
)

自动批准会重新加载并为记忆、清单和架构输入生成指纹，重新验证证据，强制执行有限的 UTC 每日限额，只写入主工作区根目录内非符号链接的 .mem 目标，且绝不使用 force。路由评估、决策、审核后结果、摘要游标和无操作事件均以仅追加方式记录。

审核后的 flag 不会静默删除记忆。晋升、修订和撤回都需要新的人类审核声明，该声明必须使用新 id，并通过 supersedes（可选 revision_of）指向旧声明。后继声明必须处于 active 生命周期状态，该关联才具有效力；无需原地将旧声明重写为 status: superseded。 ReviewStore 不会创建 Git 提交；主机可以添加 Git 集成，但不得让核心正确性依赖于它。

包含内容

• 一种与领域无关的 .mem 记录，包含来源、范围、置信度、生命周期、访问策略、关系和稳定 id。
• 可扩展、带命名空间的 .memschema.json 类型系统和工作区清单。
• 与旧版 v0.5 之前工作区向后兼容的标准类型包。
• 架构驱动的 lint 检查器、分层查询执行器、解释器和确定性合规门控。
• 通过 CLI 和 MCP 发现类型。
• 默认安全且经主机认证的审核流水线，支持人工排队、确定性且范围严格受限的自动批准、无操作检测、摘要/统计信息和仅追加审计。
• 可复现的合规基准测试，以及面向编码、助手和写作领域的类型包。
• Alex 和 Mira 的虚构标准示例，以及一个刻意设置了错误的 lint 工作区。

完整语法和语义见 docs/SPEC.md。进程内主机还应阅读 docs/PUBLIC_API.md 和 docs/UPGRADING.md。审核策略的安全契约见 docs/DESIGN_review_policy.md。 文档索引汇集了软件契约、实现设计、发布边界和可复现性资料。

memdsl 不是什么

• 它不是 Mem0、Zep、Graphiti 或 LangMem 等检索／提取系统的替代品，而是这些系统之上的受治理源格式和行为契约。
• 它不是通用的人物或记忆分类体系。各领域所有者自行定义类型。
• 它不是语义策略判定器。无法确定性评估的约束仍标记为 NEEDS_REVIEW。
• 它不是不受限制的自动记忆写入器。只有明确选择加入、身份可信且证据已验证的候选断言，才能自动批准；所有风险更高或存在不确定性的提议仍须由人工审核。

当前证据与局限

从本项目提取出的私有单用户系统获得的早期证据表明，在该系统的内部评估中，检索精确率高于其调优后的 RAG 基线。这个结果令人鼓舞，但不能证明某一种本体适用于所有人。v0.8 架构明确体现了这一局限：memdsl 标准化记录和运行时契约，同时允许各领域自行定义词汇。

随附套件是契约级的确定性测试。关于跨模型行为的主张仍需通过单独记录的模型运行来验证。

路线图

• 双层核心＋可扩展领域类型系统 — 已于 v0.5 发布
• 生命周期安全的临时服务＋分级审核策略 — 已于 v0.6 发布
• 公开且可重建的 CompiledWorkspace＋有界 Catalog 分页／预算 — 稳定／公开的 0.8 契约已随 0.9.0 发布
• 索引查询＋有界 Trace＋精确的 use/report/strict＋经审核的 Dialect — 稳定／公开的 0.8 契约已随 0.9.0 发布
• 通过显式 v2 信封实现选择加入的隔离区强制执行 — 稳定／公开的 schema／安全契约；实际推广质量仍属实验性
• 选择加入的一等经审核 Edge 实验 — 在一次匿名探索性 Pilot 后，已作为实验性功能随 0.9.0 发布；关系／证据范围的收窄仍为 ADJUST，并非正式实证验证
• 冷历史／增量编译 — 延后至有代表性的规模、SLO 和生产瓶颈证据具备后再开展
• Schema 包分发、依赖／版本约束及迁移
• 更丰富的字段验证器和由领域定义的诊断规则
• 在 EvidencePack 契约后提供可插拔的检索后端
• 用于强制执行所表示访问策略的身份提供商适配器
• 语义冲突审核器和按客户端／规则设置的配额，须以经过测量的影子／抽样／审核后证据为前提

许可证

代码：MIT。规范（docs/SPEC.md）：CC-BY-4.0。

---

中文

0.9 正式软件版本中的实验性 Edge

0.9.0 新增了明确选择加入的 memdsl.workspace.v3 一等 Edge 实验，不会改写已冻结的 0.8 契约：legacy relation 与 authority 保持兼容，Edge proposal 始终进入人工 审核，显式 supersedes 在本阶段仅进入 graph。当前 runtime authority 仍来自 Source；review/audit 只是 workflow contract，并非不可绕过的授权账本。详见 Phase 6 设计与风险矩阵 与 发布范围证据冻结。

将 Agent 记忆写成 Agent 自己会读取的源代码。

Stable 0.8 兼容合同

0.8 合同把此前未单独发布的导航能力与 View 能力统一后由 0.9.0 承载；0.7.0 与 0.8.0 均未单独发布。正式公共合同包括 Source/review authority、公共且可重建的 CompiledWorkspace / compile_workspace、v1 兼容 surface、Catalog v1、Trace v1、indexed query/search trace、report diagnostics、memdsl.workspace.v2、 exact use、通用 dialect_mapping capability、ViewContext/ResolvedView 与 显式 opt-in 的 v2 read schemas。Map v1 在整个 0.8 line 继续保留，不早于 1.0 才重新评估删除。

正式软件版本为 0.9.2，由 tag v0.9.2 锚定。它增加官方 MCP Registry 元数据 和用于安装默认只读 memdsl-mcp 服务的 UV MCPB 包；parser、schema、review、 query、authority 与 MCP tool 合同均与 0.9.1 相同。无论 patch 还是软件版本发布， 都不会把 opt-in Edge 提升为 stable，也不会让自动 Edge 生成获得 authority。

quarantine/strict 的真实 rollout 质量、dialect candidate 学习闭环和宿主证明 principal 的集成仍是 experimental/opt-in；但 authorization-before-aggregation、 hard rule 不完整时不得 ALLOW、非权威 edge 不得获得 authority、repair lane 必须 可用等安全不变量不是实验性的。CompiledWorkspace 是公共、可重建 handle；其 cache/index 布局、compiler contract 字符串和 synthetic timing 仍是内部事实。 workspace-v3 一等 Edge 保持 experimental；自动方言学习、自动 Edge 候选、inferred authority 与冷历史/增量编译尚未发布。宿主 extractor/sanitizer、私人 schema/policy/ 样本不属于 memdsl，也不构成 release gate。

memdsl 起源于一次召回失败。一个基于 RAG 的记忆系统没能召回一条确实存在的 记忆；而一个 coding agent 拿到同样的原始记忆文件，几步就把它找了出来。 同一个模型——差别在上下文契约：agent 知道那条记忆存在，可以一层层读过去； 检索器只有一次相似度猜测，而且"没命中"和"不存在"看起来一模一样。

memdsl 把这个差别做成了产品。长期记忆保存在可读、可 lint、可审查的 .mem 源文件里，每个运行时 surface 都为"agent 自己读记忆"而设计：

• 有界记忆目录 Catalog（memdsl catalog、MCP memory_catalog / memdsl://catalog、Python build_memory_catalog）：按 module/type/subject/ status 分页导航，具备 item/byte 硬预算、绑定 revision 的稳定 cursor，并避免 structured/text 双份返回；这是大型 workspace 推荐的会话起始 surface。
• 兼容记忆地图（memdsl map、MCP memory_map / memdsl://map）：旧的 v1 全量索引继续保留，不会被原地改成 Catalog。
• 带倒排索引、会解释 miss 的查询（序列化 pack 中的 search_trace）： 确定性的词法 postings 保持 v1 EvidencePack 排序与 authority lane，同时返回 View/source、候选池、filter-hidden match、受限词汇建议和安全 retry query；建议 不会写 alias，也不会让 candidate symbol 改写路由。
• 有界关系 Trace（memdsl trace、MCP memory_trace、Python trace_memory）：确定性的 incoming/outgoing/both BFS、relation filter、显式 cycle/back/cross edge、depth/node/edge/byte 硬预算与 revision-bound cursor。 连通性只是导航，不是证明。
• 原始源码兜底（memdsl://file/{file_id}）：agent 随时可以下钻去读 真正的声明，就像 coding agent 读代码一样。

当年启动这个项目的那种失败，现在会大声报错——记忆存在，是过滤器藏了它， trace 会把话说明白：

$ memdsl query examples/domains/coding -q "force push main" \
    --type coding.bug_pattern --json
  "missing": [
    "no active declarations matched query terms: ['force', 'push', 'main']",
    "1 active declaration(s) matched the query but were excluded by type/subject filters"
  ],
  "search_trace": {
    "excluded_by_filters": [
      {"id": "coding.project_rule:git.no_force_push", ...}
    ], ...
  }

$ memdsl query examples/domains/coding -q "force push main"
MUST
- [coding.project_rule:git.no_force_push] Never force-push the main branch. (exceptions: []) [status=active; runtime_role=constraint; lifecycle={"status":"active"}]

两分钟在 Claude Code 里跑起来

底层库和 CLI 支持 Python 3.9+。由于上游 MCP SDK 的要求，MCP extra 和 memdsl-mcp server 需要 Python 3.10+。

# Python 3.10+
pip install "memdsl[mcp]"
claude mcp add memdsl -- memdsl-mcp --workspace ~/memory   # 或任意 examples/ 目录

server 会指示 agent 先读 memory_catalog，只在 Source/View 和过滤条件不变时 继续 cursor，把 no_match 当作重试信号，只用 memory_trace 做有界的显式关系 导航，并在产出重要草稿前用 memory_check 对照 MUST 约束做预检。旧客户端仍可调用 memory_map。

受治理的类型化记忆

第二根支柱：像审代码一样审记忆，但不要求所有用户接受作者的一套世界观。 v0.8 保留 v0.5 引入的两层类型架构与 v0.6 的 lifecycle 安全审核合同，并加入 有界编译导航与显式 workspace-v2 View：

底层通用记录        claim / evidence / scope / confidence / lifecycle /
                    access policy / relations

上层领域类型系统    coding.project_rule / assistant.commitment /
                    writing.voice_preference / 用户自定义类型

底层负责稳定的行为契约，workspace 负责自己的词汇。编程 Agent、个人助理和 写作系统不应该仅仅因为 memdsl 作者选择了 preference、boundary、fact 这些词，就被迫用同一套分类描述自己的记忆。

两层架构

底层提供通用字段和五种稳定的 runtime role：

Runtime role	在 EvidencePack 中的行为
symbol	定义其他记忆可以引用的主体
constraint	只有 active 声明进入 MUST 并参与合规检查
guidance	只有 active 声明进入 SHOULD
assertion	只有 active 声明相关时进入 CONTEXT
question	只有 active 声明进入 MISSING，而不是伪装成事实

任何 searchable 的非 active 命中都只进入 PROVISIONAL，不论 runtime role。 candidate symbol 不能重定向查询，candidate constraint 不能进入 MUST 或 compliance。

同一 authority 边界也适用于关系。只有 source 为 active，且 full id 精确匹配或 bare ref 唯一解析时，supersedes 才能隐藏 target。candidate、retracted、 archived、歧义、重复或错误 kind 前缀的 superseder 都不能改变 query、MUST 或 compliance。这是 0.8 继续保留的 v1 correctness/security authority 规则。 ResolvedView 复用这个安全基础，只在显式 v2 opt-in 时增加 quarantine enforcement。

底层还识别 requires_evidence、searchable、temporal、 enforceable、guardable、exceptions_recommended，以及显式审核 opt-in 的 auto_approvable 等 capability。

上层定义领域真正关心的 memory type，并把每种类型编译到一个稳定 role。 仓库自带三个示例领域：

• 编程：coding.project_rule、coding.bug_pattern、 coding.tool_preference
• 个人助理：assistant.routine、assistant.commitment、 assistant.relationship_context
• 写作：writing.voice_preference、writing.taboo_topic、 writing.style_example

内置的 memdsl.standard@1 兼容包会继续加载 entity、fact、 preference、boundary、principle、decision、state、 open_issue 等旧类型。它们是向后兼容的默认词汇，不是人类记忆的唯一分类法。

定义自己的领域词汇

workspace 通过 memdsl.json 引入 schema：

{
  "schema_version": "memdsl.workspace.v1",
  "schemas": ["coding.memschema.json"]
}

.memschema.json 定义类型的字段、role 和 capability：

{
  "name": "coding",
  "version": "1",
  "types": {
    "project_rule": {
      "runtime_role": "constraint",
      "required_fields": ["claim", "evidence", "scope"],
      "optional_fields": ["rationale", "owner"],
      "search_fields": ["rationale", "owner"],
      "capabilities": [
        "requires_evidence",
        "searchable",
        "enforceable",
        "guardable",
        "exceptions_recommended"
      ],
      "defaults": {"force": "hard", "status": "active"},
      "allowed_forces": ["hard"],
      "allow_extra_fields": false
    }
  }
}

加载后，project_rule 的完整名字是 coding.project_rule：

coding.project_rule git.no_force_push {
  subject: Repository.Memdsl
  claim: "绝不对 main 分支执行 force-push。"
  scope: repository("memdsl")
  confidence: high
  exceptions: []
  rationale: "已发布的历史必须保持可审计。"
  guard {
    when_any: ["push", "git", "main"]
    deny_any: ["force-push", "--force", "--force-with-lease"]
  }
  lifecycle { status: active }
  access_policy {
    readers: [developer, coding_agent]
    writers: [maintainer]
    reviewers: [maintainer]
    export: internal
  }
  evidence {
    source: AGENTS.md
    quote: "除非用户明确要求，否则不要 force-push。"
  }
}

严格 schema 会拒绝未声明字段。未知类型会产生 unknown_memory_type lint 错误，不会悄悄获得一套临时行为。

精确 use 与 workspace 自有方言

旧 workspace 保持兼容：没有 manifest 或使用 memdsl.workspace.v1 时仍是 legacy 全局链接。只有显式使用 v2，才会进入 report 或 strict：

{
  "schema_version": "memdsl.workspace.v2",
  "schemas": ["workspace-dialect.memschema.json"],
  "linking": {"visibility": "report"}
}

compiler 会先建立整库 module/symbol 表，再解析 use X，所以声明顺序不影响结果。 X 只能精确命中一个 module 或一个 active symbol name；不支持通配符、前缀、 alias，也不设置 module 优先或 symbol 优先。report 保留 legacy 链接并给迁移诊断； strict 会去掉未导入 relation、subject 路由和 dialect 路由的效果。v1 绝不会因为 出现了 use 就被暗中切成 strict。

方言仍是 workspace 自己拥有、可版本化、可审核的 Source。schema type 通过通用 dialect_mapping capability opt in，仓库提供了完全虚构、可运行的 examples/dialect/。只有 active、公开、结构有效、无歧义的 positive mapping 才会路由；candidate、pending、private、ambiguous 和 negative mapping 都不会。 no-match 可以返回 search_trace.dialect_candidate 模板，但不会自动写 Source； 仍需 evidence、proposal、人工审核、批准和重新编译。

显式 opt-in 的 quarantine enforcement

workspace v2 可以独立开启 v2 读取 gate：

{
  "schema_version": "memdsl.workspace.v2",
  "schemas": ["workspace-dialect.memschema.json"],
  "linking": {"visibility": "report"},
  "enforcement": {"mode": "quarantine"}
}

省略 enforcement 或选择 report，仍保持 v1 读取行为。quarantine 与 strict 必须显式 opt in；它们把 Source 分成 authoritative、provisional、 quarantined、excluded，并使用新的 query/list/explain/check/Catalog/Trace v2 envelope。空结果会明确区分 no_match、quarantined、unauthorized、 compiler_error 与预算不足。identity-critical 错误 fail closed，relation/use/ dialect/type 错误则尽量只隔离最小安全的 declaration、文件或 revision family。 lint、直接编辑 Source、proposal、review 和 audit 修复通道仍然开放。

Map 保持 v1 兼容面，在显式 enforcement 下返回 unsupported_view；应改用 Catalog、query、list、explain 或 Trace。pending proposal 仍不会进入 durable View，candidate/private/ambiguous dialect 也不会借 quarantine 获得路由权。

安装与类型发现

基础包支持 Python 3.9+：

pip install memdsl                 # 或在 checkout 中运行 pip install -e .
memdsl --version
memdsl types examples/domains/coding
memdsl lint examples/domains/coding --json
memdsl catalog examples/domains/coding --json
memdsl map examples/domains/coding
memdsl query examples/domains/coding -q "force push main"
memdsl trace examples/alex decision:aurora.pricing_free_tier --both --depth 2 --json
memdsl check examples/domains/coding \
  -t "push main" \
  -c "git push --force origin main"

memdsl types 会列出已加载的标准类型和领域类型，以及各自的 runtime role、 必填字段、capability、schema 版本和来源。需要给其他工具消费时可加 --json。

memdsl lint --json 输出与文本模式完全相同的诊断，包在 memdsl.lint.v1 信封里：每条诊断的 code、severity、文件、行号、声明 id，加上计数和与退出码 一致的 status（ok、errors 或 strict_warnings）。

上面的自定义类型不需要在 Python 代码里写死 coding.project_rule，依然会作为 MUST 约束出现：

MUST
- [coding.project_rule:git.no_force_push] Never force-push the main branch. [status=active; runtime_role=constraint; lifecycle={"status":"active"}]

合规检查会返回 BLOCK 并引用同一个领域声明。没有 guard 或不具备执行能力的 约束会安全返回 NEEDS_REVIEW，不会假装已经理解。

分层查询契约

查询返回的是 EvidencePack，而不是扁平命中列表：

• MUST：适用的 constraint
• SHOULD：相关的 guidance
• CONTEXT：相关的 assertion
• PROVISIONAL：带分数的非 active searchable 声明
• CONFLICT：已声明的冲突
• MISSING：相关的 question 和已知信息缺口

每一项都携带稳定 id、类型、runtime role、capability、claim、subject、scope、 confidence、lifecycle、access policy、evidence 和源码位置。这样领域语义可以扩展， 运行时行为仍然稳定。

JSON 输出仍为 memdsl.evidence_pack.v1；v0.6 加入的 provisional 在 v0.8 继续保持 additive。带分数的 CONTEXT 和 PROVISIONAL 条目都包含 score、 matched_terms，每个 declaration item 还明确携带 lifecycle status 和 runtime role。

参考实现使用可重建的词法倒排索引。生产系统可以在同一个 EvidencePack 契约 后面替换成 BM25、embedding、图或数据库索引。

导航：先读有界 Catalog，再查询和下钻

memdsl 的出发点是"让 agent 自己读记忆"胜过"让相似度匹配替 agent 决定"： 知道某条记忆存在的 agent 可以一层层钻下去，而检索器一旦没命中就什么都没有。 四个 surface 支撑这个闭环：

• 有界 Catalog（memdsl catalog、MCP memory_catalog / memdsl://catalog、Python build_memory_catalog）：按 module 汇总，并可按 module/type/subject/status 过滤。默认 20 items / 8192 canonical compact UTF-8 JSON bytes；truncated、next_cursor、returned_items、精确 total 和词表 total/truncated metadata 都显式返回。cursor 绑定 Source fingerprint、 report-only View、过滤条件、顺序和 representation；Source 改变会返回 cursor_stale。
• Map v1 兼容面（memdsl map、MCP memory_map / memdsl://map、Python build_memory_map）：继续为旧客户端返回全量可服务声明索引，但不再推荐作为 大型 workspace 的会话起始 surface。显式 workspace-v2 enforcement 下会返回 unsupported_view。Map 与 Catalog 都只是导航，不是引用来源。
• 检索痕迹（序列化 pack 中的 search_trace）：记录查询被如何解释，以及 使用了哪些 index、过滤前后候选池，以及 type/subject filter 排除了哪些本来 匹配的声明。no-match 可返回有界 vocabulary_suggestions 与 retry_queries；candidate、歧义或 access-restricted 词汇不会成为自动路由。
• 有界 Trace（memdsl trace、MCP memory_trace、Python trace_memory）：沿已解析的显式关系做确定性 BFS。默认 depth 3、20 nodes、 40 edges、8192 bytes；cursor 绑定 Source/View、anchor、direction、relation、 depth 与 provisional visibility。back/cycle/cross edge 显式返回，但连通性不是 evidence 或 proof。
• 只报告、不隔离的链接诊断（memdsl lint、MCP memory_lint 与 memdsl://status）：duplicate id、歧义/错误前缀/dangling target、未知 relation、 revision cycle 和 supersede fork 都会显式出现。cycle edge 不会让参与节点全部 消失，fork 不会暗选 winner，而默认 Map/query authority 仍保持 v1 兼容。

执行前约束检查

任何被 schema 编译为 constraint 的类型都可以参与 memdsl check。要执行 确定性的 guard，该类型必须同时声明 enforceable 和 guardable。短语与正则 guard 返回 ALLOW 或 BLOCK；只有自然语言的约束返回 NEEDS_REVIEW。 例外必须由调用方通过 --exception 显式声明。

v0.4 的标准 boundary 也走同一条通用链路。boundary_id、 applicable_must 等旧 JSON 字段仍作为兼容别名保留。

memdsl eval compliance examples/compliance \
  --cases examples/compliance/cases.jsonl --json

memdsl eval compliance examples/domains/coding \
  --cases examples/domains/coding/cases.jsonl --json

作为 MCP server 使用

MCP server 需要 Python 3.10+：

# Python 3.10+
pip install "memdsl[mcp]"
memdsl-mcp --workspace examples/domains/coding --inspect
memdsl-mcp --workspace ~/memory

MCP server 提供：

• tools：memory_catalog、memory_map、memory_types、memory_query、memory_trace、memory_check、 memory_explain、memory_list、memory_lint、memory_propose、 memory_review_list
• resources：memdsl://status、memdsl://catalog、memdsl://map、memdsl://types、 memdsl://files、memdsl://file/{file_id}

Agent 应该在会话开始时读取 memory_catalog，让导航成本不随 workspace 总量 线性膨胀，再用 memory_query 与有界 memory_trace 局部下钻；memory_map 继续服务 v1 客户端。在提出新声明前，应该先调用 memory_types 或读取 memdsl://types，发现当前 workspace 的词汇，而不是自己 发明类型，也不是默认标准兼容包就是唯一世界观。

可通过 --scopes 或 MEMDSL_MCP_SCOPES 缩小 MCP 权限范围，默认值为 read:summary,read:search,write:candidate。底层会表示、验证并传输声明级 access_policy。在 enforced View 中，嵌入式宿主只能在构造 MemdslMCPService 时注入可信 principal 与 roles；MCP tool 参数不能自报身份。 过滤发生在 count、vocabulary、diagnostics、graph traversal 和 raw-file resource 之前。memdsl 不提供身份提供商；宿主仍需认证 principal 并映射 roles。

受审查的写入

每次 MCP 写入仍然先成为 proposal。新声明必须使用已加载类型，能够解析，并 通过当前 workspace 的 lint。非法 proposal 会被拒绝；与 pending/approved 内容 完全相同的提交返回 no_op；其余 proposal 要么排队，要么由宿主证明过的窄 策略自动批准。

默认仍然全部人审。先生成一份合法但禁用自动批准的 policy：

memdsl review policy init memory
memdsl review policy show memory
memdsl review policy validate memory

生成的 JSON 里 trusted clients 和 rules 都为空，日限额为 0。要开启自动化， workspace owner 必须给一个 candidate assertion 类型显式加入 auto_approvable，配置精确 kind 规则和可信宿主 client，设置正数日限额， 再授予默认不包含的 write:auto scope：

memdsl-mcp --workspace memory \
  --scopes read:summary,read:search,write:candidate,write:auto

内置 workspace_file_quote verifier 要求 evidence.source 解析到已加载 workspace root 内，且 evidence.quote 必须逐字出现在该 UTF-8 文件中。 question、guidance、constraint、symbol、active、global、带 warning、带破坏性 关系或证据未验证的 proposal 始终排队。没有 write:auto 时，合法 policy 处于 shadow 姿态：写入仍 pending，但 eligible_route 会记录策略原本会怎么做。

人工操作与质量反馈保持显式：

memdsl review list memory
memdsl review approve memory PROPOSAL_ID --into memory/approved.mem
memdsl review reject memory PROPOSAL_ID --reason "not durable"
memdsl review digest memory
memdsl review stats memory
memdsl review audit memory PROPOSAL_ID --verdict confirm

review list、review show、review audit 与已有的 policy show、digest、 stats 一样支持 --json，队列面板或 CI 任务不必再解析给人看的文本。approve 与 reject 仍然只有文本输出，保持决策动作显式。

进程内宿主应传入权威 workspace paths：

from memdsl import (
    ProposalContext,
    ReviewStore,
    Workspace,
    load_policy,
    staging_dir_for,
)

workspace = Workspace.load(["memory"])
store = ReviewStore(staging_dir_for(["memory"]))
policy = load_policy(store.staging_dir, registry=workspace.registry)
assert policy is not None
context = ProposalContext(client_id="mcp-client")

result = store.submit(
    ["memory"],
    proposal_source,
    policy=policy,
    context=context,
    write_auto_granted=True,
)

自动批准前会重新加载并 fingerprint 记忆、manifest 和 schema，重新验证证据， 执行有限 UTC 日配额，只写入主 workspace root 内的非 symlink .mem 目标， 且绝不使用 force。路由 assessment、decision、post-review 结果、digest cursor 和 no-op 事件都保持 append-only。

post-review flag 不会静默删除记忆。晋升、修订和撤销都要提交一条新 id 的 人工审核声明，用 supersedes（可同时用 revision_of）指向旧声明。successor 必须是 lifecycle active 才获得关系 authority；旧声明不需要原地改成 status: superseded。 ReviewStore 不创建 Git commit；宿主可以增加 Git 集成，但核心正确性不依赖 Git。

包里有什么

• 与领域无关的 .mem 通用记录：来源、scope、confidence、lifecycle、 access policy、relations 和稳定 id。
• 可扩展、带 namespace 的 .memschema.json 类型系统和 workspace manifest。
• 面向 v0.5 之前 workspace 的标准兼容类型包。
• schema 驱动的 linter、分层查询、explain 和确定性 Compliance Gate。
• CLI 与 MCP 的类型发现能力。
• 默认安全、宿主证明的审核链路：人工队列、确定性的窄范围自动批准、no-op 检测、digest/stats 和 append-only audit。
• 可复现合规 benchmark，以及 coding、assistant、writing 三个领域包。
• Alex、Mira 两个虚构标准示例和一个故意损坏的 lint 示例。

完整语法与语义见 docs/SPEC.md。进程内宿主还应阅读 docs/PUBLIC_API.md 和 docs/UPGRADING.md。 审核策略的安全合同见 docs/DESIGN_review_policy.md。 文档索引 把软件合同、实现设计、发布边界和 可复现材料集中在一起。

memdsl 不是什么

• 它不是 Mem0、Zep、Graphiti、LangMem 等检索/抽取系统的替代品，而是位于 这些系统之上的受治理源格式和行为契约。
• 它不是人或记忆的通用分类法；领域所有者定义自己的类型。
• 它不是语义策略裁判；无法确定性执行的约束会保持 NEEDS_REVIEW。
• 它不是不受限制的自动记忆写入器。只有显式 opt-in、身份可信且证据已验证的 candidate assertion 才可能自动批准；所有高风险或不确定 proposal 仍由人审。

当前证据与边界

这个项目来自一个私有的单用户系统。该系统的内部评测曾显示，DSL 结构化检索的 precision 高于它自己的调优 RAG baseline。这个结果值得继续验证，但不能证明一套 ontology 对所有人都通用。v0.8 正面承认这个限制：memdsl 标准化记录结构和运行 契约，把领域词汇的所有权交还给使用者。

仓库内置的是确定性的契约级测试。跨模型行为结论仍需单独记录真实模型运行。

Roadmap

• 两层 core + 可扩展领域类型系统 — v0.5 已完成
• lifecycle 安全的 provisional 服务 + 分级审核策略 — v0.6 已完成
• 公共可重建 CompiledWorkspace + 有界 Catalog 分页/预算 — 0.9.0 已发布的 stable/public 0.8 合同
• 倒排查询 + 有界 Trace + exact use/report/strict + 受审核 Dialect — 0.9.0 已发布的 stable/public 0.8 合同
• 显式 v2 envelope 下的 opt-in quarantine enforcement — schema/安全合同 stable/public，真实 rollout 质量仍为 experimental
• 显式 opt-in 的一等可审核 Edge 实验 — 0.9.0 以 experimental 状态承载该能力，依据匿名探索性 Pilot 开启；relation/evidence 收窄结论仍为 ADJUST，不是正式实证验证
• 冷历史/增量编译 — 等待代表性规模、SLO 与生产瓶颈证据
• Schema 包分发、依赖/版本约束和迁移机制
• 更丰富的字段验证器和领域诊断规则
• EvidencePack 后面的可插拔检索后端
• 执行 access policy 的身份提供商适配器
• 基于 shadow/sample/post-review 数据的语义冲突 reviewer 与 per-client/per-rule 配额

许可证

代码：MIT。规范（docs/SPEC.md）：CC-BY-4.0。