DadaoTask

26 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
dadao	a24a493403	feat(rich): 备注/工单说明/知识正文支持 Markdown 与图片附件写一件事的时候，光有纯文本不够：要贴截图、要分段、要标重点。这次把「正文」这条路补全，思路是存 Markdown 而不是 HTML—— 能导出、能全文检索、能直接喂给 LLM，也不必每次渲染都重新清洗一遍 HTML。后端 - attachment 表 + RLS + 迁移 0005；本地磁盘存储，key 由内容 sha256 决定，换对象存储只改 services/storage.py 一个文件 - 上传在读流时卡 20MB，不先落盘再判断；磁盘名由服务端生成，用户文件名只进库和响应头 - 列表带 attachment_count、详情带 attachments，避免一屏 N 次请求 - raw 直链给 <img src> 用（图片带不了 Authorization 头），只允许本工作区成员，非成员一律 8001 不区分「不存在」与「没权限」 - 5 个用例：上传下载、超限、跨租户、删除确认与权限、raw 鉴权前端 - 自研零依赖 Markdown 渲染器：先转义再上标签，链接协议白名单 - RichTextEditor：工具栏 + Ctrl+B/I + 预览，粘贴或拖入图片自动上传并插入引用 - AttachmentPanel：上传/下载/删除，下载走带 Authorization 的 fetch 转 blob - 任务备注、工单说明与验收结论、知识正文、评论全部接入顺手修的 - TaskDetail.hydrate 漏了 setAttachments，导致附件面板永远是空的（e2e 抓到的） 71 passed；web tsc 0 错、构建 255.07 kB │ gzip 80.85 kB； e2e：richtext 9 项 + smoke 7 + tickets 8 + knowledge 7，全绿。	2026-10-29 01:53:46 +08:00
dadao	0919c8ecd3	fix(knowledge): 草稿的过程段写「收件箱 → 待办」，而不是两句「状态变更」 CI / backend (push) Canceled after 0s Details 自动生成的草稿里，时间线只查了 activity.action，没带 payload，于是每条状态变化都变成一模一样的「状态变更」，读者看不出事情怎么走的。 - services/knowledge.snapshot_source 多取 Activity.payload 一起交给渲染 - domain/knowledge 加 STATUS_LABEL 与 _describe()，把 payload 的 from/to 翻成人话 - 新增用例断言草稿里有「待办 → 进行中」「进行中 → 已完成」 66 passed。	2026-10-28 14:14:50 +08:00
dadao	e9addeed25	feat(knowledge): 工单验收自动生成草稿，核对后发布，来源可追 - knowledge_doc 与 item 1:1，除 source_kind=manual 外必须有来源（库级约束） - 状态机 draft/in_review/published/archived，发布要 owner/admin；非法动作回 allowed_from 与 allowed_actions - 工单验收通过自动落 postmortem 草稿（generated_by=rule），同一来源只生成一次 - 接口：列表/详情/手记/改内容/状态动作/从事项沉淀；已发布禁改，改内容带乐观锁 - Web 知识页 + 详情抽屉；任务与工单详情里可「沉淀成知识」 - 8 个后端用例 + e2e 7 项断言（沉淀 → 待核对 → 发布）	2026-10-28 14:02:35 +08:00

Author

SHA1

Message

Date

dadao

a24a493403

feat(rich): 备注/工单说明/知识正文支持 Markdown 与图片附件

写一件事的时候，光有纯文本不够：要贴截图、要分段、要标重点。
这次把「正文」这条路补全，思路是**存 Markdown 而不是 HTML**——
能导出、能全文检索、能直接喂给 LLM，也不必每次渲染都重新清洗一遍 HTML。

后端
- attachment 表 + RLS + 迁移 0005；本地磁盘存储，key 由内容 sha256 决定，
  换对象存储只改 services/storage.py 一个文件
- 上传在**读流时**卡 20MB，不先落盘再判断；磁盘名由服务端生成，用户文件名只进库和响应头
- 列表带 attachment_count、详情带 attachments，避免一屏 N 次请求
- raw 直链给 <img src> 用（图片带不了 Authorization 头），只允许本工作区成员，
  非成员一律 8001 不区分「不存在」与「没权限」
- 5 个用例：上传下载、超限、跨租户、删除确认与权限、raw 鉴权

前端
- 自研零依赖 Markdown 渲染器：先转义再上标签，链接协议白名单
- RichTextEditor：工具栏 + Ctrl+B/I + 预览，粘贴或拖入图片自动上传并插入引用
- AttachmentPanel：上传/下载/删除，下载走带 Authorization 的 fetch 转 blob
- 任务备注、工单说明与验收结论、知识正文、评论全部接入

顺手修的
- TaskDetail.hydrate 漏了 setAttachments，导致附件面板永远是空的（e2e 抓到的）

71 passed；web tsc 0 错、构建 255.07 kB │ gzip 80.85 kB；
e2e：richtext 9 项 + smoke 7 + tickets 8 + knowledge 7，全绿。

2026-10-29 01:53:46 +08:00

dadao

0919c8ecd3

fix(knowledge): 草稿的过程段写「收件箱 → 待办」，而不是两句「状态变更」

CI / backend (push) Canceled after 0s

Details

自动生成的草稿里，时间线只查了 activity.action，没带 payload，
于是每条状态变化都变成一模一样的「状态变更」，读者看不出事情怎么走的。

- services/knowledge.snapshot_source 多取 Activity.payload 一起交给渲染
- domain/knowledge 加 STATUS_LABEL 与 _describe()，把 payload 的 from/to 翻成人话
- 新增用例断言草稿里有「待办 → 进行中」「进行中 → 已完成」

66 passed。

2026-10-28 14:14:50 +08:00

dadao

e9addeed25

feat(knowledge): 工单验收自动生成草稿，核对后发布，来源可追

- knowledge_doc 与 item 1:1，除 source_kind=manual 外必须有来源（库级约束）
- 状态机 draft/in_review/published/archived，发布要 owner/admin；非法动作回 allowed_from 与 allowed_actions
- 工单验收通过自动落 postmortem 草稿（generated_by=rule），同一来源只生成一次
- 接口：列表/详情/手记/改内容/状态动作/从事项沉淀；已发布禁改，改内容带乐观锁
- Web 知识页 + 详情抽屉；任务与工单详情里可「沉淀成知识」
- 8 个后端用例 + e2e 7 项断言（沉淀 → 待核对 → 发布）

2026-10-28 14:02:35 +08:00