Skip to main content
Glama

memory_reconcile_candidates

Surface similar task memos, stale direction entries, and promotion candidates for memory reconciliation. Acquire a project lease, then apply approved operations.

Instructions

按需整理·粗筛:返回情景层候选组 + 方向层清单 + 蒸馏素材 + 操作说明。

调用即占住本项目的整理权(同一项目同一时刻只有一个会话能整理,别的会话 会被挡在门外):判完没有要改的,提交空批 memory_reconcile_apply(operations=[]) 释放。只想看一眼有什么可整理(例如 Leader 循环里的例行查看),传 peek=true: 只读、不占整理权,但这样拿到的候选不能直接 apply。

记忆整理 = 会话内按需显式动作(CC 非常驻,无后台整理进程)。本工具只做 确定性粗筛(零 LLM)——OS 无独立 LLM 凭据,判定由你(调用工具的会话内 agent)完成,工具只负责候选粗筛与操作应用("agent 算、工具存")。

返回四块(project_id 自动按当前上下文解析):

  • candidate_groups:有效 task_memos 按 scope_path/task 聚簇、簇内 BM25 两两 相似度超阈配对成的候选组(含组内各条全文 + id)。逐组做 LLM 精判: KEEP(都留)/ MERGE(合并)/ INVALIDATE(矛盾失效)/ NOOP(不动)。

  • direction_inventory:全部有效方向层条目全文——逐条做陈旧检查(引用的 功能已退役/版本过时/世界已变 → 提 invalidate)。

  • promotion_candidates:高频跨任务反复出现的簇,蒸馏为方向层条目的素材 (promote 操作,source_refs 回指源 memo)。

  • operation_guide:四操作语义 + reconcile 三守则(只留高频有用 / 指向权威 而非复述 / 重写精简优先)+ 量大开 ultracode 提示。

整理权(reconcile_lease):30 分钟,持有者每次 candidates/apply 顺延。 别的会话持有未过期的整理权时返回 success=false、对方还要多久到期和可选的 做法,不交出候选(peek=true 照常可看)。

判完后把确认的操作交给 memory_reconcile_apply 批量应用。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
peekNotrue 时只读查看,不取整理权、不返回 lease_id(reconcile_lease.status 为 "peek"),拿到的候选不能拿去 apply;默认 false 即取得整理权
lease_idNo续用自己已持有的整理权时回传上次返回的 reconcile_lease.lease_id; CC 会话与 HTTP MCP 连接(如 Codex)自动识别本人,可不传
thresholdNo簇内 BM25 相似度配对阈值(0-1,默认 0.45)
scope_pathNo仅整理该路径作用域的 memo(留空=全项目有效 memo)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.15.0
    • addedInput schema / properties / lease_id
      Added value: +{
      +  "default": "",
      +  "description": "续用自己已持有的整理权时回传上次返回的 reconcile_lease.lease_id;\nCC 会话与 HTTP MCP 连接(如 Codex)自动识别本人,可不传",
      +  "type": "string"
      +}
    • addedInput schema / properties / peek
      Added value: +{
      +  "default": false,
      +  "description": "true 时只读查看,不取整理权、不返回 lease_id(reconcile_lease.status\n为 \"peek\"),拿到的候选不能拿去 apply;默认 false 即取得整理权",
      +  "type": "boolean"
      +}
  2. First observedv1.9.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and discharges it: it discloses that calling acquires an exclusive per-project reconcile lease (30 min, renewed per call), that concurrent sessions are blocked and receive success=false with remaining time, that peek is read-only and non-lease, and that screening is deterministic with zero LLM. These are exactly the behavioral traits an agent needs before invoking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a one-line summary (purpose + four return blocks), then bullets, then operational caveats, which is good structure for a complex tool. It is long and repeats the lease concept twice (the calling-acquires-lease warning and the reconcile_lease section), so it is efficient but not maximally tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with an output schema, the description needn't restate return fields, yet it usefully enumerates the four logical blocks and the four operation judgments (KEEP/MERGE/INVALIDATE/NOOP). Combined with lease mechanics, peek behavior and the apply handoff, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented in the schema, including peek's read-only semantics and lease_id's auto-identification. The description reinforces peek and lease behavior but adds no syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: on-demand coarse screening that returns four named blocks (candidate_groups, direction_inventory, promotion_candidates, operation_guide). It explicitly distinguishes itself from the sibling memory_reconcile_apply, which is named as the downstream application step, so an agent can route between them without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use guidance: call to obtain reconciliation rights, pass peek=true for read-only routine checks (e.g. in a Leader loop), pass empty operations to memory_reconcile_apply to release when nothing needs changing. It also names the alternative and its tradeoff (peek candidates cannot be applied), leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools