72 lines
4.3 KiB
Markdown
72 lines
4.3 KiB
Markdown
## ADDED Requirements
|
||
|
||
### Requirement: 扫描并识别待处理文件
|
||
系统 SHALL 扫描项目 `sources/` 目录下的所有文件，并根据扩展名判断解析方式：
|
||
- Office 文档（.docx、.pdf、.pptx、.xlsx）：调用 lyxy-reader-office skill 解析
|
||
- 其他文件（.md、.txt、.csv、.json、.xml、.yaml、.yml、.log、.html 等）：直接读取内容
|
||
|
||
#### Scenario: sources 中有 office 文档
|
||
- **WHEN** sources/ 中存在 `报告.docx`
|
||
- **THEN** 系统 SHALL 使用 lyxy-reader-office skill（通过 lyxy-runner-python 执行）将其解析为 markdown
|
||
|
||
#### Scenario: sources 中有纯文本文件
|
||
- **WHEN** sources/ 中存在 `config.json`
|
||
- **THEN** 系统 SHALL 直接读取文件内容作为 parsed 产物
|
||
|
||
#### Scenario: sources 目录为空
|
||
- **WHEN** sources/ 中没有任何文件
|
||
- **THEN** 系统 SHALL 提示用户 sources/ 中无待处理文件
|
||
|
||
### Requirement: 同名不同扩展名冲突检测
|
||
系统 SHALL 在解析前检测 sources/ 中是否存在同名但不同扩展名的文件（如 `技术方案.pdf` 和 `技术方案.docx`），因为 parsed 产物都会命名为相同的 `.md` 文件。同时也需检测 sources/ 中的文件名是否与 manifest.json 中已有记录的不同扩展名文件冲突。
|
||
|
||
#### Scenario: sources 中存在同名不同扩展名文件
|
||
- **WHEN** sources/ 中同时存在 `技术方案.pdf` 和 `技术方案.docx`
|
||
- **THEN** 系统 SHALL 拒绝处理这两个文件，并提示用户重命名其中一个以消除冲突
|
||
|
||
#### Scenario: sources 中文件与已入库文件同名但不同扩展名
|
||
- **WHEN** manifest.json 中已有 `技术方案`（ext: `.pdf`）的记录，且 sources/ 中出现 `技术方案.docx`
|
||
- **THEN** 系统 SHALL 拒绝处理该文件，并提示用户重命名
|
||
|
||
### Requirement: 生成 parsed markdown 文件
|
||
系统 SHALL 将解析后的内容写入 `parsed/<文件名>.md`，文件头部 MUST 包含元信息注释：
|
||
```
|
||
<!-- source: <原始文件名含扩展名> -->
|
||
<!-- archived: archive/<文件名_时间戳>.<扩展名> -->
|
||
<!-- parsed_at: <解析时间 YYYY-MM-DD HH:mm> -->
|
||
```
|
||
若 parsed/ 中已存在同名文件（同一文档的更新版本），SHALL 覆盖旧文件。
|
||
|
||
#### Scenario: 首次解析文件
|
||
- **WHEN** 解析 `需求文档.docx`，parsed/ 中不存在 `需求文档.md`
|
||
- **THEN** 系统创建 `parsed/需求文档.md`，头部包含 source、archived、parsed_at 元信息，正文为解析后的 markdown 内容
|
||
|
||
#### Scenario: 更新已有文件
|
||
- **WHEN** 解析 `技术方案.pdf`，parsed/ 中已存在 `技术方案.md`（上一版本）
|
||
- **THEN** 系统覆盖 `parsed/技术方案.md`，元信息更新为最新版本的 archive 路径和时间
|
||
|
||
### Requirement: 归档原始文件
|
||
系统 SHALL 将已解析的原始文件从 `sources/` 移动到 `archive/`，文件名格式为 `<文件名_YYYYMMDDHHmm>.<扩展名>`。每个进入 archive 的文件都 MUST 带有时间戳后缀，即使该文件只有一个版本。
|
||
|
||
#### Scenario: 归档文件
|
||
- **WHEN** `需求文档.docx` 解析完成，当前时间为 2026-02-18 16:00
|
||
- **THEN** 原始文件移动为 `archive/需求文档_202602181600.docx`
|
||
|
||
#### Scenario: 同名文件多次入库
|
||
- **WHEN** `技术方案.pdf` 第二次入库，archive 中已有 `技术方案_202602181600.pdf`
|
||
- **THEN** 新版本归档为 `技术方案_202602181725.pdf`（以当前时间为时间戳），两个版本并存于 archive
|
||
|
||
### Requirement: 更新 manifest.json
|
||
系统 SHALL 在每个文件处理完成后更新 manifest.json：
|
||
- 新文件：在 files 数组中追加新条目，包含 name、ext、parsed 路径，versions 数组包含首个版本的 archived 路径、hash 和 ingested_at
|
||
- 已有文件更新：在对应条目的 versions 数组中追加新版本记录
|
||
- last_ingest 时间戳 SHALL 更新为当前 ingest 的时间
|
||
|
||
#### Scenario: 新文件入库更新 manifest
|
||
- **WHEN** `需求文档.docx` 首次解析完成
|
||
- **THEN** manifest.json 的 files 数组中追加 `{"name": "需求文档", "ext": ".docx", "parsed": "parsed/需求文档.md", "versions": [{"archived": "archive/需求文档_202602181600.docx", "hash": "sha256:...", "ingested_at": "2026-02-18T16:00"}]}`
|
||
|
||
#### Scenario: 已有文件更新 manifest
|
||
- **WHEN** `技术方案.pdf` 第二次入库
|
||
- **THEN** manifest.json 中该文件条目的 versions 数组追加新版本记录，不删除旧版本记录
|