Work Summary
这次窗口期的工作非常集中，核心在三个项目：static-project、any2text、rsspulse。最重的投入在 static-project 的 md2pdf 预览链路，你连续围绕代码块字号、行距、全局字体大小、动态调节、实时预览、刷新持久化、彩色/黑白适配反复回捞问题，说明你已经不满足于“参数能改”，而是在追“预览结果、持久化状态、最终导出语义”三者一致。
第二条主线是容器化项目的运行边界梳理。openclaw 相关问题集中在插件安装命令、容器内入口、版本判断、docker-compose 所在位置和更新方式；rsspulse 则暴露出运行环境认知与真实页面验证之间的脱节。你关心的不是命令会不会跑，而是镜像、容器、宿主机和发布入口之间到底谁负责什么。
第三条主线是 any2text 的质量门禁补齐。你直接把问题压到 Dockerfile、pytest、mypy、Makefile、ADR、README、CSS lint 这些交付边界上，方向是对的：把“能开发”推进到“能长期维护”。这说明你对工程化收口很敏感，但也暴露出门禁常常在后段才被补进来，而不是在项目骨架阶段一次性立住。
Improvement Areas
1. 前端设置状态需要单一事实源
现象：static-project 里同一批需求被反复打回，症状包括设置按钮缺失、参数调了预览不变、刷新后配置丢失、彩色切换无效。
根因：设置值、预览渲染值、持久化值不是同一个状态源，UI 交互和导出链路缺少显式契约，导致看似改了参数，实际没有打通到最终渲染结果。
行动项：
- 把“设置面板状态、预览状态、导出状态”收敛成一个配置模型，禁止各自维护影子状态。
- 为字号、行距、彩色模式、持久化恢复建立最小不变量，用真实预览断言覆盖。
- 所有设置项先定义默认值、存储键、渲染映射，再进 UI 实现。
2. 验证方式必须从口头确认升级为证据确认
现象：你多次要求“自己用浏览器打开看”“使用 CDP”“做截图级验证”，并直接质疑“你怎么做的校验”，说明现有验证停留在开发者主观判断。
根因：功能完成标准没有绑定到可观察证据，导致实现方容易用代码路径替代真实结果，用局部渲染替代整链路验证。
行动项：
- 为视觉与交互改动建立固定验收序列：状态变更、预览更新、刷新恢复、导出结果、截图留证。
- 对高风险 UI 改动默认做 CDP 或可重复截图校验，不再接受“理论上应该生效”。
- 把验收截图或关键观察写进提交说明或 ADR，避免同类回归重复争论。
3. 容器运行边界需要显式化，而不是靠现场猜
现象：你连续追问 openclaw 插件命令为何不存在、Docker 安装是否正常、最新版本、docker-compose 在哪里，以及 rsspulse 在 Docker 内启动后的更新路径。
根因：项目把“镜像构建期、容器运行期、宿主机编排期”的职责混在一起，没有把入口命令、升级路径、插件安装方式、持久化目录和服务归属写清楚。
行动项：
- 每个容器化项目都补一份最小运行手册：compose 文件位置、服务名、卷、入口命令、升级命令、诊断命令。
- 区分“镜像里没有这个命令”和“命令在别的容器/宿主机执行”两类问题，先画边界再排障。
- 更新操作一律收敛到单入口，避免一会儿
docker exec，一会儿手动进容器，一会儿改 compose。
4. Python 项目的质量门禁应该在骨架阶段立住
现象：any2text 里 pytest 缺失、mypy 缺位、Makefile target 不完整、README/ADR/CSS lint 需要后补，说明门禁是被需求推着补的。
根因：项目模板没有把“容器内测试可执行、类型检查可执行、文档边界可追踪”作为初始约束，导致后期补门禁时成本上升，还容易和实际运行环境脱节。
行动项：
- 新 Python 项目默认内置
make test、make lint、make typecheck，并保证容器内外行为一致。 - 先给核心模块做 strict typing，外围模块渐进推进，避免一次性铺太大。
- ADR 不只记录架构，也记录为何设置这些质量门禁，防止后续被删弱。
Strengths
- 问题追打能力强：你不会接受“看起来修了”，会把问题追到预览、持久化、导出和真实页面验证全部闭环。
- 跨层切换快：能在 UI 参数、Docker 编排、类型系统、README/ADR 之间快速切换，而且关注点始终落在交付边界。
- 工程收口意识明确：在
any2text上主动把注意力拉回 Makefile、Dockerfile、测试、类型检查和 ADR，这比单纯堆功能更有价值。
Action Items
- P0 - 为
static-project建立统一配置模型与预览不变量 → 产出设置项 schema、持久化键表、截图级验收用例。 - P0 - 为
openclaw/rsspulse补齐容器运行手册 → 产出单入口升级与排障文档，消除执行位置歧义。 - P1 - 为 Python 工具项目固化质量门禁模板 → 产出可复用的 Makefile、mypy 配置、容器测试基线。
- P1 - 把“真实验证”前置到完成定义 → 产出一份 UI/页面改动验收 checklist，并要求证据留档。
Tech Trends
今日 HackerNews 热门技术话题精选。
1. Agent Safehouse – macOS-native sandboxing for local agents
Points: 318 | Comments: 76
这篇文章主张把本地 agent 的安全边界前置到内核层，而不是依赖提示词或人工小心。核心观点很直接：LLM 失误不是会不会发生，而是何时发生，所以最小权限和默认拒绝必须变成系统能力。
技术实现上，它用单脚本封装 sandbox-exec，默认只给当前项目目录读写、工具链只读，其余如 SSH 密钥、云凭证和其他仓库一律拒绝。对做自动化、SecOps 和本地 agent 开发的人，这类方案的价值不在“更方便”，而在把误读敏感文件这类事故变成内核级不可达。
Key Takeaways:
- 对 agent 来说，权限模型比提示词约束更可靠。
- 开发环境也应采用 deny-by-default，而不是信任用户习惯。
2. Notes on writing Rust-based Wasm
Points: 202 | Comments: 90
文章把 Rust/Wasm 边界看成两套内存模型和对象生命周期的接口设计问题，而不是语法糖问题。重点不是“能不能导出”，而是接口命名、引用语义、可变状态承载方式这些细节决定了系统是否稳定。
作者建议导出类型和导入接口命名分层、默认按引用传递、少碰 &mut，并用 Rc 或 Arc 管理状态，同时把 Rust 错误显式转成 JS Error。这对跨语言边界设计很有启发：真正昂贵的通常不是一次引用计数，而是边界不稳带来的排障成本。
Key Takeaways:
- 跨语言接口先设计语义边界，再谈性能细枝末节。
- 可诊断性和稳态 API 往往比微观优化更值钱。
3. My Homelab Setup
Points: 143 | Comments: 120
作者把旧游戏 PC 改造成家用服务器，目标不是炫技，而是用最直接的方式解决照片存储、快照恢复和异地备份问题。文章可贵之处在于没有把自托管浪漫化，而是把冗余、恢复和远程访问当成基本盘。
方案上使用 TrueNAS、双 8TB RAID 1、分层快照、Backrest 配合 Backblaze B2 做云备份，再用 Tailscale 提供远程访问。对 DevOps 的启示很明确：哪怕是个人场景，系统也要围绕“可恢复、可替换、最小暴露面”来建，而不是围绕“先跑起来”来建。
Key Takeaways:
- 自托管的核心不是部署成功，而是故障后还能恢复。
- 备份、快照和远程访问边界应该一开始就设计进去。
4. We should revisit literate programming in the agent era
Points: 129 | Comments: 71
作者认为，文学化编程过去难落地，是因为代码和说明要双重维护；但在 agent 时代，模型可以同步更新 prose、代码和 tangle 流程，这个历史包袱突然变轻了。文档不再只是事后补写，而可能重新变成“与实现同源”的工程资产。
文章把 runbook、手工测试步骤、解释文本和可执行代码放进同一文档，让审阅、执行、记录一次完成。对日常开发很有启发：很多“写文档太慢”的痛点，本质是同步成本高；如果 agent 能承担同步劳动，docs-first workflow 会重新变得务实。
Key Takeaways:
- agent 擅长把说明、代码和执行记录维持在同一上下文里。
- 运行手册和测试步骤可以重新成为一等源码资产。
5. Log messages are mostly for the people operating your software
Points: 108 | Comments: 56
这篇文章的关键提醒是：日志首先是给运维者看的，不是给写代码的人自我安慰的。很多日志语句在开发者脑中上下文完整时很自然，但一旦进入生产环境，就只剩下模糊、不可操作的碎片。
它要求你在写非 debug 日志前先回答一个问题：运行系统的人从这条消息里能得到什么。这个视角对后端系统特别重要，因为真正影响 MTTR 的往往不是有没有日志，而是日志能不能支撑定位、归因和行动。
Key Takeaways:
- 日志的评价标准是可操作性，不是“我当时想表达什么”。
- 面向运维者设计日志，才能真正缩短排障链路。
6. LibreOffice Writer now supports Markdown
Points: 280 | Comments: 49
LibreOffice 26.2 的亮点不只是版本更新，而是把 Markdown 导入导出正式纳入文档工作流，同时继续提升复杂文档性能与兼容性。这说明传统文档工具也开始承认纯文本协作是长期趋势，而不是开发者的小众偏好。
对日常工程文档和内容生成工具来说，这类变化很实际：Markdown 不再只适合仓库内阅读，它与办公套件的互通正在变强。做 md2pdf、报告生成、知识归档这类工具时，文本格式兼容性会越来越重要。
Key Takeaways:
- Markdown 正在从开发格式扩展成跨工具文档底座。
- 文档系统的竞争点正在回到性能、兼容性和长期可移植性。
Learning Resources
预览校验与状态持久化
- Lost Pixel – open-source visual regression testing for your frontend
- Using Python and Selenium for automated visual regression testing
- Show HN: Playwright Recorder v1.3.0 – Session Persistence and Network Recording
容器运行边界与自托管
- My Homelab Setup
- Best practices around creating production ready web apps with Docker Compose
- Agent Safehouse – macOS-native sandboxing for local agents
Python 类型门禁与工程化
- Mypy – Optional Static Typing for Python
- Mypy: Optional static typing for Python
- Guido presents static typing for Python using MyPy