本地健康导出字段校验 CLI

这个小工具的目标很简单：在本地检查 JSON 健康导出文件，如果包含接收者未请求的字段，就拒绝通过（fail closed）。它不解析医疗数据，不上传任何内容，是一个介于「导出完成」和「文件共享」之间的窄范围预检。触发背景是 OpenAI 于 2026 年 7 月 23 日宣布的 Health in ChatGPT 产品推送，面向美国 18 岁以上已登录用户（网页与 iOS），支持连接病历和 Apple Health，可查看化验、药物、活动、睡眠等信息。OpenAI 称连接数据与相关对话不会用于基础模型训练或广告定向。

该验证器使用白名单（allowlist）而非黑名单（denylist）来规避意外泄露——黑名单只检查已知敏感键，而白名单要求每披露字段都经过审批，能捕获源设备、原始记录 ID、时区等隐藏元数据。下面是一个示例实现（Python 3 脚本，作为 validate_export.py 保存）：

```python
#!/usr/bin/env python3
import argparse, json, sys
from pathlib import Path

ALLOWED = {"subject", "type", "day", "value"}
FORBIDDEN = {"name", "email", "address", "phone", "notes"}

def check(path: Path):
errors = []
for number, raw in enumerate(path.read_text().splitlines(), 1):
try:
row = json.loads(raw)
except json.JSONDecodeError as exc:
errors.append(f"line {number}: invalid JSON ({exc.msg})")
continue
keys = set(row) if isinstance(row, dict) else set()
extra = keys - ALLOWED
found = keys & FORBIDDEN
if not isinstance(row, dict):
errors.append(f"line {number}: object required")
if extra:
errors.append(f"line {number}: unexpected={sorted(extra)}")
if found:
errors.append(f"line {number}: forbidden={sorted(found)}")
return errors

p = argparse.ArgumentParser()
p.add_argument("file", type=Path)
args = p.parse_args()
problems = check(args.file)
print("REJECT" if problems else "ACCEPT")
for problem in problems:
print(problem, file=sys.stderr)
raise SystemExit(bool(problems))
```

使用方法：python3 validate_export.py export.ndjson。如果文件中出现 "notes":"call after lunch" 这样的字段，会同时报出 unexpected 和 forbidden 两种错误并退出。

分享前建议增加三个低成本检查：随机浏览十行并统计总行数；通过带外方式确认目的地和删除日期；从允许字段生成新文件，而非原地修改原文件。该工具仅校验顶级键名，无法检测允许字符串内隐藏的标识值、链接攻击、畸形日期、重复行或重识别风险。OpenAI 描述的健康体验为「支持」，不替代医疗诊断或治疗；本地 schema 校验的作用更小：只能减少意外泄露，不能判断数据的准确性、必要性或临床意义。

#开发者 #工具 #CLI #Python #隐私 #OpenAI #ChatGPT #Health #数据校验
@DevToolboxHub

用Python实现健康记录数据最小化过滤器

OpenAI 在 2026 年 7 月 23 日宣布 ChatGPT Health 功能，覆盖符合条件的美国用户（18 岁以上，登录后使用网页或 iOS），可连接病历和 Apple Health，仪表盘展示化验、用药、活动、睡眠等信息。OpenAI 称已连接数据和相关对话不用于训练基础模型或定向广告。

这篇教程用一个迷你 Python 程序演示“数据最小化”——如何让程序证明一个目的只接收原记录中的部分字段。例如，输入包含 date、steps、sleep_minutes、medication、note，但 activity_summary 目的只应得到 date 和 steps。

代码使用 Python 3.11+ 和标准库，定义 POLICY 字典映射目的到允许字段。minimize 函数对未知目的抛出 ValueError（fail-closed），而非返回全部字段。测试用例验证精确输出、输入不被修改、未知目的失败闭合。建议先测试异常输入（如拼写错误的目的名），确保断言能检测多余字段。

本练习只处理扁平字典，不处理值清洗、嵌套临床格式、匿名化、文件安全或集成任何已发布服务。示例数值纯属虚构，无医学意义。切勿未经完整的隐私与安全审查就用于生产健康数据控制。

#开发者 #工具 #Python #数据最小化 #隐私 #OpenAIHealth #ChatGPTHealth #单元测试
@DevToolboxHub

DeepDoc：离线解析文档为Markdown的单二进制工具

在构建RAG管道或搜索功能时，从docx、pdf等文件中提取文本总是一道绕不开的槛。现有方案要么依赖JVM（Apache Tika），要么需要Python环境及模型下载（unstructured、Docling），要么得上传云端（LlamaParse）。DeepDoc提供另一种选择：一个静态Rust二进制，无JVM、无Python、无模型下载、不连网，单文件即可运行。

> DeepDoc将每种格式解析为统一的文档模型（标题、段落、列表、表格、元数据、页码），再序列化为Markdown或JSON。v0.1支持13种原生数字格式：docx、pptx、xlsx、odt、ods、odp、epub、html、rtf、csv、md、txt及纯文本PDF。递归处理文件夹，输出保持目录结构。
>
> 对于RAG场景，DeepDoc按块边界切分，同时保留标题层级路径和字节范围作为元数据，确保检索时上下文不丢失。非OCR工具，扫描PDF会被检测并报错退出（返回码4），避免污染索引。也可作为Rust库使用，直接嵌入服务。
>
> 示例：deepdoc report.docx 直接输出带表格的Markdown；deepdoc ./docs --recursive -o out/ 批量处理并镜像目录。

DeepDoc是本地优先、轻依赖的工具链（DeepLab系列）之一，开源（MIT / Apache 2.0），v0.1已发布。

GitHub

#开发者 #工具 #DeepDoc #Rust #RAG #文档解析 #离线 #开源
@DevToolboxHub

APRF: AI生产就绪的硬门控框架

大多数团队把LLM功能当落地页来发布——合并PR、看演示、庆祝，然后现实打脸：提示注入泄露客户CRM、编码Agent提交密钥、支持机器人虚构退款导致诉讼、遗忘的API密钥一夜烧掉$82k。这些失败并非模型不够聪明，而是生产系统缺少生产门控。APRF是一个门控的、机器可读的生产就绪框架，提供代码、YAML门控和CI，本周就能接上。

APRF不是认证、不是合作伙伴网络、不是给董事会的0–100“就绪分数”。它是必过式方法论：强制检查要么通过，要么阻止发布。推荐控制从不平均进入门控。核心原则：门控结果 = ALL(强制检查通过) — 一项失败即阻断；能力 = 各支柱最小值 — 不允许平均分掩盖弱点。当前版本v0.10包含8个域（安全、安全、数据、模型生命周期、Agent、可靠性、成本、治理）、27个支柱、核心配置41个门控（Tier‑2）、受控配置61个门控（Tier‑3/合规系统），以及RAG、Agent、语音、编码Agent等附加透镜。机读规范与自证声明JSON均可获取。附完整实现示例：TypeScript工具白名单+模式验证、Python不可绕过的审批、YAML策略包（与app版本绑定）、GitHub Actions门控CI（检查证据文件存在性）、以及自证声明JSON模板。一个门控失败即阻止发布，没有“87%就绪”。

适合正在交付Agent、RAG、语音、编码助手的工程师，平台/MLOps团队厌倦了“我们很小心”的模糊说法，安全人员需要能映射到测试和配置的AI控制。APRF不会给你“对所有都合规”的徽章——这正是它的价值所在。贡献与讨论通过公开RFC进行。

#开发者 #工具 #APRF #StackRail #LLM #AI安全 #生产就绪
@DevToolboxHub

三款Chrome扩展提升开发工作流

一位开发者注意到日常工作中的三个小痛点——在随机网站上粘贴JSON格式化、复制JWT到jwt.io调试、切换到字符计数网站检查字数——于是花几个周末构建了三个Chrome扩展来解决它们。

PayloadPeek
JSON格式化工具，支持折叠语法高亮树、一键生成TypeScript接口、从JSON结构推断SQL schema（CREATE TABLE）、Ctrl+F搜索、点击复制任意值。最实用的功能是TypeScript Generator，处理陌生API时无需手写接口。

BearerPeek
JWT解码器，附带安全分析面板：标记缺失exp声明（永不过期）、缺失aud声明（任何服务可接受）、算法设为"none"、过期的token及精确过期时长。自动扫描当前页面中JWT格式的字符串，在DevTools查看请求时可预填token。

TextPeek
字符和字数计数器，支持平台感知的限制：Twitter 280、LinkedIn 3000、Meta描述160、YouTube标题100等。选中任意网页文本右键即可看到即时计数，无需打开任何窗口。

构建经验
Manifest V3对权限非常严格：因请求未使用的tabs、scripting权限被拒两次，因从CDN加载highlight.js被拒一次。MV3下所有JS必须本地打包，不能加载外部脚本。首次提交通常被拒，但拒绝邮件具体可操作，仔细阅读并修复即可。构建三个小东西比一个大东西好：每个扩展专注一件事，Chrome商店列表更清晰、权限理由更简单、用户信任更高。本地处理是真正的差异点——“数据不离开浏览器”是开发者关心的，尤其对JWT token和API响应。所有扩展均使用Claude Code作为pair programmer，在周末全职工作之余开发。

作者将这些扩展放在ShipNano品牌下，计划持续推出小型专注工具。

#开发者 #工具 #PayloadPeek #BearerPeek #TextPeek #Chrome扩展 #ShipNano #JSON #JWT #字符计数
@DevToolboxHub

Vault：浏览器端的投资组合风险追踪器

大多数散户用电子表格或免费App管理投资，只能看到总价值和每日变动，看不到年化波动率、夏普比率、市场贝塔、最大回撤、持仓相关性等核心风险指标。机构投资者用了几十年的东西，散户只能看饼图。

Vault 是一个开源的投资组合追踪器，基于 React 19 和 Vite 构建，通过 EODHD API 获取实时市场数据，在浏览器本地计算六项指标：收益（对比标普500）、分散度（HHI指数）、风险（年化波动率、夏普比率、95% VaR）、回撤（最大回撤曲线）、相关性（皮尔逊矩阵）和行业敞口（GICS细分）。不设后端，不存账户，持仓数据仅保存在 localStorage，不上传任何第三方服务器。

所有数学计算集中在单个文件 src/utils/finance.js，不依赖外部统计库，从零实现时间加权收益、波动率、夏普比率、贝塔、回撤、相关性矩阵和集中度指数。这些公式并不神秘，大多数付费工具只是把它们锁在付费墙后。

六项指标核心算法
时间加权收益：每日以前一日收盘价加权，避免月中新增持仓扭曲日收益。
波动率与夏普比率：日收益率标准差×√252，再对可配置无风险利率计算夏普比率。
贝塔：投资组合与标普500（GSPC.INDX）的协方差除以基准方差。
回撤：增长指数曲线（基数100）从滚动峰值的百分比跌幅。
相关性矩阵：按日期对齐的资产间皮尔逊相关系数。
集中度（HHI）：赫尔芬达-赫希曼指数应用于仓位权重。

添加持仓时，EODHD 的 Search + EOD 端点自动补全代码和买入日收盘价，随后渲染收益曲线、相关性热图和行业敞口，无需手动构建公式或重复输入价格。

代码地址：GitHub

#开发者 #工具 #Vault #EODHD #投资组合 #风险指标 #React #开源
@DevToolboxHub

说谎的数字：重建真正的Claude Code用量仪表盘

一位开发者在使用 Claude Code 月订阅时，因夜间自动化脚本消耗了两周额度，账户被锁定 4 天，不得不以原价购买额外 Token。这促使他构建一个用量仪表盘，过程历经四次失败迭代，每个版本都揭示一个关键教训。

第一次：自行估算每周 $4,690 限额，显示已用 13%——这个数字完全虚构，却看起来像真实测量。
第二次：从 claude.ai 抓取真实百分比 12%，但没有时间参考点——12% 在第一天意味着太快，最后一天意味着浪费。
第三次：改为计算剩余可用时间和重置时间，发现 Anthropic 的每周限额是固定时钟（每周一 13:00 重置），未用余额不结转，慢速使用等于浪费。
第四次：用贝叶斯统计处理早期波动大的问题，边界测试发现两个 bug——统计容忍度不应翻转判断结论；周期前 24 小时数据不足时不发出预警。此外，数据缺失时仪表盘应诚实显示“数据不可用”，而非用虚假数字保持沉默。

最终仪表盘在第二天就能用一句话告诉你：“按当前速度，额度不够撑到周五。”作者强调：没有来源的可信数字比明显缺口更危险，输入缺失时保持沉默的数字比错误数字更糟。

#开发者 #工具 #ClaudeCode #Anthropic #用量监控 #自动化
@DevToolboxHub

Apache Airflow与.NET 10集成指南

通过HTTP集成Apache Airflow 3与.NET 10，无需用C#重写DAG。服务端保持Airflow负责调度与执行，.NET仅通过REST API/v2触发DAG Run、认证JWT并轮询状态。指南覆盖端到端流程：生成可追踪的dag_run_id、正确序列化config、复用令牌、处理401后自动续期、设置超时与取消传播。

预备环境需.NET 10 SDK、Docker Compose 2.14+、至少4GB内存。仓库提供Airflow 3.3.0、PostgreSQL 16及示例DAG。使用LocalExecutor以简化测试。
认证：POST /auth/token获取JWT，之后通过Authorization: Bearer发送。客户端读取exp避免频繁刷新，并用SemaphoreSlim防止并发续期。
触发：POST /api/v2/dags/{dag_id}/dagRuns，必需字段dag_run_id、conf、logical_date（可null）。响应返回DAG Run对象，state初始为queued。
监控：GET /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}，轮询间隔5-10秒，直到state为success、failed或canceled。使用CancellationTokenSource设置总超时（如10分钟）。
关键实践：dag_run_id应包含业务键以确保幂等性；conf只传小引用（ID、URI），不传密文或大负载；失败时区分401（续期）、403（权限不足）等，仅GET允许指数退避重试。

完整代码示例（含Docker compose、客户端实现、Minimal API）见仓库BlogSamples/Orchestration/Airflow。

#开发者 #工具 #ApacheAirflow #dotnet10 #CSharp #DAG #JWT #DevOps #API
@DevToolboxHub

约80行脚本为营销文档做CI校验

作者的个人项目 lans.cloud 提供 100 多个免费浏览器工具。发文章、目录列表、推销邮件里提到的工具数量却不断出错——37、50、51、又变成50。代码有测试，文档会漂移，营销文案漂移最严重，因为没人执行校验。于是作者用大约80行脚本把营销文档放进CI：从代码注册表中提取真实工具数量，在git push前检查所有仍可编辑的文档里提到的数字是否一致，不一致则阻止提交。

关键设计：只检查当前活文档（后续会复制的），已发送邮件、归档旧文保留原数字。第一次运行就揪出一条过时的“41”，第二天又批量发现16处错误。作者感叹，营销文案是在别人头脑中执行的代码，应该像测试代码一样测试它。

#开发者 #工具 #CI #自动化 #营销文档 #事实检查 #lanscloud #sideproject
@DevToolboxHub

用 Claude Code CLI 当 Prism provider

一位 Laravel 开发者把已有 Claude Code 订阅利用起来，将 Claude Code CLI 封装成 Prism provider，从而在不额外支付 API 费用的情况下继续使用 Prism 的 LLM 调用接口。整套实现只有约 200 行代码，通过 stdin/stdout 与 CLI 交互，并保留了按环境变量切换 provider 的能力。

核心思路：Prism 的 provider 是扩展自 Prism\Prism\Providers\Provider 的类。这里只需实现 text() 和 structured() 两个方法，不支持 embedding、图片和流式。

CLI 调用输出包含 is_error、result、usage、model，可直接映射到 Prism 的 TextResponse / StructuredResponse。

安全要点：命令参数用数组传给 Laravel Process（避免 shell 注入）；用户 prompt 走 stdin 而非 argv；工作目录设为 sys_get_temp_dir() 避免项目指令泄漏；额外检查 envelope 中的 is_error 字段。

结构化输出模拟：CLI 不支持原生 JSON schema，因此在 prompt 末尾拼接 schema 要求，并在解析时先尝试直接 json_decode，再剥离 markdown 代码块，最后截取首尾大括号。

注册方式：在 ServiceProvider 的 boot 中通过 PrismManager::extend() 注册闭包，确保 Octane 下每次解析都重新读取配置。

切换 provider 只需修改环境变量，例如 PRISM_TEXT_PROVIDER=claude-cli PRISM_TEXT_MODEL=claude-haiku-4-5。resolveModel 方法会捕获旧模型名并回退到默认值。

注意：CLI 调用慢（大 prompt 30-90 秒），需注意超时链设置；容器内需安装 Node.js；高并发下进程创建开销大，不适合生产规模流量。对于 solo 开发或小产品，可大幅节省 API 成本。

#开发者 #工具 #Prism #ClaudeCode #CLI #Laravel #LLM
@DevToolboxHub

组织 CLAUDE.md、Skills 与 Agents 的最佳实践

为 Claude Code 等编码代理配置指令文件时，常见误区是同一套知识被复制到 CLAUDE.md、skills、agent 定义和参考文档四类文件中，导致各份独立漂移。经审计发现，这种“自信的错误”成本极高——样式文档推荐了与构建配置不匹配的 CSS-Modules 模式，测试模板在 beforeAll 中设置 mock 却被 test setup 文件在每个测试后重置，渲染组件缺少必要 Provider。每个错误文档都会让代理多花数千 token 的调试循环。

正确做法是按“何时加载、谁需要”决定内容归属：
- 每次会话都加载的规则放 CLAUDE.md / AGENTS.md，保持简短（3 行内 + 链接到 skill）
- 只有特定任务需要的深度知识放 skill（如样式机制、数据获取模式、测试配方），描述加载后才触发
- 角色或流程而非知识放 agent（定义工作流完成标准，调用哪些 skill），保持薄层
- 绝不可跳过的检查用 hook（格式化、lint）——代码规则比文字要求可靠

核心原则：每个事实只存在于一个文件，其他文件均引用它。模式超过几行就放入 skill，CLAUDE.md 仅放链接。

验证文档像验证代码一样：先用 grep 检查文档示例是否真实存在于代码库（如“prefetchQuery”零使用，“recommendedHelper”仅 1/50 测试文件使用）；再用子代理仅凭文档回答实现问题，对比实际代码评分。若代理按文档生成的代码会失败，则文档未通过，修复后再合并。

这一重组成果显著：典型功能任务上下文缩小约 11%，约定变更现在只需改 1 个文件而非 3 个，且文档不再生成损坏的样式和失败测试——每次代理踩坑省去数千 token 调试。

#开发者 #工具 #Claude #ClaudeCode #Agent #工程效率 #文档管理 #CodingAgent
@DevToolboxHub

Empire LLM for Codex：外部模型只贡献证据，不掌权

面对多个AI模型涌入代码审查场景，混乱与成本同步飙升：模型擅自编辑文件、执行命令、甚至自行审批补丁。Empire LLM for Codex 为 Codex 设计的插件，用一条原则解决这一痛点——外部模型贡献证据，而非权威。

Codex 保持领导地位。插件通过 OpenRouter 路由有限请求，应用能力/隐私/可用性/成本策略，返回带来源和成本的响应。外部模型无法编辑项目、执行代码、批准自己的提案或静默合并结果。Codex 评估后决定是否采纳。

具体实现中，请求被严格界定，响应附带着 provider、model、tokens、cost 和引用证据。开发者只需安装插件、定义最小上下文任务、并在行动前阅读“收据”——使用它如同对待外部顾问的建议：有用但绝不自动生效。同样，模型生成的图表、原型等媒体也按此流程处理：生产、标记、返回，由 Codex 决定是否放入资源文件夹。

这种架构强制了职责分离：更多模型并不自动产出更多智能，反而带来更多成本与模糊性。插件设立了三个关键边界：有限请求范围、每份响应的溯源、以及明确拒绝授予仓库权限。目前尚缺审查质量、假阳性率和成本方差等公开基准，但“Codex 主导、外部模型提供证据”的决策本身不依赖单一数字。

如果你已经在 Codex 中拉入多个模型，这是在不授予它们“钥匙”的前提下，最干净的做法。

#开发者 #工具 #EmpireLLM #Codex #AICodeReview #OpenRouter
@DevToolboxHub

SonicJS 认证问题排查指南

SonicJS 部署到 Cloudflare Workers 后，可能会遇到用户无法登录、权限不足或随意注册等问题。以下是在生产环境中必须处理的认证配置。

关闭公开注册：在 app config 中设置 disableSignUp: true，管理员通过 /admin/users/new 创建用户，确保同时写入 auth_user 和 auth_account。
密码存储不一致：Better Auth 读取 auth_account，部分流程只更新 auth_user.password_hash。使用 npm run set-password:prod 脚本同步两个存储，并通过环境变量 ADMIN_EMAIL 和 ADMIN_PASSWORD 种子初始管理员。
RBAC 权限问题：登录后有权限提示，通常是因为 auth_user.role 字段未映射到 RBAC 角色。使用 npm run promote-user:prod 提升用户权限，默认 editor 带 portal:access，admin 则全权限。
症状排查表：任何人可注册→关闭 signup；凭证未找到→运行 set-password；登录后无权限→运行 promote-user；种子失败→检查 wrangler.toml 和 D1 绑定；部署后认证异常→重新设置 BETTER_AUTH_SECRET 和 JWT_SECRET。
使用 patch-package 修复框架 bug，但应优先升级上游版本。

最后，确保私有 CMS 的强化清单：禁用公开注册、种子 admin、创建用户写入双表、RBAC 含 portal:access、密码重设脚本同步双存储、生产密钥通过 wrangler secret put 设置、公开集合显式指定 access.public。

#开发者 #工具 #SonicJS #Cloudflare #BetterAuth #RBAC #Workers #CICD
@DevToolboxHub

2026年S3替代方案速览：自托管与兼容云

2026年Amazon S3替代方案分为两大阵营：免出站费的S3兼容云（Wasabi、Backblaze B2）和完全去锁定的自托管引擎（MinIO、RustFS、Ceph、SeaweedFS）。选择取决于你希望由谁托管——云服务商还是自己的机架。

关键对比
• MinIO（AGPLv3）：单个静态二进制，纠删码，对象锁定，单租户高IOPS场景标杆，商用嵌入需另购许可。
• RustFS（Apache 2.0）：Rust编写，许可宽松，目标高吞吐自托管，但社区规模和第三方工具仍弱于MinIO。
• Wasabi：专有许可，无出站费，热存储约$6.99/TB/月，API兼容但缺乏Athena/Lambda等生态。
• Backblaze B2：专有许可，出站免至存储量3倍，约$0.005/GB/月，适合备份和归档。
• Ceph（LGPLv2.1）：统一对象+块+文件，运营复杂度高，适合大规模存储。
• SeaweedFS：轻量级，大文件数和小对象优化，适用于内容农场。

迁移清单（以12TB为例）
部署目标（MinIO/RustFS/B2），用rclone sync --checksum拷贝，切换应用端点并保留S3作为回退一个计费周期，最后用rclone check验证。在1Gbps链路上迁移12TB约需一个周末，瓶颈通常是源端出站上限。

选择四问：谁运行（云/自托管）、出站模型（读多需免出站）、许可证（AGPLv3/Apache 2.0影响分发）、工作负载（单租户/混合/统一）。答案映射：云+免出站→Wasabi/B2；自托管+宽松许可+高吞吐→RustFS；自托管+成熟生态→MinIO；统一存储→Ceph。

选择建议：按上述四问定位，200GB的PoC比电子表格更有效。最流行的S3替代是MinIO（自托管标杆）和RustFS（Apache 2.0高吞吐），云上免出站则推荐Wasabi和Backblaze B2。

#开发者 #工具 #S3 #对象存储 #MinIO #RustFS #Ceph #Wasabi #BackblazeB2
@DevToolboxHub

mAPI-ng：让 Go API 自我诊断问题

厌倦了盯着 Grafana 面板来回比对？mAPI-ng 是一个为 Go 服务设计的诊断工具，不只看图表，而是关联 RED 指标（速率、错误、时长）与 Go 运行时信号、实例健康及下游 IO，直接给出可能根因和置信度，例如“内存/GC压力（高置信度）”“下游IO瓶颈（中等置信度）”“goroutine泄漏”，并附带“排除此原因”说明，避免黑盒幻觉。

接入极简：两个 import、一个中间件、一个环境变量，无需 YAML 配置或管理 Prometheus；数据存储使用 ClickHouse。整个方案 MIT 许可，可通过 make up 自托管，也提供托管版（含永久免费层），无锁定风险。

GitHub

#开发者 #工具 #Go #API #诊断 #开源 #监控 #ClickHouse #自托管
@DevToolboxHub

phi-leak-guard：检测LLM输出PHI并阻断构建

作者在开发基于LLM的临床文本功能时发现，现有评估库要么完全不检测受保护健康信息（PHI），要么依赖远程API评分——这对患者数据而言本身就是风险。于是他写了 phi-leak-guard，一个零依赖 TypeScript 库，在 Vitest/Jest 中本地运行，不联网、不调用模型，只要发现 PHI/PII 就让测试失败。

库的关键在于用校验和减少误报：NHS号走 Modulus-11 校验，VIN 验证 ISO-3779 校验位，IPv4 做八位段范围验证，SSN/NINO 检查结构+前缀规则。命中结果会标注是 validated（校验通过）还是 pattern（正则/上下文匹配），方便评估可信度。覆盖率方面，它完整覆盖 HIPAA Safe Harbor 列出的 18 类标识符，对于生物识别、照片、“其他任何标识符”等文本无法检测的类别则明确报告为不可检测，而非假装覆盖。作者明确表示这不是合规认证，而是降低风险的回归门。同时预留了可插入 NER 模型的接口。

安装：npm install --save-dev phi-leak-guard。MIT 许可，提供 ESM + CJS + TypeScript 类型。合成基准测试精度 1.00、召回 0.97。

GitHub

#开发者 #工具 #PHI #TypeScript #Vitest #Jest #npm #LLM #HIPAA #隐私检测
@DevToolboxHub

中间链治理：不只在入口验证AI代理输出

现代AI代理通常执行多步工作流——检索文档、调用API、查询数据库、生成中间计划、调用外部工具、产生最终响应。但现有安全机制大多只验证初始提示或最终输出，忽略了中间步骤的风险。例如一个无害请求可能让代理在第三步生成引用敏感表的SQL，这种中途输出问题靠入口检查永远无法发现。

Mid-Chain Governance（中间链治理）在执行过程中按间隔重新检查每一步的输出文本，而非仅依赖入口验证。它不是拦截动作本身，而是在文本传递到下一步或交付用户之前进行检查。通过选择性重新验证——按间隔检查且保证最终交付总被检查——在模拟中实现了接近全步骤检查的捕获率，而延迟成本大约减半。

该项目是一个开源的实验性库 midchain-governance，用于多步AI管道的选择性输出重新验证。它不声称发明了跨步约束检查这一概念，而是一个具体的、经过测试的实现——包括间隔逻辑、无论链长多少都保证检查最终输出的机制，以及探索捕获率/延迟权衡的模拟代码。当前没有生产记录，模拟数据如实标注为模拟。目标是补充而非取代现有护栏。

适用场景：企业AI助手、客服代理、自主软件工程代理、多代理编排平台——任何代理在多个步骤产生有意义输出的系统。作者欢迎反馈和贡献。

GitHub: GitHub

#开发者 #工具 #AI #安全 #LLM #代理 #MidChainGovernance #开源 #多步工作流
@DevToolboxHub

文件同步工具的四种数据丢失陷阱

一个文件同步工具一旦在网络两端读写用户文件，就会面临比崩溃更严重的隐患——静默地销毁用户无法恢复的成果。以下是开发过程中遇到的四种数据丢失陷阱，以及对应的修复方案。这些 bug 都不算罕见，且都能通过简单的测试，但实际却是错误的。

1. os.WriteFile 先截断后写入。若进程在两步之间被杀死，文件会变成半截内容。修复：先写入临时文件，再 rename 进行原子替换。注意临时文件需与目标同目录，且 rename 会交换 inode，硬链接和扩展属性会丢失。更隐蔽的二次伤害：若写入发生在本地区块记录之前，被杀死的写入会产生一个工具不认识的内容片段，下次运行会误报“本地文件已更改”，然后提供 --force 破坏性标志作为解决方案。

2. 基于 etag 或 mtime 的冲突检测会遗漏双方都修改的情况。本地和远端都改动时，etag 比对只会看到“服务端不同”并直接覆盖本地编辑。冲突判定必须基于字节哈希，而非元数据。元数据只适合作为跳过任务的快速路径，不能作为授权覆盖的依据。

3. --prune/mirror 标志造成的破坏最大，因为删除不可撤销。幼稚的规则是“本地有但远端没有就删除”，这会误删用户从未同步过的文件、本地修改的文件以及仅存本地的文件。正确规则：只删除能证明是你写入且用户没有触碰的文件。证明来自你的本地区块记录。若操作中途中断，必须将自身记录为失败，否则 prune 逻辑会将崩溃解读为一批用户删除。

4. 当服务端返回的文件列表为 null 时，Go 的 json.Unmarshal("null", &slice) 会成功并产生一个 nil 切片。不加保护地处理此输入，工具会认为项目没有文件，下次 push --prune 就会删除所有本地文件。防御措施：不可信输入必须进行形状验证，任何意外情况都需停止操作，而非放行。需要明确拒绝 null 列表、达到分页上限的列表，以及内容长度与服务端声明不符的列表。一次错误的信任可能损失用户文件。

这四种 bug 都能通过 happy-path 测试，只有通过问“如果此刻崩溃或出错，用户会损失什么”才能暴露出来。工具是开源的，上述每个决策都有测试用例锁定。

GitHub

#开发者 #工具 #Go #数据安全 #Git #sync #编程教程
@DevToolboxHub

打造免费开源图像编辑器替代昂贵方案

开发者 @rageshpikalmunde 在集成图像编辑功能时发现，现有库要么功能不全，要么需支付昂贵的商业许可。于是他决定自己构建一个免费开源且易于集成的图像编辑器——RP Image Editor。

该库轻量、TypeScript 优先、框架无关且高度可定制。当前提供裁剪、旋转、缩放、绘图、标注、形状、移动端友好、HEIC 支持、自动 EXIF 旋转、高分辨率导出等能力。架构支持集成到 Angular、React、Vue、Ionic、Capacitor 等前端项目。

项目正在积极开发中，计划加入模糊工具、更多标注工具、移动端体验优化、性能优化及更多主题选项。社区反馈对项目发展非常重要，开发者欢迎提交 feature request 或 bug report。

npm

#开发者 #工具 #RPImageEditor #开源 #图像编辑库
@DevToolboxHub

Solana主网部署完整检查表

作者结合自身真实上线经验，整理了一份 Solana 程序从 devnet 到 mainnet-beta 的部署检查表，覆盖部署前、部署中、部署后权限管理、前端对接等四个阶段，并标注了亲自踩过的坑。作者认为，最危险的不是 deploy 命令本身，而是集群确认、升级权限决策、缓冲区 SOL 回收这些“外围步骤”——每项都不复杂，但一旦忙起来容易忘，而任何遗漏都可能造成不可逆损失。

预计起飞前有检查单，外科医生下刀前也有。不是因为他们忘了怎么飞或做手术——而是因为在压力下跳过一个步骤的代价太高，不能仅靠记忆。把 Solana 程序发到主网也属于同一类：不可逆操作、真实资产在线，以及十几件每件在忘记之前看起来都显而易见的小事。作者最近刚完整走了一遍上线流程，趁记忆还新鲜把步骤写成了过手单。
Phase 1: Pre-flight（在 devnet 上做） 确保测试全部通过，且测试针对最终编译的字节码（不是之前版本）。在 devnet 上完整体验一遍主网流程，不跳过任何计划“这次先跳过”的步骤。用 anchor build --verifiable 生成可验证构建——跳过它的话程序就永远是个黑箱。确认部署钱包有足够 SOL 覆盖 rent-exempt minimum（可用 solana rent 预览），注意：有了可验证构建后不要再跑普通 anchor build 或 cargo build-sbf，否则会生成不同哈希。
Phase 2: 部署（不可逆阶段） 切换 CLI 到 mainnet-beta 并用 solana config get 确认。通过专用 RPC 端点部署（不用公共端点，限流会导致写入超时）。网络忙时加 priority fee（--with-compute-unit-price）。了解恢复路径：部署不是原子操作，若中断可用 solana program show --buffers 查看滞留的 buffer 并恢复或关闭它，避免每次失败都泄漏 SOL。
Phase 3: 部署后权限与验证 用 solana program show <PROGRAM_ID> 确认程序已上线并检查升级权限。主动决定谁持有升级权限（单密钥对、Squads 多签或 --final 不可变），不要默认。发布 IDL 让程序接口随程序本身可检索，并通过 IDL 重新生成类型化 client。注意：跳过 IDL 发布会导致构建验证失败。
Phase 4: 前端与上线 将 React 前端指向主网 program ID。确认 Wallet Standard 连接展示的是主网钱包（不是 devnet 残留）。重新验证所有失败模式（拒绝授权、余额不足、blockhash 过期）现在都能给出清晰提示。公布上线，并提前写好用户反馈渠道。

真正让作者惊讶的是：部署命令本身并不吓人——跟 devnet 上跑的一样。真正需要谨慎的是围绕部署的那些环节：确认集群、把升级权限当作决策而非默认、记住停止的部署不是从头再来而是 SOL 在 buffer 里等着回收。最好的工程团队不把上线当作记忆或英雄主义表演，而是当作程序来执行。

#开发者 #工具 #Solana #Web3 #Checklist #Deployment #Anchor #React
@DevToolboxHub

PixelSmash：FFmpeg 十六年高危漏洞曝光

JFrog 安全研究团队披露了名为“PixelSmash”的漏洞，存在于 FFmpeg 媒体框架的 MagicYUV 解码器中，可导致远程代码执行（RCE）与拒绝服务（DoS）攻击。该漏洞已在代码库中潜伏十六年，影响大量使用该解码器的应用。攻击者仅需提供一个恶意构造的媒体文件即可触发。

建议用户立即检查受影响版本，应用补丁或禁用 MagicYUV 解码器以降低风险。

#开发者 #工具 #FFmpeg #PixelSmash #MagicYUV #RCE #DoS #JFrog #安全漏洞
@DevToolboxHub