Destiny

🔮 Destiny

先排盘，再说人话；先做实验，再谈星辰。

Destiny 是一个离线优先、可审计的传统命理计算 Skill，也是一套谨慎的历史天文研究工具。

可以把它想成一张圆桌：

• 历法先生管公历、农历、节气与黄历；
• 八字先生排四柱与大运，但会老实承认“身强身弱”这里只是轻量启发式；
• 紫微先生铺开十二宫，并认真区分 00:00 的早子时和 23:00 的晚子时；
• 易经先生负责起卦、互卦与变卦，但不会冒充尚未实现的完整文王纳甲；
• 桌边还坐着一位很难取悦的量化审计员：他拿 JPL 星历、point-in-time 时间戳、placebo 和多重检验，专门问“这个历史结果会不会只是漂亮的巧合？”

核心原则只有一句：

算盘先响，翻译官后开口。 排盘由确定性代码完成；自然语言只是解释层，不参与偷偷改盘。

同样，历史研究必须允许两种不浪漫、却很重要的结论：“没有稳定的预注册单变量关联”，以及“加入这组天文特征后，M2 并没有比声明过的金融控制基线 M0 更好”。v2.2 增加了后者的配对检验，但它只对用户提供的 controls、样本与 null procedures 有效，不会把一张漂亮的 p-value 通行证伪造成因果。

[!CAUTION] Destiny 用于传统文化、娱乐与可证伪的历史关联研究。它不提供医疗、法律、投资建议，也不替任何人做婚姻、职业或人生决定。历史相关性不等于因果，更不等于可交易利润。

30 秒启动

需要 Python 3.10+。紫微需要 Node.js 18+。

git clone --depth 1 https://github.com/harryhuang0719/Destiny.git
cd Destiny
python3 scripts/bootstrap.py --installer auto
./destiny doctor --all --json
./destiny bazi 1990 1 15 14 1 --json

这条命令跟随 main。v2.1.0 是已经发布的稳定基线；当前源码准备 2.2.0。等 v2.2.0 实际出现在 Releases 后，生产部署可把 clone 改成 git clone --branch v2.2.0 --depth 1 ... 来固定版本。

--installer auto 是默认值：本机有 uv 且 uv lock --check 通过时，使用 uv sync --frozen；否则说明原因并回退 pip。--installer uv 会强制使用完整 lock，条件不满足就失败；--installer pip 是最通用的回退路径，安装项目中 固定的直接依赖。默认环境是仓库内 .venv，也可用 --venv <路径> 指定 独立环境；未指定 --skip-node 时再用 npm ci 安装锁定的 iztro==2.5.8。它们都不会安装系统软件、下载 JPL kernel 或下载市场数据。

Bootstrap 最后的 JSON summary 同时给出 next 和 next_argv。前者方便人类 复制；agent 或程序应把 next_argv 字符串数组直接传给 subprocess，不要重新 拼 shell 字符串。数组会指向实际 venv，并按本次安装能力选择 doctor --core|--research|--all --json。

私有 Python index 环境变量：必须显式打开

默认情况下，bootstrap 给 pip/uv 子进程的是精确环境变量 allowlist，只保留 运行所需的 OS、代理、证书、cache/offline 等环境项；无关 API key、云/数据库 凭据、SSH agent、Python/Node 注入变量和私有 index 环境变量都不会继承。 这不是 config-file 隔离：为保证工具正常运行而保留的 HOME / APPDATA / USERPROFILE，仍可能让 pip/uv 发现用户级 pip.conf / uv.toml。确实要继承 父进程的私有源环境变量时：

python3 scripts/bootstrap.py --installer auto --allow-private-index-env

这个 opt-in 也不会传整个父环境，只额外允许：

• PIP_{CLIENT_CERT,EXTRA_INDEX_URL,FIND_LINKS,INDEX_URL,KEYRING_PROVIDER,NO_INDEX,TRUSTED_HOST}；
• UV_{DEFAULT_INDEX,EXTRA_INDEX_URL,FIND_LINKS,INDEX,INDEX_STRATEGY,INDEX_URL,KEYRING_PROVIDER,NO_INDEX}；
• 命名 index 的 UV_INDEX_<NAME>_{USERNAME,PASSWORD}。

不在默认 operational allowlist 或上述 opt-in 集合内的 PIP_* / UV_* 变量（包括其他 token 与 publish 凭据）仍被丢弃。Summary 里的 allow_private_index_env 会记录这次安装是否显式打开了该能力。

需要额外能力时再加：

# 外部 LLM 适配器
python3 scripts/bootstrap.py --installer auto --llm

# JPL/Skyfield 历史天文研究
python3 scripts/bootstrap.py --installer auto --research

# 开发测试（可组合）
python3 scripts/bootstrap.py --installer auto --llm --research --dev

没有 Node、只想用历法/八字/易经：

python3 scripts/bootstrap.py --installer auto --skip-node

--skip-node 只表示本次不运行 npm ci，不会删除此前已有的 node_modules；因此在已经完整安装过的仓库里，紫微仍可能可用。

Windows：

py -3 scripts\bootstrap.py --installer auto --llm --research
.\destiny.ps1 doctor --all --json
.\destiny.ps1 bazi 1990 1 15 14 1 --json

也可以使用 destiny.cmd。

也可以直接运行包管理器；偏好完全冻结的 Python transitive resolution 时：

uv sync --frozen --all-extras
npm ci --ignore-scripts

pip install . / 构建 wheel 会安装 destiny Python CLI 与核心历法； pip install ".[research]" 再加入 Skyfield。wheel 不会安装 npm 的 iztro， 因此 wheel 环境中的紫微会明确退出 3；这是有意的能力边界，不是静默降级。 需要完整 Skill 与紫微时，请使用 Git clone + bootstrap 流程。

research / all 还直接锁定 NumPy：Python <3.11 用 2.2.6、3.11 用 2.4.6、>=3.12 用 2.5.2。Skyfield 本来会间接带入 NumPy，但 v2.2 的 ridge contract 直接依赖 float64 与 numpy.linalg.solve，所以把它写成 一等依赖并冻结解析结果。NumPy 只在 incremental path 懒加载，核心安装不受影响。

Doctor 到底检查什么？

./destiny doctor --core --json       # Python、lunar-python、固定 tzdata
./destiny doctor --research --json   # core + Skyfield + NumPy；不下载/检查 JPL kernel
./destiny doctor --all --json        # core + Node 18+ + 版本吻合且可加载的 iztro

三种模式互斥；未指定模式时等价于 --all。选中 profile 未就绪时退出 1， JSON 的 selected_mode 与 selected_mode_ready 可供任何 agent 稳定判断。 --core 和 --research 不探测或启动 Node/iztro，相应 checks 明确标为 status: "not_checked"；默认/--all 才校验锁定版本，并在最小 OS 环境中执行 带超时的静态 require('iztro') smoke，metadata 或加载任一失败都视为未就绪。

给 Claude、Codex、OpenClaw 或任何 Agent 安装

仓库根目录就是唯一的 SKILL.md。支持 Skill discovery 的工具把仓库放进 自己的 Skill 目录即可；不支持的工具也只需 clone 到任意目录，再让 agent 先读 SKILL.md。当前可固定已发布的 v2.1.0；需要增量研究时暂用 main， 等 v2.2.0 Release 真正出现后再固定该 tag。

任何 Agent 都能照做的协议

git clone --depth 1 \
  https://github.com/harryhuang0719/Destiny.git /path/to/destiny
python3 /path/to/destiny/scripts/bootstrap.py --installer auto
/path/to/destiny/destiny doctor --core --json

然后给 agent 这段短指令：

先完整阅读 /path/to/destiny/SKILL.md，把它的父目录作为 DESTINY_ROOT。
按任务选择 doctor --core、--research 或 --all；计算时优先 --json --no-llm，
不要自行下载 JPL kernel、市场数据，也不要把出生资料发送给外部模型。

Codex

个人安装用 ~/.agents/skills/destiny，项目安装用 .agents/skills/destiny：

git clone --depth 1 \
  https://github.com/harryhuang0719/Destiny.git ~/.agents/skills/destiny
python3 ~/.agents/skills/destiny/scripts/bootstrap.py --installer auto

然后说：$destiny 帮我把这个公历时间转换成农历，并解释时间口径。 也可以让 $skill-installer 从本仓库安装。参见 OpenAI 官方 Skill 文档。

Claude Code

git clone --depth 1 \
  https://github.com/harryhuang0719/Destiny.git ~/.claude/skills/destiny
python3 ~/.claude/skills/destiny/scripts/bootstrap.py --installer auto

项目级目录是 .claude/skills/destiny。然后使用 /destiny，或直接描述 八字、紫微、历法、起卦、历史天文查询等需求。参见 Claude Code Skill 文档。

OpenClaw

以下命令从 main 安装到当前 active workspace；--global 才会安装到 共享 managed skill 目录。等 Release 页面出现 v2.2.0 后，将 main 换成 v2.2.0 即可固定增量研究版本：

openclaw skills install git:harryhuang0719/Destiny@main
# 或所有本地 agent 共享：
openclaw skills install git:harryhuang0719/Destiny@main --global
openclaw skills info destiny

从 info 显示的目录运行 python3 /显示出来的路径/scripts/bootstrap.py --installer auto。之后可用 $destiny 或 /destiny。参见 OpenClaw Skills 文档。

Windows 将 python3 换成 py -3，启动器使用 destiny.ps1 或 destiny.cmd。只有历史天文任务才给 bootstrap 加 --research；只有明确 选择外部 provider 时才加 --llm。

Release、校验和与 provenance

发布工作流只接受位于 main 历史、且所有版本元数据完全一致的 v* tag。 发布前还必须由两个隔离源码副本产出逐字节一致的 wheel 与规范化 sdist。 v2.1.0 Release 是不可变的历史版本。当前 2.2.0 源码只有在 v2.2.0 Release 实际出现后，才应有 wheel、sdist 与 SHA256SUMS；在此之前不要假设下面的 v2.2 资产已经存在。

gh release download v2.2.0 --repo harryhuang0719/Destiny
sha256sum -c SHA256SUMS       # Linux
# macOS: shasum -a 256 -c SHA256SUMS
gh attestation verify destiny_agent_skill-2.2.0-py3-none-any.whl \
  --repo harryhuang0719/Destiny
python3 -m pip install ./destiny_agent_skill-2.2.0-py3-none-any.whl

成功发布后，wheel 与 destiny_agent_skill-2.2.0.tar.gz 都应能通过 GitHub/Sigstore build provenance 验证。

两条清清楚楚的流水线

flowchart LR
    A[出生/日期输入] --> V[日期·时区·性别·流派校验]
    V --> C[历法]
    V --> B[八字]
    V --> Z[紫微]
    V --> I[易经卦象]
    C --> J[版本化 JSON]
    B --> J
    Z --> J
    I --> J
    J --> U[Claude / Codex / OpenClaw / 人类]
    J -. 显式 opt-in .-> L[单一外部 LLM]

    K[显式提供的 JPL SPK] --> S[天文状态]
    S --> F[连续周期特征]
    M[BYOD point-in-time targets] --> Q[仅向后的 as-of 对齐]
    F --> Q
    H[预注册 hypothesis] --> Q
    Q --> U[Legacy 单变量 · maxT/BH]
    C[哈希 controls long CSV + catalog] --> A[controls as-of · complete case]
    Q --> A
    A --> R[M0 controls ↔ M2 controls + all astro · shared folds]
    R --> N[HAC · circular MBB · full-pipeline C_N placebo]
    U --> E[克制的 evidence labels]
    N --> E

第一条线服务传统文化计算。第二条线保留 legacy 单变量筛查，也提供显式启用的 M0-vs-M2 增量路径。两者不能相互偷渡结论：市场预测差异即使存在，也不能证明 个人命盘有效；个人命理解读也不是市场模型的证据。

命理 CLI

所有主命令都支持 --json。核心默认不联网；--no-llm 保留作显式强调。

历法与农历转换

./destiny calendar 2026 8 26 --json
./destiny calendar 2024 2 4 16 --minute 28 --second 0 --json
./destiny lunar 2024 1 1 --json
./destiny lunar 2023 2 1 --leap --json

输出包括公/农历、精确与农历年干支、节气精确时间、生肖、宜忌、星宿、彭祖百忌、天神和值星。

八字

./destiny bazi 1990 1 15 14 1 --minute 30 --sect 2 --json

• gender：1=男、0=女，这是底层传统算法参数；
• --sect 1|2：明确 23:00 附近的换日流派，默认 2；
• 输出四柱、五行、十神、纳音、地势、胎元/命宫/身宫、大运起始日与完整偏移；
• day_master.strength 是八个明字等权计数提示，绝不是完整旺衰/用神裁决。

紫微斗数

./destiny ziwei 2000 8 16 23 男 --json

紫微通过静态 Node bridge 调用 iztro。出生信息以 JSON 从 stdin 传递，不拼接成 JavaScript；Node 子进程也看不到无关 API key。23:00 使用 iztro 的晚子时 index 12，00:00 使用早子时 index 0。

综合、合盘、流年与黄历初筛

./destiny comprehensive 1990 1 15 14 1 --minute 30 --json
./destiny hepan 1990 1 15 14 1 1992 3 20 8 0 --json
./destiny liunian 1990 1 15 14 1 --year 2026 --json
./destiny zeji 结婚 --month 2026-09 --json

hepan 如果做真太阳时，必须分别提供两人的地点：

./destiny hepan 1990 1 15 14 1 1992 3 20 8 0 \
  --city1 上海 --city2 "New York" --minute1 30 --minute2 15 --json

zeji 是透明的黄历宜忌初筛：活动出现在 宜 且不出现在 忌 才保留，结果按日期排列，没有神秘隐藏分数，也不保证结果。

易经卦象

./destiny iching manual 789978 --json
./destiny iching time 2024 2 10 12 --json
./destiny iching dayan --seed 42 --json

大衍模式使用 6:7:8:9 = 1:5:7:3 的传统离散概率，并返回可重放 seed。时间起卦采用一套明确口径：农历月日 + 子=1 … 亥=12 的地支序数。

把用户原文安全传给 agent：

./destiny iching dayan --question-stdin --json

启动后通过进程 stdin 写入问题。不要写成 ./destiny ... "用户问题" 再让 agent 做字符串插值，因为 shell 的 $() 和反引号会在 Python 之前执行。

当前易经层提供本卦、互卦、变卦、变爻和简要卦辞/指导；不宣称拥有完整爻辞库、纳甲、世应、六亲六兽落爻、旬空、月建日辰旺衰等完整文王卦能力。

真太阳时：时间不是一个裸整数

./destiny bazi 1990 6 15 14 1 --minute 30 --solar --city 上海 --json
./destiny bazi 1990 6 15 14 1 --minute 30 --solar --city "New York" --json
./destiny bazi 1990 6 15 14 1 --minute 30 \
  --solar --longitude 77.21 --tz 5.5 --json

城市同时绑定经度与 IANA timezone，因此纽约夏令时不会再被默认成 UTC+8。不存在或歧义的 DST 本地时刻会失败；歧义时可显式给 --tz。JSON 同时保留：

• 原始民用时间；
• 城市、IANA zone、历史 UTC offset 与经度；
• 校正后的真太阳时；
• true-solar-time-v2 口径版本。

它仍是一套约定明确的近似，不解决所有命理流派争议。详见 方法论。

可选外部 LLM

Agent 通常应该直接解读离线 JSON，不需要再把出生信息发给第二个模型。

如果你明确希望 CLI 调用外部 provider：

cp .env.example .env
# 只在本机编辑 .env；它已被 gitignore
./destiny bazi 1990 1 15 14 1 \
  --llm --provider minimax --env-file .env --json

支持 minimax、deepseek 与自定义 OpenAI-compatible endpoint。默认只调用你指定的一个。--llm-fallback 必须单独写出，因为它可能把同一份出生资料发送给另一个已配置供应商。详情见 隐私与安全。

历史天文查询

历史层来自仓库内保留的 原始研究 Blueprint，实现修正见 Blueprint notes。

1. 明确取得 JPL kernel

Destiny 不会自动下载 32 MB 的 de440s.bsp。从 JPL/NAIF 官方目录取得文件并保留来源；文件不应提交 Git。

mkdir -p data/kernels
curl --fail --location \
  https://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/planets/de440s.bsp \
  --output data/kernels/de440s.bsp
./destiny history kernel-info --kernel data/kernels/de440s.bsp

kernel-info 输出 SHA-256；每份 feature manifest 也会记录 kernel hash。de440s 覆盖约 1849–2150，适合现代研究。完整 DE440/DE441 是可选外部 kernel，不进入仓库。

2. 查询一个历史时刻

./destiny history astro \
  --kernel data/kernels/de440s.bsp \
  --at 1929-10-24T16:00:00-05:00 \
  --bodies sun,moon,mercury,mars,jupiter,saturn \
  --allow-pre-utc

1972 年前，UTC 不是现代严格意义上的统一时间标签；因此命令默认拒绝，只有显式 --allow-pre-utc 才会返回带 proleptic UTC label 警告的描述性重建。天文内部仍记录 TT/TDB/UT1。

坐标口径写入结果：地心、apparent、ecliptic/equinox of date。每个 body 还记录实际 SPK target 与 NAIF ID；例如 de440s 的部分外行星是 system barycenter，不冒充 planet center。

3. 构建连续历史特征

先估算，不计算：

./destiny history build \
  --kernel data/kernels/de440s.bsp \
  --start 2000-01-01T00:00:00Z \
  --end 2026-01-01T00:00:00Z \
  --step-hours 24 --out data/astro_daily.csv --dry-run

确认后移除 --dry-run。生成内容包括：

• 各天体黄经 sin/cos、黄纬、距离、黄经速度、逆行；
• Moon–Sun 有向相位与 illumination；
• 预设 pair 的 signed angle、0–180° separation、相对速度；
• Fourier k=1,2 与连续 Gaussian aspect scores；
• CSV 和 .manifest.json 的 SHA-256、kernel hash、body target、口径与参数。

更高 harmonic、更多 pair、不同 orb 都是额外 hypothesis，必须在查看 OOS 前固定。

4. 准备 BYOD target 与 controls

本仓库不下载、不捆绑、不重新分发行情。先复制 研究输入模板：

• series_catalog.example.json：精确声明 vendor、series、instrument、venue、时区、calendar、price/target 语义、tradability、vintage 与许可；
• hypothesis.example.json：legacy schema-1.0 单变量 manifest；
• hypothesis.incremental.example.json：完整 schema-2.0 M0/M2 manifest；
• controls.example.csv + controls_catalog.example.json：经过 validator 的 point-in-time long-table 小样；
• generate_incremental_demo.py：生成 150 行、可完整运行的纯 synthetic demo；
• target_schema.csv：每行必须满足：

observation <= available <= decision < execution <= target_start < target_end

Controls 的精确 header 是 control_id,observation_time_utc,available_at_utc,vintage_id,value，并按 (control_id, observation, available) 严格递增。 Catalog 的 SHA-256 必须匹配 CSV。空字符串是唯一 missing marker；不允许 future/nearest join、插值、回填、post-decision revision 或从 blank latest 回退旧值。

日期只有 2025-01-01 而没有 offset，会被拒绝。未来 feature/control join 会被拒绝。VIX、收益率等 indicator 如果标记 tradable=false，系统不会伪造策略 Sharpe。

5A. Legacy 单变量研究

./destiny history research \
  --features data/astro_daily.csv \
  --targets /path/to/targets.csv \
  --catalog /path/to/series_catalog.json \
  --hypothesis /path/to/hypothesis.json \
  --trial-registry /path/to/trials.ndjson \
  --out /path/to/result.json

incremental_model 缺失或精确等于 {"enabled": false} 时走这条兼容路径， 计算与 result schema 保持 1.0.0。

默认会验证同目录的 astro_daily.csv.manifest.json；若 sidecar 在别处，显式 加 --feature-manifest /path/to/manifest.json。manifest、CSV、target、catalog、 hypothesis、registry 与 result 不能互相复用路径或 hard-link identity。

输出包含：

• train / validation / test 的 Pearson 与 Spearman；
• joint circular time-shift placebo、经验 p、familywise maxT 与 BH q；
• 有效周期覆盖与方向稳定性；
• backward-only as-of 对齐、丢弃样本和输入 hashes；
• 每次 trial 都追加 STARTED，并最终追加 COMPLETED 或 FAILED 的 registry；
• 对非重叠、可交易 return target 才会生成的简化 OOS threshold strategy；
• 限制与 evidence status。

5B. M0-vs-M2 增量研究

./destiny history research \
  --features data/astro_daily.csv \
  --targets /path/to/targets.csv \
  --catalog /path/to/series_catalog.json \
  --hypothesis /path/to/hypothesis.incremental.json \
  --controls /path/to/controls.csv \
  --controls-catalog /path/to/controls.catalog.json \
  --trial-registry /path/to/trials.ndjson \
  --out /path/to/result.json

Enabled mode 要求 hypothesis schema 2.0.0，两个 controls 参数必须成对出现， 输出 result schema 2.0.0。M0 使用全部预注册 controls；M2 在完全相同的 rows/folds 上加入全部预注册 astronomy features。两者共享 alpha grid 与 fit 预算；train-constant columns 会记录后冻结删除。两者各自在 train→validation 选 alpha，再用 train+validation refit，最后只打开一次 test。主统计量 d = squared_loss_M0 - squared_loss_M2，正值偏向 M2。

推断不是只扔出一颗 p-value：

• Newey-West HAC 使用预注册 lag；
• circular moving-block bootstrap 用 uncentered distribution 做 CI、centered null 做单侧 p，但不假装覆盖完整模型选择不确定性；
• full-pipeline placebo 从完整循环群 C_N 的非零 joint shifts 中取样，controls、 targets、timestamps 与 split 不动，而每次重新执行 M2 的常数检测、全 alpha grid、refit 与 test loss；
• robust p 是三个 component p 的 max，对应 union-null 的保守 intersection-union 构造；再做 min(1, family_size × p_robust) Bonferroni。 任一 component p 为 null 时，robust/family p 也保持 null。

最后一步仍有边界：family p 依赖声明的 family 真实且完整，本地 runner 不能 证明全局 family completeness 或 family_index 唯一。threshold_met 只是 diagnostic，绝不会升级 evidence label。

状态的含义很克制：

状态	含义
EXPLORATORY	普通历史探索
PSEUDO_OOS_ONLY	时间上切开，但历史结果早已可见，不是假装封存的确认
PROSPECTIVE_DECLARED_UNVERIFIED	本地时间/Git 门禁通过的 prospective 声明；没有外部时间戳/公证，不能自我认证
DESCRIPTIVE	周期/事件数不足，只能描述
EVALUATED_EXPLORATORY / EVALUATED_PSEUDO_OOS_ONLY / EVALUATED_PROSPECTIVE_DECLARED_UNVERIFIED	incremental evaluation 对应的内部状态；不代表确认

两个路径都不会打印 CONFIRMATORY_PASS。Incremental 结果仍只是在给定 controls、 样本、ridge 与 null procedures 条件下的配对预测损失比较，不证明完整金融信息已被 控制，更不证明因果、命理有效、稳定 alpha 或可交易利润。详见 历史研究方法。

“支持”与“不冒充支持”

能力	当前实现	明确不声称
历法	公历/农历双向、节气精确时刻、黄历字段	所有民俗流派唯一标准
八字	四柱、十神、纳音、地势、大运	完整旺衰/用神裁决
紫微	iztro 2.5.8 十二宫与星曜	所有紫微门派一致
易经	起卦、本/互/变卦、变爻指导	完整纳甲六爻与全爻辞库
择日	宜忌透明初筛	成功保证或完整择日术
历史天文	哈希 JPL kernel、连续特征、明确 frame	NASA/JPL 背书或历史 vintage 可执行性
历史研究	legacy 单变量 + opt-in paired M0/M2、HAC/MBB/声明的 C_N joint shifts	完整金融 baseline、因果、稳定 alpha、production trading

JSON 与退出码

当前源码的 package/Skill version 是 2.2.0；只有 v2.2.0 tag 工作流成功后， 它才是已发布 release。源码版本也不等于数据协议版本：核心 JSON 仍是 2.0.0， 天文是 1.0.0，legacy research 是 1.0.0，enabled incremental research 才是 2.0.0。结果包含引擎版本、analysis mode 与计算口径，避免静默改义。

Exit code	含义
0	命令成功
1	Help 或 doctor 选中的 profile 尚未就绪
2	输入、配置或研究契约错误
3	紫微 Node/iztro 引擎不可用
130	用户中断

JSON 模式 stdout 只输出一个 JSON document；诊断去 stderr，便于 agent 和程序直接 json.load()。

测试与复现

python3 scripts/bootstrap.py --installer auto --llm --research --dev
.venv/bin/python -m pytest -q
npm test
npm audit --omit=dev

测试套件覆盖：

• 立春精确到秒的四柱切换；
• 已知八字与男女大运；
• Bazi sect 1/2 的晚子时差异；
• 八经卦与关键六十四卦 golden；
• 农历梅花时间例、大衍概率桶与 seed replay；
• 紫微早/晚子时不同命盘、isEmpty() 与 JS 注入回归；
• Node 子进程无法读取哨兵密钥；
• 纽约 DST、歧义/不存在时间、半小时时区；
• 每个 --no-llm 路径、纯 JSON 与恶意问题文本；
• circular geometry、FDR、point-in-time 违例、as-of join、trial registry、placebo 与 indicator 禁止伪回测；
• controls revision/staleness/blank-latest、M0/M2 shared rows、ridge golden、HAC、 circular block、完整 C_N shift 与 conservative family correction；
• Sun/Moon/Mars/Jupiter 三个 epoch 的离线 JPL Horizons independent golden；
• 可选真实 JPL kernel smoke test。

CI 不调用真实 LLM，不提交或缓存私人数据。

项目结构

Destiny/
├── SKILL.md                         # Claude / Codex / OpenClaw 共同入口
├── README.md / CHANGELOG.md
├── AGENTS.md / CLAUDE.md
├── destiny / destiny.cmd / destiny.ps1
├── scripts/
│   ├── destiny_analyzer.py          # 向后兼容的统一 CLI 门面
│   ├── cli_support.py               # 参数校验与通用 CLI helpers
│   ├── llm_provider.py              # 可选 provider 传输边界
│   ├── output_support.py            # JSON schema、解释与输出
│   ├── calendar_engine.py
│   ├── bazi_engine.py
│   ├── ziwei_engine.py + ziwei_bridge.cjs
│   ├── iching_engine.py
│   ├── timezone_util.py
│   ├── historical_research.py       # 向后兼容的研究 API 门面
│   ├── research_common.py           # schema、I/O 与共享约束
│   ├── research_ephemeris.py        # JPL/Skyfield 状态计算
│   ├── research_features.py         # 连续天文特征
│   ├── research_contracts.py        # catalog/hypothesis/target 契约
│   ├── research_statistics.py       # split、placebo、maxT/BH
│   ├── research_registry.py         # append-only trial registry
│   ├── research_runner.py           # point-in-time 研究编排
│   ├── history_cli.py               # 历史研究 CLI
│   └── bootstrap.py                 # auto / uv / pip 安装器
├── references/                      # 方法、隐私、agent 与历史研究口径
├── docs/                            # 原始 Blueprint 与实现修正
├── examples/research/               # 无市场数据的 schema/config 模板
│   └── generate_incremental_demo.py  # 完整 synthetic M0/M2 demo
├── tests/ + tests/fixtures/          # regression、numeric golden、legacy fixture
├── package.json / package-lock.json
└── pyproject.toml

故障排查

Node.js not found / Cannot find module 'iztro'

node --version
npm ci --ignore-scripts
./destiny doctor --all --json

Node 需 18+。只用非紫微功能可重新 bootstrap --skip-node；它不会清理 已经存在的 node_modules。

skyfield 未安装

python3 scripts/bootstrap.py --installer auto --research

Skyfield 与按 Python 版本锁定的 NumPy 都只属于研究 extra，不会拖进普通排盘环境。

1972 年前时间被拒绝

这是有意的。现代严格 UTC 不能直接倒贴到 1929 年。若做描述性天文重建，显式加 --allow-pre-utc，并保留输出中的时间政策警告。

JSON 解析失败

确认调用的是主入口并带 --json，不要把 stderr 合并进 stdout：

./destiny bazi 1990 1 15 14 1 --json > chart.json
python3 -m json.tool chart.json

安全、许可与致谢

• Destiny 源码：MIT，见 LICENSE。
• lunar-python：MIT；iztro：MIT；httpx：BSD-3-Clause；Skyfield：MIT； NumPy project：BSD-3-Clause（wheel bundled components 另见其 notices）。
• 完整说明见 THIRD_PARTY_NOTICES.md。
• JPL kernel 是外部数据，不进入仓库；使用者保留来源与 SHA-256。Destiny 不代表 NASA/JPL 背书。
• Swiss Ephemeris / pyswisseph 因 AGPL/商业双许可没有被悄悄加入 MIT 核心。
• 不提交 .env、出生资料、生成命盘、市场原始数据、JPL kernel、trial registry 或回测结果。

漏洞请按 SECURITY.md 私下报告；贡献算法或研究方法前请读 CONTRIBUTING.md。

如果最后跑出来的结论是“星辰很美，但 M2 没有在这套声明过的 M0 controls 之外 稳定降低 OOS loss”，那不是失败——那正是这套系统保持诚实的一刻。