用两条回归测试复现分组笔记的元信息错位

本文记录一次可重复的开源项目回归测试。代码审阅和行文由AI辅助，结论来自实际运行输出。复现对象是AI办公实践中心的workvault，核对提交为085fcde1bff20b1a4dc132d76bf8d82f7efa6bee；2026年10月19日再次获取远端后，该主分支提交未变。本文未修改项目生产代码，也未断言维护者已经确认或修复。

1. 为什么文件数量正确仍可能存在错误

数据转换工具经常把原始记录渲染为多篇Markdown笔记，并额外生成分组索引。如果后续步骤依赖数组位置把元信息补回笔记，插入索引就可能改变对应关系。只验证“生成了几篇文件”无法发现内容之间的错配。

这次使用两条虚构记录：Alice（id为1）和Bob（id为2），两者均属于A组。正文模板只输出姓名，文件名来自姓名；profile同时声明name与id两个frontmatter字段。测试全部在本地运行，不连接个人云资源、不使用账号凭据。

2. 先设置不分组的对照

第一条用例关闭分组，调用renderSource，再分别寻找notes/Alice.md和notes/Bob.md，使用extractFrontmatter取出元信息，断言两者姓名分别为Alice和Bob。该用例实际通过。

第二条用例只增加groupBy: 'team’和groupTemplate: ‘# Team {{group}} ({{count}})’，其余输入保持一致。这样可以缩小差异，避免同时修改数据、模板和配置而无法定位原因。

核心断言如下：

const alice = notes.find(n => n.path === 'notes/Alice.md');
expect(extractFrontmatter(alice!.content)).toContain('name: Alice');

3. 实际输出

开启分组后，实际得到：

notes/A.md      -> name: Alice, id: 1
notes/Alice.md  -> name: Bob, id: 2
notes/Bob.md    -> 没有frontmatter

组索引拿到了第一位成员的元信息，Alice正文配上了Bob的元信息，末位成员没有对应元信息。Vitest实际汇总为1通过、1失败；失败断言显示预期name: Alice，实际得到name: Bob。这里的失败用例用于证明缺陷，不能写成“测试全部通过”。

4. 沿着对应关系定位

src/core/engine.ts先把分组索引追加进notes，再追加成员笔记。后续补frontmatter的处理却遍历混合后的notes，并使用records[i]取原记录。索引笔记不属于原始成员记录，这两个数组在分组情况下已经长度不同、含义不同。

修复方向是保留明确的数据关联：在渲染成员时直接使用该成员record生成frontmatter，或者将组索引与成员笔记分开处理。组索引应使用自身的组信息。简单跳过第一项也不稳妥，因为可能同时存在多个组索引，索引数量随数据变化。

本文没有提交修复或声称生产环境恢复。维护者仍需决定组索引应包含哪些字段，并验证模板自带frontmatter、多个分组和空记录等分支。

5. 值得保留的回归检查

至少保留两条成员的name和id与正文一致、组索引不携带第一位成员身份、末位成员仍有元信息这三类断言。还应增加多分组和模板自带frontmatter的用例。测试目标应覆盖“数据属于谁”，不能只覆盖“是否生成文件”。

复现仓库：https://gitcode.com/agent-best-practices/workvault

以上仅是指定提交、指定输入下的本地复现；未公开个人数据，未将本地回归结果混同为上游接收、审核或修复结果。