把混乱的报障，变成可查询的证据。

132 条合成工单贯穿 SLA、父事件、诊断、沟通与知识沉淀。这里不是静态作品截图，而是一套可以真实筛选、查询和追溯的支持数据库。

关联业务表9外键 · 约束 · 索引

合成 SQL 工单…读取 D1 / SQLite

只读 SQL 查询…6 类服务端白名单

双运行环境SQLite + D1本地事务 · 线上只读

数据库总览

九张业务表围绕工单建立关系，让支持过程可以被筛选、聚合、复盘与审计。

从业务对象到可查询关系

9 TABLES · RELATIONAL

输入维度

customers客户

sla_policiesSLA 策略

incident_groups父事件

核心事实表客户、事件与严重度外键在这里汇合

过程与产出

ticket_notes结构化笔记

evidence_items证据

ticket_events事件

knowledge_articles知识

audit_logs审计

metadata 只记录种子版本，不计入九张业务表。关系、约束与索引都可以在 database/schema.sql 中复核。

案例数据

在 132 条合成记录中组合筛选，再沿外键查看客户、父事件、证据、沟通、知识与审计。

SQL 查询

36 组查询按 6 类组织；每一组都展示真实 SQL 与当前结果，只运行服务端预审的只读 SELECT。

问数据库

先检索本站工单、知识条目、SQL 诊断和项目文档，再由 DeepSeek 在这组资料边界内回答。

DATABASE LIBRARIAN

只问本站数据库

系统实现

每一项都可在仓库文件或运行接口中复核，不用虚构技术成果。

浏览器 → REST API → SQLite / D1 / DeepSeek

浏览器只负责交互；本地由 Python + SQLite 运行，公开站由 Cloudflare Worker + D1 运行同一组参数化查询。网站管家先检索当前数据与项目文档，再把有限上下文交给 DeepSeek；API Key 不进入浏览器。

01Responsive UIHTML · CSS · JS

02REST APIPython / Worker

03Grounded sourcesSQLite / D1 · Docs · DeepSeek

A

9 张关联表

客户、父事件、SLA、工单、结构化笔记、证据、事件、知识条目与审计日志分别建模。

database/schema.sql

B

参数化 API

严重度、状态与关键词筛选都通过绑定参数执行，避免把搜索值拼进 SQL。

GET /api/tickets

C

事务与审计

推进工单阶段时，同一事务更新状态、写入事件，并留下 before / after 审计记录。

POST /api/tickets/:id/advance

D

36 组只读诊断

六类诊断场景由服务端白名单选择，本地 SQLite 与云端 D1 都只接受预审的 SELECT。

SERVER-SIDE SELECT ALLOWLIST

E

迁移边界

附 MySQL 8 表结构草案，但本地未安装 MySQL，因此明确标记为未运行验证。

database/mysql/schema.sql

F

隐私边界

48 个租户名、132 条工单、日志和数值均为合成数据；仓库有独立隐私扫描与来源说明。

docs/synthetic-data-provenance.md

G

有依据的 AI

模型只接收当前问题、有限历史和服务端检索片段；回复附结构化来源，资料不足时不允许自由补写。

POST /api/librarian/chat