图中是项目设计稿，包含用于说明交互的示例数据，不代表真实业务运行数据。
它解决的不是“少一个笔记软件”
我的日常工作横跨软件、硬件与结构。代码有提交记录，电路和结构有版本文件，测试过程有截图、表格和日志，现场结论还可能只留在一段临时消息里。每一种资料都有地方可放，但它们经常失去共同的上下文：属于哪个项目、对应哪次验证、为什么改、后续还剩什么。
火阳 的第一版只做几件事：选择项目，写下一条记录，附上文件或截图，再把下一步变成待办。实际用起来以后，需求自然向外生长。记录需要搜索和筛选，文件需要归档与预览，待办需要子任务和时间计划，误删需要回收站，频繁切窗口又催生了悬浮快捷记录。
我没有把这些功能拆成互不相干的小工具。项目是主索引，文本、附件、待办、资料目录和统计都沿着这个索引组织。这样回看某个硬件版本或结构变更时，不必先回忆信息究竟落在哪个应用里。
从入口到资料库
当前桌面端以 Python 3 和 PyQt5 为主运行线。主窗口负责项目导航、全局搜索、拖放、托盘和提醒；记录页承载项目空间、待办、附件、资料库与时间线；独立便签适合尚未归档的想法；统计页负责从项目和时间两个维度复盘；设置页集中处理存储、备份、恢复和连接项。
悬浮窗是一次很实际的取舍。工程过程中最容易丢的不是长文，而是一句话、一个文件路径、一张截图和一个“稍后检查”。窗口保持轻量，只负责快速进入；复杂整理仍回到主界面。这样既减少打断，也避免把所有能力塞进一个小窗口。
本地优先，不等于只有本机能用
项目现在以 SQLite 为主存储，并启用 WAL、synchronous=FULL、外键检查、10 秒 busy timeout 和启动时 quick_check。旧 JSON 数据会在校验后迁移，备份恢复仍保留兼容路径。这里的重点不是追求复杂架构，而是让桌面工具在突然退出、重复打开和版本迁移时仍有明确行为。
局域网能力则放在独立 API 层。当前实现覆盖健康检查、项目和待办读取、幂等创建、签名 Webhook、SSE 实时通知，以及手机浏览器的报销录入入口。网络访问必须显式开启，并检查访问令牌、私有网段、CORS、请求体大小和可选 TLS。仓库里的 OpenAPI 文档定义了 48 个路径模板、68 个操作，那是后续设计面，不是已经全部落地的接口数量。
三种工程角色怎样落在一个项目里
软件
桌面交互、数据一致性、API、自动化测试、日志与 Windows 打包。
硬件
按设备项目保存测试资料、原理图说明、BOM、日志、样机照片与验证结论。
结构
围绕版本记录 CAD/图纸、装配问题、外观确认、材料与供应链待办。
火阳 本身是软件项目，但它的结构来自跨域工程现场。工具并不替代专业 CAD、EDA 或代码仓库，它负责把这些专业工具留下的证据重新放回同一个项目进程中。
当前状态
本次整理对 D:\Pre_project\Project\data 做了只读审计。当前 main 分支有 167 次提交，仓库可见历史从 2026 年 7 月 21 日到 7 月 28 日；之后的 SQLite、API、报销、导出与打包工作仍有相当一部分留在工作树中。因此，这篇文章只把 7 月 28 日以前写作“Git 历史”，后面的内容统一称为“当前工作树中的后续开发”。
下一阶段不会继续堆按钮。我更关心三个问题：备份能否离机恢复，局域网能力能否继续收紧边界，复杂记录页能否在数据量增长后仍保持响应。等这些问题有了新的验证结果，我会继续把过程和失败记录补进来。
评论区