Positron 中 Copilot Chronicle 站立汇报（Standup）实战：用 `copilot_sessionStoreSql` 从会话历史自动生成每日工作报告

• 开发工具
• 代码编辑器
• 数据科学

导读：本篇文章聚焦 Positron（下一代数据科学 IDE）内置 Copilot 扩展的chronicle:standup提示词与其背后的chronicle技能，讲解如何借助copilot_sessionStoreSql工具对本地 SQLite（或云端 DuckDB）会话存储执行只读 SQL 查询，把过去 24 小时的 Copilot 编码会话自动汇总成一份结构化、可分享的每日站立汇报。读完本文，你将掌握 Standup 工作流的完整调用链路、会话存储表结构与跨后端 SQL 方言差异，并能复现/扩展这一自动化汇报流程。

1. 从提示词到技能：chronicle:standup 的完整调用链

在 Positron 仓库的 Copilot 扩展中，站立汇报能力由一个极简的提示词文件触发：chronicle-standup.prompt.md。该文件只有三行核心内容，却精确地定义了 Agent 的行为契约：

--- name: chronicle:standup description: Generate a standup report from recent chat sessions --- Generate a standup report from my recent coding sessions. Use the **chronicle** skill — it documents the `copilot_sessionStoreSql` tool, the session-store schema, and the Standup workflow for summarizing the last 24h of activity from `sessions`, `session_refs`, `turns`, and `session_files`. When you invoke `copilot_sessionStoreSql`, set `subcommand: "standup"` on every call.

从中可以拆出三个关键信息：

1. 触发方式：当用户发出「生成站立汇报 / daily summary / 我今天做了什么」之类请求（例如/chronicle standup）时，Agent 会加载此提示词；
2. 技能依赖：提示词本身不包含任何 SQL 细节，而是把权威知识委托给chronicle技能（SKILL.md），后者完整记录了copilot_sessionStoreSql工具的用法、会话存储表结构以及 Standup 工作流；
3. 遥测契约：每次调用工具时都必须传subcommand: "standup"，该字段用于遥测归因——从工具实现的参数定义（sessionStoreSqlTool.ts）可以看到，subcommand的可选值为'standup' | 'tips' | 'cost-tips' | 'search' | 'improve' | 'reindex'，且只用于 telemetry attribution。

1.1 提示词在扩展中的注册方式

该提示词并不是游离文件，而是通过 package.json 的contributes.chatPromptFiles声明注册：

{ "path": "./assets/prompts/chronicle-standup.prompt.md", "when": "github.copilot.sessionSearch.enabled", "sessionTypes": ["local"] }

两个值得注意的约束：

• when: "github.copilot.sessionSearch.enabled"：只有会话搜索上下文键为 true 时提示词才生效。该上下文键与chat.localIndex.enabled设置联动（见 contextKeys.contribution.ts 与 configurationService.ts，后者将该设置定义为基于实验的配置，默认值为true）；
• sessionTypes: ["local"]：仅面向本地交互式会话。

与它并列注册的还有chronicle-tips、chronicle-cost-tips、chronicle-improve、chronicle-reindex、chronicle-search等提示词（package.json），共同构成完整的 Chronicle 提示词家族；chronicle 技能本身也在 package.json 中以chatSkills形式注册，同样以github.copilot.sessionSearch.enabled为启用条件。

2. 前置条件：让copilot_sessionStoreSql可用

chronicle 技能在 SKILL.md 的开头就给出了硬性前置条件：

Prerequisite:Chronicle requires thegithub.copilot.chat.localIndex.enabledsetting to betrue. If thecopilot_sessionStoreSqltool is not available, tell the user to enable this setting in VS Code Settings.

即：

• github.copilot.chat.localIndex.enabled = true（本地索引开关）：决定本地 SQLite 会话追踪与/chronicle命令是否可用；
• chat.sessionSync.enabled（云同步开关，可受企业策略约束）：决定会话是否可选同步到云端，实现跨设备访问；开启后查询会路由到云端 DuckDB 后端，其中包含所有设备、所有 Agent（VS Code、CLI、Copilot Coding Agent、PR 审查）的完整会话历史。

从源码看，这两个开关的语义在 sessionIndexingPreference.ts 中有明确注释：

• chat.localIndex.enabled（ExP 级设置）——启用本地 SQLite 追踪与/chronicle命令；
• chat.sessionSync.enabled（核心设置，含企业策略）——启用云上传。

而hasCloudConsent()（sessionIndexingPreference.ts）进一步说明：只有当chat.sessionSync.enabled为 true且仓库不在chat.sessionSync.excludeRepositories排除列表（支持 picomatch 通配模式）时，才会把存储级别判定为'user'（云端），否则一律回落为'local'（仅本机）。

3. Standup 工作流三步走

chronicle 技能为 Standup 定义了严格的三步流程（SKILL.md），这也是本文最核心的可执行内容。

3.1 Step 1：抓取最近 24 小时的活动

使用copilot_sessionStoreSql且action: "query"，查询sessions表中updated_at落在最近 24 小时内的行，并按updated_at降序排列。时间窗口谓词因后端而异：

拿到这些 session id 后，再从session_refs拉取关联引用（PR、issue、commit）。只有当某个会话需要更多细节时，才进一步查询turns（以及session_files，云端还有checkpoints）——不要一上来就把每个会话的每一轮对话都倒出来。

技能还专门强调了「不编造」原则：如果 24 小时内没有任何会话，应当直接告知用户没有近期活动可汇报，建议扩大时间窗口或运行/chronicle reindex，然后停止——绝不能虚构一份站立汇报。

3.2 Step 2：纳入没有 PR 的工作

每个近期会话都应被视为候选工作项，即使它没有关联 PR、issue 或 commit。技能明确指出：

PRs are supporting evidence, not the source of truth.

PR 只是佐证，不是事实来源。不能因为某个分支没有 PR 就省略它——应当依据会话摘要（summary）和对话内容（turns）来判断是否纳入汇报。

3.3 Step 3：核对 PR 状态并按工作流分组格式化

对找到的每个 PR 引用，使用 GitHub CLI 或 MCP 工具核对当前状态（open / merged / draft / closed）。每个工作项要么带一行 PR 状态，要么写 "No PR found"——永远不要凭空捏造一个 PR。

输出必须按工作流（分支/功能）分组，并使用以下精确结构：

Standup for <date>: **✅ Done** **Feature name** (`branch-name` branch, `repo-name`) - 3-7 words describing the status - Key files: 2-3 most important files changed - Merged: [#123](https://github.com/owner/repo/pull/123) or No PR found - Session: `full-session-id` **🚧 In Progress** **Feature name** (`branch-name` branch, `repo-name`) - 3-7 words describing the current state of work - Key files: 2-3 most important files being worked on - Draft: [#789](https://github.com/owner/repo/pull/789) or No PR found - Session: `full-session-id`

格式化规则（原文逐条继承）：

• 保持简洁扼要——用户随时可以追问细节；
• 使用对话数据（用户消息和助手回复）理解到底做了什么（WHAT）；
• 使用session_files中的文件路径识别受影响的组件/区域；
• 同一分支上的相关会话合并为一条；
• 每个功能/分支只展示最近的一个会话；
• PR 与 issue 用 Markdown 链接语法；
• 工作看起来已完成归类为 Done，否则归为 In Progress；
• 没有分支或仓库的会话归入 "Other" 分组。

4. 支撑工具：copilot_sessionStoreSql的源码级解析

4.1 工具注册与参数 schema

copilot_sessionStoreSql在 package.json 中声明，工具引用名toolReferenceName为sessionStoreSql，启用条件同样是github.copilot.sessionSearch.enabled。其输入参数完整定义如下：

其中模型可见的modelDescription（SQLite 版）与工具实现里的CLOUD_MODEL_DESCRIPTION（DuckDB 版，sessionStoreSqlTool.ts）相互补充：本地后端用datetime('now', '-1 day')做日期运算、用 FTS5MATCH做全文检索；云端后端用now() - INTERVAL '1 day'、用ILIKE做文本检索。

4.2 只读强制与 SQL 安全防线

工具实现（sessionStoreSqlTool.ts）内置了多层防御，这也解释了为什么 SKILL.md 的 Query Guidelines 会强调「只允许 SELECT 和 WITH」：

1. 阻断危险模式（BLOCKED_PATTERNS）：INSERT/UPDATE/DELETE/DROP/CREATE/ALTER/TRUNCATE/REPLACE、ATTACH/DETACH、PRAGMA（data_version除外）、VACUUM、REINDEX、ANALYZE、LOAD_EXTENSION（SQLite 若开启扩展加载即可执行原生代码，属 RCE 风险）、事务控制语句BEGIN/COMMIT/ROLLBACK/SAVEPOINT/RELEASE；
2. 白名单校验：剥离前导注释（防止用注释前缀走私非查询语句）后，语句必须以SELECT或WITH开头；
3. 单语句限制：sql.includes(';')即拒绝，防止多语句注入；
4. 引擎级兜底：合法查询最终交给ISessionStore.executeReadOnly()执行，该方法在可用时通过setAuthorizer做引擎级只读强制（见 sessionStoreSqlTool.ts）；
5. 结果上限：最多返回MAX_ROWS = 100行，且格式化输出总预算为 30,000 字符（TOTAL_FORMAT_BUDGET），防止撑爆上下文窗口。

上述安全边界均有测试用例固化（sessionStoreSqlTool.spec.ts）：测试逐一验证了DROP TABLE、DELETE、INSERT、UPDATE、ATTACH DATABASE、VACUUM INTO '/tmp/copy.db'（曾报告的真实绕过路径）、load_extension、BEGIN/COMMIT/ROLLBACK、注释前缀走私、EXPLAIN、多语句、空查询等场景全部被阻断，而WITH (CTE)查询可以正常放行。

4.3 查询路由：本地 SQLite 还是云端 DuckDB？

工具根据用户的云同步设置自动路由（sessionStoreSqlTool.ts）：

• 云端已启用：查询发给CloudSessionStoreClient（DuckDB 后端），模型看到的工具描述会通过alternativeDefinition()动态替换为 DuckDB 语法版本（sessionStoreSqlTool.ts）；
• 云端未启用：查询落到本地 SQLite；
• 云端失败回退：若云端鉴权/网络失败，自动回退到本地执行，并在结果中标注source: local_fallback。

因此 SKILL.md 反复强调一条铁律：始终遵循工具描述中展示的 SQL 方言——它与你当前激活的后端一致。

5. 会话存储 Schema 速查表

Standup 工作流的数据来源是会话存储库。chronicle 技能（SKILL.md）给出了完整 schema，核心表如下：

几个容易踩坑的命名约定（SKILL.md 明确警示）：

• sessions主键是id（不是session_id），其他表统一用session_id外键回指sessions.id；
• 不存在started_at（用created_at/updated_at）、不存在workspace（本地用cwd）、不存在title（用summary）、不存在content/messages（用turns.user_message/turns.assistant_response，云端用events.user_content/events.assistant_content）；
• 本地全文检索应走 FTS5 的search_index表并直接SELECT session_id，绝不能把search_index.rowid与turns.rowid做 JOIN——两者相互独立，会拉进无关会话。

6. 查询规范与性能红线

Standup 场景之外的查询同样要遵守 SKILL.md 的通用规范：

• 每次调用只允许一条查询（禁止分号拼接）；
• 只允许SELECT和WITH（CTE）；DESCRIBE、SHOW、PRAGMA及一切变更语句都会被阻断——不要尝试用内省语句探测 schema，直接查阅技能文档；
• 始终使用LIMIT（上限 100），优先聚合（COUNT、GROUP BY）而非裸行转储；
• 时间范围过滤一律用updated_at（不是created_at）；
• 分析会话内容务必 JOINturns，不能只依赖sessions.summary。

针对云端 DuckDB 查询的超时风险（context deadline exceeded），SKILL.md 给出明确的性能纪律：

• ILIKE '%X%'在turns上是全表扫描，建议采用两步模式：先用窄时间窗口 +GROUP BY session_id的 CTE 收集命中会话，再用WHERE id IN (...)从sessions富化，避免大扫描结果的昂贵 JOIN；
• 云端重表默认用7 天窗口，无结果时渐进放宽：7 天 → 30 天 → 90 天；
• 最终 SELECT 保持LIMIT 50；
• 超时后应当收窄窗口或剔除最重的表（通常是turns），不要用同一窗口重试。

7. 与其他 Chronicle 子命令的分工

chronicle:standup只是 Chronicle 技能族的一员，理解分工有助于把握它在整体中的定位：

chronicle-standup与chronicle-search一样，都是「指向技能、让技能承载全部细节」的薄提示词模式——前者在每次调用工具时固定传subcommand: "standup"，后者固定传subcommand: "search"。这种设计把易变的知识（SQL 方言、schema、性能红线）收敛在单一技能文档中，而提示词只承担意图声明与遥测标注职责，值得在自建 Agent 工作流中借鉴。

8. 小结

chronicle:standup代表了 Positron Copilot 扩展中一条完整且克制的自动化链路：薄提示词声明意图 → chronicle 技能提供 schema 与工作流权威知识 →copilot_sessionStoreSql工具以只读 SQL 安全地访问本地/云端会话存储 → 结构化 Markdown 输出。其核心方法论——把 PR 当作佐证而非事实来源、按工作流分组、宁缺毋滥不编造——保证了汇报的真实性与可读性。若要在自己的环境中复现，只需确认github.copilot.chat.localIndex.enabled已开启（必要时开启chat.sessionSync.enabled以获得跨设备、含 token 分析的完整数据），即可通过/chronicle standup体验这一能力；更深入的查询模式、schema 细节与性能纪律，均可直接查阅 chronicle SKILL.md 与工具实现 sessionStoreSqlTool.ts。

• 开发工具
• 代码编辑器
• 数据科学