另一半
因为我希望它们存在，所以我构建了这些东西。
PANTHEON 是正式的工作。这里展示的是在没人为结果买单时，同样的直觉会做出什么：桌面上的真实星空、一个零依赖的星历库，以及一个能绘图的终端。纪律完全相同，只是赌注不同。
GNOME Shell · GPL-2.0 · ★3
TerraFirma：把真实的星空铺在你的壁纸上。
这不是天空的动画。而是真实的天空，根据星历，按你的纬度、经度和时钟计算得出。
热循环刻意设计为可测量
投影和大气计算位于 skymath.js 中，它不从 GNOME Shell 导入任何内容。只能在会话内运行的文件，只能靠猜；能独立运行的文件，可以计时。这条边界背后的理由，与让 PANTHEON 核心远离其应用层的纯度 lint 相同。
星表和星历来自第三方，已在 NOTICE.md 中注明出处。给它指定一个日期，然后抬头看看，对这类软件来说，这是唯一算数的测试。
已抽离并发布
由此产生的三个软件包。
与 PANTHEON 那六个相同的模式：先把东西做出来，找出真正可复用的部分，把它拆出来，并按其自身的条件发布。这三个都采用 MIT 许可，现在就可以安装。
braillecanvas v0.4.0 · MIT
盲文字符每个字符单元有 2×4 个点，所以一个 80×24 的终端实际上是一块 160×96 的画布。这就是真正的渲染和 ASCII 艺术的区别。
有意思的部分是颜色。每个单元格携带两种颜色，一种用于点亮的点，一种用于空隙，因此跨越边缘的单元格（比如皮肤与天空的交界处）能保留边缘，而不是把它平均成一团泥。在这张图像上，每个点的平均颜色误差从 45.7 降到 21.3。
按每个单元格选择点亮哪些点，而不是从固定的抖动网格中取图案，可将无纹理单元格从 35.1% 降至 1.6%。
它自己的 README 中写明了两个限制：低于约 90 列时照片就不再可用；单色则根本无法呈现这张图，她的脸亮度测得 159，而身后的天空是 192，所以 1-bit 渲染从构造上就只能是一个剪影。
skymaths v0.1.2 · MIT
无依赖的位置天文学计算：太阳、月亮、行星、晨昏蒙影、升起与落下。从 TerraFirma 的星历中提取，随后做了修正：它所用的 Espenak–Meeus 多项式仅针对 1900–1920 年发布，却被用于 1986 年，导致 1950 年得出 −534 秒，而实测值为 +29。这是通过对照已发布的天文年历、而非对照其自身来核查发现的。
它就运行在本站上：在深色模式下，背景是 2026 年 8 月 13 日英仙座流星雨之夜的加的夫夜空，在你的浏览器中计算生成：5,044 颗恒星呈现其真实颜色，还有当时的月相和行星所在位置。滚动页面即可转动视角。
/proc 数据：滚动时间窗口内的 CPU、内存和平均负载。图表在远低于照片所需的 90 列下限时也能正常显示，因为它们本身就是高对比度的。就在此页面上，此刻
图案是生成的，而种子无法逃逸。
本站的每一件艺术作品：上方的主视觉、网站图标、社交卡片、头像，都出自 PANTHEON 自己的生成器。确定性且带种子：相同的种子每次都生成相同的图像。
两端契约相同
服务端引擎渲染社交卡片和租户站点；浏览器引擎绘制你正在看的动画版本。同一条规则：输入种子，输出可复现的艺术。
从构造上防注入
种子只用于 PRNG，别无他用。它从不会被插入到标记或样式中。一个实际上是攻击载荷的租户名只会画出一幅不同的图，而不会画出一个 script 标签。这与系统其余部分是同样的本能，只是用在了装饰上。
可以安装，不只是可以阅读
六项保证，已提取并发布。
每一个都源自 PANTHEON，作为一个可验证的承诺拆分出来，然后发布到 PyPI，使其能够独立存在。对抗性 AI 代理（由我自己运行，并非独立审查）逐行检查了它们，发现了真实的缺陷；下面列出的是修复这些缺陷之后的版本，每个版本的验证方式都是从注册表安装到干净环境中，并重新运行审查者自己的复现步骤，而不是信任构建日志。
pantheon-guardrails v0.3.2 · Apache-2.0
一个宪章评分器，只在高风险回复上调用 LLM 评判，并要求该评判必须是与生成模型不同的模型，以免两者存在相同的盲区。它过去会把超出范围的分数向上截断：一个返回 {"clarity": 99} 的评判会得到满分 1.0 并通过所有阈值，这是一个失效即放行的护栏。现在，评判抛出异常、挂起或返回无意义内容时，都会被明确视为评估失败，默认予以阻止。
pantheon-ssrf-guard v0.2.1 · Apache-2.0
一个能抵御 DNS 重绑定的双层 SSRF 出站防护：它在连接时重新检查 socket 实际连接到的 IP，因此一个先解析为公网地址、随后重绑定到回环地址或云元数据的主机会被拒绝。审查发现，opener 仍会读取 file:// URL，因为 Python 默认会为其他 scheme 安装处理器；现在在边界处有了明确的 http/https 允许列表，重定向也包括在内，环境代理默认关闭，除非你主动开启。
pantheon-tool-sanitizer v0.3.0 · Apache-2.0
在不可信的 MCP 工具文本进入智能体提示之前，剥离其中的工具协议标记和 Unicode 走私内容。范围如实界定：它不声称能阻止纯文本注入，那是架构问题而非字符串问题。审查带来两处修复：一个 256 kB 的对抗性输入曾耗费 26 秒 CPU，现在直接拒绝；"Read\nthe\tfile" 不再变成 "Readthefile"，因为换行是词边界。
credit-ledger v0.3.0 · Apache-2.0
基于 Postgres 的防透支计量，约 150 行代码：针对余额 50 发起 100 笔并行扣费，恰好 50 笔成功；在 webhook 重放下实现恰好一次计费；隔离由行级安全强制执行。已发布的构建版本曾经会接受负数扣费，也就是反过来给客户付钱，还会接受低于该列精度的金额，实际计费 0.0000 却报告成功。现在一条金额规则覆盖所有路径，并且为已有的数据库提供了经过测试的迁移。
pantheon-ical v0.3.1 · Apache-2.0
用不到 200 行代码实现预订日历的 iCal（RFC 5545）双向读写。丢失的忙碌时段会被读成空闲，所以静默是危险的失效方式：过大的日历会被拒绝而不是被截断，溢出的重复规则会明确报告，而不是返回一个不完整的列表。最后一次修复不仅限制了结果，也限制了工作量：一条单行的恶意规则过去会在被拒绝前用 76 秒生成 3400 万个实例，现在会在 401 处停止。
上面的每个修复都以同样方式完成：先复现缺陷，修复边界而非症状，然后证明把 bug 放回去时新测试会失败。一个不会失败的测试不是证据。
它运行在什么之上
技术栈很平常。边界不是。
Python 3.12、FastAPI、Postgres、Redis、React 配 Vite，一个 Dockerfile 部署在 nginx 后面。这些都不是值得称道的决定，而是你为了把注意力放到真正重要的地方而选用的部件。
146 个文件 · 14,002 行
pantheon-core：底层基座。按约定与领域无关：它不得从 residents 或 bundles 导入，一旦导入，两项独立检查都会让 CI 失败。
210 个文件 · 24,216 行
测试，针对 38,816 行 Python。我不手写实现，所以测试套件不是安全网。它就是规格说明，也是我真正编写的产物。
五层，一条路径
architect · runtime · guardrails · substrate · primitives，providers 被刻意置于栈之外，因为它同时位于两层之下，契约明确说出这一点，而不是勉强变通。
正是这条边界，让六个组件可以被抽离出来，作为独立库发布，抽离工作大多只是移动那些从未被允许向下依赖的文件。完整版本，包括我做错的部分 →
可以问这些工作中的任何内容。
- Isaac 在找什么样的职位？
- 其中哪些在生产环境中运行？
- 给我看一个他发现并修复的真实 bug