root/Jyotisha
2
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Add antigravity fragment sync audit task

Browse Source
This commit is contained in:
732642856
2026-06-25 19:02:49 +08:00
parent 3e58909831
commit cb1789433b
7 changed files with 321 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitignore
+2
View File
@@ -19,3 +19,5 @@ htmlcov/
.mypy_cache/
.hypothesis/
benchmarks/jyotish/outputs/
output_report.txt
results_extracted.md
docs/research/antigravity_round9_calibration_status_bug_report_2026_06_25.md
+11
View File
@@ -0,0 +1,11 @@
# Antigravity AI 外部校准透明度 Bug 报告 (Round 9)
## 文件级 Bug 清单
本部分枚举直接影响“普通用户如何看待系统准确度”的产品化缺陷。
| 严重程度 | 文件路径 | 行号 | 现象 | 用户影响 | 修复建议 |
|---|---|---:|---|---|---|
| **P0** | `jyotish-app/index.html` <br/> `jyotish-app/main.js` | 全局 | Web 前端完全没有显示后台极为严谨的 `ready_for_calibration` 与 `valid_packets` 等外部采源大盘进度数据。 | 普通用户在使用 Dasha 时，可能误认为人生重大起步日期是100%绝对校准的。 | 在网页显眼处（如首屏底部或专属 Trust Center 弹窗）动态读取或静态写明当前 Dasha/Shadbala 的校准队列进展。 |
| **P1** | `jyotish-app/ai-chat.js` <br/> `jyotish-app/skill-map.js` | 全局 | AI Chat 系统没有在 Prompt 的底层结构中把 `external_verified` 尚未完成的状态强行注入上下文。 | 若用户直接问大模型“我的这几年大运精确到了哪一天？”，大模型可能会脱离界限进行幻觉性肯定回答。 | 在请求大模型生成洞察时，强行在头部 System Prompt 附加一段关于“高级模型仍在收敛对齐阶段，只能做总体参考”的提示。 |
| **P2** | 整体产品部署架构 | - | 虽然与代码 Bug 无关，但当前的纯工程化入口（依赖 Python 和 Node 命令行）将一切没有代码知识的用户挡在门外。 | 用户只能去看静态 Demo（甚至有些后台高级功能调不出来），体会不到校准大盘的意义。 | 安排一次桌面环境的极简打包（如 Pake），一键拉起后端 API 服务器与前端壳。 |
docs/research/antigravity_round9_competitor_transparency_gap_2026_06_25.md
+11
View File
@@ -0,0 +1,11 @@
# Antigravity AI 竞品透明度对比差距 (Round 9)
## 竞品对用户算法边界的披露方式
在高级计算方法往往存在派系争议（如不同 Ayanamsa 或年历基准导致的大运时间差）的占星领域，成熟产品如何对待自己的“计算黑盒”？
| 对标对象 | 透明度呈现 | 我们当前呈现 | 缺口 | 推荐修复 |
|---|---|---|---|---|
| **VedAstro** | **API/文档级透明**。所有计算方法在 Swagger 或开放文档中均标明引用的古籍出处及使用的 Ayanamsa，用户明确知道所调用的流派。 | 仅在代码仓库 `README.md` 与核心验证器中硬编码限制。 | 面向最终用户的网页端缺乏“计算依据与校准度”查阅入口。 | 在网页前端增加“算法来源与校准状态”（Trust Center），直接展示后台 `oracle queue` 的进度。 |
| **JHora** | **桌面极客级透明**。UI 上提供了成百上千个复选框和下拉菜单，用户不仅能看到基础分量表，还能完全掌控每一个微调常数（如节点类型、日出定义）。 | 只能通过命令行或 JSON 配置底层常数，前端几乎是一个没有任何底层调整按钮的黑盒。 | 用户无法在界面上直观感知当前 Dasha 的微观时间计算基准。 | 短期内无需增加复杂的极客 UI，但必须在展示结果处标注类似于“基于 Lahiri 与通用 BPHS 规则构建中，外部大运起步边界待校正”。 |
| **PyJHora** | **代码级透明 (AGPL)**。由于强制开源，所有计算链条和写死的星历修正对于开发者绝对透明。 | 我们也是源码级开源。 | 在防止代码侵权前提下，我们的常数库构建进度较慢。 | 继续保持开发者的白盒机制，通过隔离取样加速真值录入，并在文档里继续清晰界定哪些部分尚未绝对对齐。 |
docs/research/antigravity_round9_next_fix_plan_2026_06_25.md
+19
View File
@@ -0,0 +1,19 @@
# Antigravity AI 下一步产品修复方案 (Round 9)
## 1. 对标
虽然我们在后台做了世界上最严谨的黑盒证据检验，但在产品前台展示上，相较于 VedAstro 极其坦诚的开放接口集，我们的 Web/App 在“自我能力边界”的披露上存在严重断层。普通用户极可能对尚未充分校验绝对值的大运（Dasha）和六维力量（Shadbala）深信不疑。
## 2. 开源参考
针对如何向用户传达“这部分仍在参考外部标杆计算”的态度，我们需要在界面和问答交互中引入安全区概念。不同于 JHora 完全不解释而是甩给用户满屏选项，我们需要化繁为简，在用户查阅特定指标时进行友好的提示。
## 3. Bug
我们强烈建议 Codex 按照以下优先级序列，立刻开始执行普通用户产品路径的填坑与透明度重构：
- **第一步（最迫切）：Web/App 侧暴露 Trust Center**
在 `jyotish-app/index.html` 与 `main.js` 的视图层，尤其是大运与力量面板附近，增设“数据可信度”或“Dasha/Shadbala Calibration Status”微标与说明弹窗。明白无误地写明：“该部分的绝对起步时间与强度值正通过外部真实靶心（如 JHora 等）进行严密收集校验，当前状态为参考标定中。”
- **第二步：动态读取校准大盘**
修改 `jyotish_api_server.py`，新增诸如 `/api/capability_audit` 的节点，或者直接在前端打包时把 `oracle queue summary` 的 `ready_for_calibration` 数量进行静态展示，让用户亲眼看到数字从 0 变 5 的演进过程。
- **第三步：AI 与 Skill 文案同步封印**
在 `jyotish-app/ai-chat.js` 以及 `SKILL.md` 的系统提示词中，增加硬性规定：当用户提问关于特定日期的具体人生起步大运时，强制 AI 必须首先声明当前模型的外部证据验证状态，不可满口打包票。
- **第四步：一键打包交付用户**
通过 Pake 或 Docker Compose 一键脚本，把目前的 Web 端与后端 API 融合成一个“双击即可使用”的桌面程序或镜像，彻底解决让小白去配置 NPM 和虚拟环境的千古难题。
docs/research/antigravity_round9_user_calibration_transparency_audit_2026_06_25.md
+20
View File
@@ -0,0 +1,20 @@
# Antigravity AI 普通用户校准透明度黑盒审计 (Round 9)
## 审计范围
我们在本次审计中针对 `README.md`、`SKILL.md` 以及 `jyotish-app/` 下的前端呈现逻辑，检索了 `ready_for_calibration`、`Dasha/Shadbala` 校准等关键字，重点评估当前对普通用户的透明度。
## 检查结果
1. **README 是否说明 `ready_for_calibration: 0`**：
- **通过**。目前的 `README.md` 在“质量门与验证”板块确实写明了：“当前队列有 5 个 `template_only` 任务、`ready_for_calibration: 0`、`production_tuning_allowed: false`，说明只能继续采集外部黑盒目标值”。这在工程层面上是透明的。
2. **SKILL 是否避免过度宣称**：
- **通过**。在 `SKILL.md` 以及前端内置的 `skill-map.js` 中存在声明：“相对强弱已展示，外部绝对值校准仍需标注边界”。AI 也没有被赋予“系统已完全精准”的越权提示。
3. **Web/App 首屏或 Trust Center 是否展示 calibration status**：
- **不通过（存在隐患）**。检索发现 `jyotish-app/` 没有任何直接向 C 端普通用户渲染输出 `ready_for_calibration` 大盘数据的视图逻辑。这意味着不读 README 的“纯净小白”用户根本不知道系统后台正卡在外部数据收集中。
4. **AI Chat 安全边界**：
- **部分通过**。在结构化输出时 AI 不会吹嘘，但在纯自由对话时，如果缺乏强制系统注入的 calibration status，大模型有幻觉吹嘘其排盘（尤其是人生起步大运日期）为全球绝对真理的风险。
5. **用户能否区分高可信与待校准区域**：
- **较差**。基础的 D1/D9、Ashtakavarga 拥有 100% 测试覆盖和天文学精度；而 Dasha 年月日漂移和 Shadbala 边缘值目前为相对参考。产品界面在呈现这些报表时，并没有使用明确的 UI 徽章（如“精确级” vs “外部校准中”）进行隔离提示。
## 结论
工程上（文档与测试）的防腐做得极其优秀，但是这些警示尚未穿透至普通产品的用户界面上。普通用户面临被高深且无声的排盘数据误导的真实风险。
docs/research/antigravity_sidecar_work_order_round10_2026_06_25.md
+252
View File
@@ -0,0 +1,252 @@
# Antigravity AI 副手任务单 Round 10（2026-06-25）
## 任务目标
本轮副手任务聚焦两件事：
1. 复核“地毯式本机碎片扫描”和 GitHub 云端同步状态，确认是否还有因 Codex、Antigravity、WorkBuddy、Downloads、Desktop、历史备份窗口造成的印度占星文件遗漏。
2. 复核 Round 9 暴露的普通用户风险：Web/App/Skill 是否仍没有清晰披露 Dasha/Shadbala 外部校准状态。
本轮仍然是外部审计和黑盒验证任务，不是核心实现任务。Codex 主线程会负责真正修改 `jyotish-app`、`SKILL.md`、测试和提交推送。
## 严格边界
禁止事项：
- 不要提交、推送、重置、删除、移动、批量格式化或覆盖现有文件。
- 不要读取、记录、传播任何 GitHub token、API key、浏览器登录态、系统钥匙串、cookie、SSH 私钥或远端凭证。
- 不要打开或摘录用户私人星盘完整报告内容，除非只读取文件名、大小、路径和同步状态。
- 不要修改 `scripts/`、`jyotish-app/`、`skills/`、`SKILL.md`、`tests/`、`README.md` 的实现内容。
- 不要把 `output_report.txt`、`results_extracted.md` 或任何私人出生资料推送/纳入同步建议。
- 不要复制 JHora、PyJHora、AGPL/GPL 项目的实现代码、公式常量或内部数据表。
- 不要把 `template_only`、`local_baseline`、本仓库输出或空目标字段标成 `external_verified`。
- 不要使用“绝对可信”“世界第一”“完全校准”等过度准确率话术。
允许事项：
- 可以读取 `README.md`、`SKILL.md`、`task_plan.md`、`findings.md`、`progress.md`。
- 可以读取 `docs/research/*round8*`、`docs/research/*round9*` 和本任务单。
- 可以读取 `scripts/oracle_collection_queue.py`、`scripts/oracle_evidence_validator.py`、`scripts/oracle_boundary_audit.py` 和 `references/oracle/dasha_shadbala_oracle_cases.json`。
- 可以运行只读命令：`git status`、`git log`、`git ls-remote`、`find`、`rg`、`python3 ... --format json`、`pytest`。
- 可以联网查询公开对标资料，但只做产品差距和许可证边界分析，不复制代码。
- 只能新增 `docs/research/*round10*2026_06_25.md` 报告文件。
## 必跑命令
### 1. 当前仓库状态
```bash
git status --short --branch
git log --oneline --decorate -n 8
git remote -v
```
### 2. GitHub 远端真实 HEAD
优先用 443 端口，避免普通 SSH 22 端口超时：
```bash
GIT_SSH_COMMAND='ssh -p 443 -o ServerAliveInterval=10 -o ServerAliveCountMax=3' \
git ls-remote ssh://git@ssh.github.com:443/732642856/yinduzhanxing.git \
refs/heads/codex/release-hygiene-ci refs/heads/main
```
必须判断：
- 本地 `HEAD` 是否等于远端 `refs/heads/codex/release-hygiene-ci`。
- 本地 `origin/...` 跟踪引用是否只是没有 fetch 更新。
- 是否有未跟踪文件应归档、提交或忽略。
### 3. 本地高相关碎片扫描
只扫描文件名/路径，不读取私人报告正文：
```bash
for base in \
/Users/wuyongnaren/Documents \
/Users/wuyongnaren/Downloads \
/Users/wuyongnaren/Desktop \
/Users/wuyongnaren/Projects \
/Users/wuyongnaren/WorkBuddy \
/Users/wuyongnaren/.workbuddy \
/Users/wuyongnaren/.codex \
/Users/wuyongnaren/.gemini \
/Users/wuyongnaren/engines-repo \
/Users/wuyongnaren/文件仓库
do
[ -e "$base" ] || continue
echo "### $base"
find "$base" -type d \( \
-name node_modules -o -name .cache -o -name Library -o -name Applications \
-o -name .Trash -o -name .npm -o -name .cargo -o -name .rustup \
-o -name .pyenv -o -name .venv -o -name venv -o -name __pycache__ \
-o -name .pytest_cache -o -name .ruff_cache -o -name dist -o -name build \
\) -prune -o \( \
-iname '*印度占星*' -o -iname '*jyotish*' -o -iname '*yinduzhanxing*' \
-o -iname '*vedic*astro*' -o -iname '*vedastro*' \
-o -iname '*dasha*shadbala*' -o -iname '*antigravity*round*' \
\) -print 2>/dev/null | head -n 200
done
```
### 4. 本地同项目 Git 副本扫描
```bash
find /Users/wuyongnaren -type d -name .git \
\( -path '*/node_modules/*' -o -path '*/Library/*' -o -path '*/.Trash/*' \) -prune \
-o -type d -name .git -print 2>/dev/null \
| sed 's#/.git$##' > /tmp/all_git_repos_round10.txt
while IFS= read -r repo; do
if git -C "$repo" remote -v 2>/dev/null | grep -E '732642856/yinduzhanxing|yinduzhanxing' >/dev/null; then
echo "--- $repo"
git -C "$repo" remote -v
git -C "$repo" status --short --branch | head -n 8
git -C "$repo" log --oneline -n 5 2>/dev/null
fi
done < /tmp/all_git_repos_round10.txt
```
### 5. Oracle / calibration gate 复验
```bash
python3 scripts/oracle_collection_queue.py \
--oracle-file references/oracle/dasha_shadbala_oracle_cases.json \
--format json > /tmp/jyotish_oracle_queue_round10.json
```
```bash
python3 scripts/oracle_evidence_validator.py \
--queue-file /tmp/jyotish_oracle_queue_round10.json
```
```bash
python3 -B -m pytest \
tests/test_oracle_collection_queue.py \
tests/test_oracle_evidence_validator.py \
tests/test_frontend_productization.py::test_dasha_reference_audit_is_documented_and_gated \
-q
```
### 6. Web/App/Skill 透明度静态复核
```bash
rg "ready_for_calibration|Dasha/Shadbala|external_oracle_evidence_validation|calibration|校准|Evidence Validator" \
README.md SKILL.md jyotish-app docs/research -n
```
## 对标任务 A：全球对标项目差距复核
输出文件：
- `docs/research/antigravity_round10_global_benchmark_gap_recheck_2026_06_25.md`
必须参考公开资料并用中文总结：
- VedAstro / VedAstro.Python：公开 README 宣称 596 calculations，MIT license，适合作为 API/AI/MCP 广度对标。
- PyJHora：AGPL-3.0，特性广，适合作为黑盒 oracle/行为参考，不可复制实现代码。
- JHora / Jagannatha Hora：桌面端深度标杆，重点作为截图/人工录入的 Dasha/Shadbala 外部真值来源。
- Hora Prakash 或其他开源网页产品：用于普通用户交付形态、无账号/离线/浏览器体验对标。
输出固定小节：
1. 对标
2. 开源参考
3. Bug
## 本机同步任务 B：本地碎片与主仓差异审计
输出文件：
- `docs/research/antigravity_round10_local_fragment_sync_audit_2026_06_25.md`
必须按表格输出：
| 类别 | 路径 | 状态 | 是否应同步到主仓 | 理由 |
|---|---|---|---|---|
至少覆盖：
- 当前主仓 `/Users/wuyongnaren/Documents/印度占星`
- `.workbuddy/skills/jyotish-vedic-astrology`
- `.gemini/antigravity-ide/.../scratch`
- `Downloads/印度占星*.pdf`
- `Desktop` 上的解盘报告或头像图片
- `WorkBuddy/2026-06-09-20-03-34/jyotish-fragments`
- `Projects/星轨资料恢复/.../jyotish-vedic-astrology`
- `Documents/Codex/.../yinduzhanxing...`
- `Documents/星轨talk/engines-repo/jyotish`
判断口径：
- 产品代码、测试、公开研究报告：可能应同步。
- 私人星盘输出、PDF 原件、Antigravity scratch、临时 stdout：默认不推送。
- 历史 skill 副本：只做差异来源，不直接覆盖当前主仓。
- 下载区压缩包：除非包含新模块且许可证清楚，否则只记录，不纳入主仓。
## 云端同步任务 C：GitHub 状态复核
输出文件：
- `docs/research/antigravity_round10_git_cloud_sync_blackbox_2026_06_25.md`
必须回答：
- `codex/release-hygiene-ci` 远端 HEAD 是什么 commit。
- 本地 HEAD 是什么 commit。
- 本地 `origin/codex-release...` 如果显示 ahead，是否只是 local tracking ref stale。
- 当前未跟踪文件中哪些应该提交，哪些应该保留本地。
- 是否发现其他本机同 remote 的仓库副本存在未同步提交。
## 产品透明度任务 D：Round 9 P0/P1 复核
输出文件：
- `docs/research/antigravity_round10_calibration_transparency_recheck_2026_06_25.md`
必须检查：
- Web/App Trust Center 是否已经展示 Dasha/Shadbala Calibration Status。
- AI Chat 是否已经强制注入 “Dasha/Shadbala 仍在外部 evidence validator 校准中，不做绝对断言”。
- `SKILL.md` 是否明确要求普通用户解释时区分 D1/D9 高可信与 Dasha/Shadbala 待外部校准。
- 若尚未修复，输出 P0/P1/P2 Bug 表。
## 给 Codex 的下一步任务 E
输出文件：
- `docs/research/antigravity_round10_next_codex_fix_queue_2026_06_25.md`
必须给出可执行顺序：
1. 先处理 Git 同步与本地未跟踪 Round 9/Round 10 文档，排除 `output_report.txt`、`results_extracted.md`。
2. 给 Web/App Trust Center 增加 Dasha/Shadbala Calibration Status。
3. 同步 AI Chat prompt boundary 与 `SKILL.md`。
4. 增加静态/前端测试，防止校准状态再次从普通用户界面消失。
5. 继续采集 JHora/PyJHora 黑盒真值，直到至少 3 条 evidence packet 通过 validator。
## 最终回复格式
完成后在 Antigravity 聊天里用中文回复：
1. 已创建哪些 `docs/research/*round10*2026_06_25.md` 文件。
2. 本机是否发现未同步的印度占星文件碎片，哪些应提交、哪些应忽略。
3. GitHub 远端 `codex/release-hygiene-ci` 是否与本地 HEAD 对齐。
4. Web/App/Skill 是否已充分披露 Dasha/Shadbala 校准状态。
5. P0/P1/P2 Bug 总表。
6. 下一步建议给 Codex 的可执行修复事项。
最终报告必须包含三个固定章节：
- 对标
- 开源参考
- Bug
## 公开参考源
- VedAstro.Python GitHub：`https://github.com/VedAstro/VedAstro.Python`
- VedAstro AI Docs：`https://vedastro.org/DocsForAI.html`
- PyJHora GitHub：`https://github.com/naturalstupid/PyJHora`
- JHora 官方页面：`https://www.vedicastrologer.org/jh/`
- Jagannatha Hora 新站：`https://jagannathahora.com/`
- Hora Prakash GitHub：`https://github.com/PriyankGahtori/hora-prakash`
progress.md
+6 -1
View File
@@ -336,4 +336,9 @@
- 完成 Antigravity Round 7 副手任务单：新增 `docs/research/antigravity_sidecar_work_order_round7_2026_06_25.md`，要求副手复核 evidence validator、quick/release 质量门接入、external_verified 晋级清单和用户准确率话术。
- 修复 external_verified 晋级路径：`scripts/oracle_collection_queue.py` 现在保留 oracle JSON 中已填的 `evidence_packet.status/metadata` 和目标值，新增 `target_fields`，避免外部证据包被重新降级为 `draft`；`scripts/oracle_evidence_validator.py` 改为用 `target_fields` 校验已填目标，兼容旧 draft 队列。
- 完成 Antigravity Round 8 副手任务单：新增 `docs/research/antigravity_sidecar_work_order_round8_2026_06_25.md`，要求副手黑盒复验 external_verified 晋级链路，并输出相对 VedAstro/PyJHora/JHora 的全球差距矩阵。
- 当前下一最高优先级：跑聚焦测试和 quick 质量门；随后推进网页/app Trust Center 暴露 Dasha/Shadbala calibration status，避免普通用户误解“已完全校准”。
- 完成 GitHub 远端真实 HEAD 复核：`git ls-remote ssh://git@ssh.github.com:443/732642856/yinduzhanxing.git` 显示远端 `codex/release-hygiene-ci` 为 `912867f2ec35ce13f757fb0362da6bced9edf404`，与本地主分支 HEAD 一致；本地 `origin/... [gone]` 是 22 端口 fetch 失败后的跟踪引用异常，已用 `git update-ref` 按远端真实 HEAD 修复。
- 完成地毯式本机碎片扫描第一轮：高相关路径约 297 条，主要分布在当前主仓、`.workbuddy/skills/jyotish-vedic-astrology` 旧 skill 副本、`.gemini/antigravity-ide` scratch、Downloads PDF/压缩包、Desktop 私人报告、WorkBuddy 历史碎片、Projects 恢复目录、Documents/Codex 历史审计与 `Documents/星轨talk/engines-repo/jyotish`。
- 同项目 Git 副本扫描结论：除当前主仓外，发现 `.workbuddy/skills/jyotish-vedic-astrology` 指向同一远端但停在 `main@4ff6248`，仅 `references/validation_logic_report.json` 有排序类本地修改；该副本作为历史 skill/基线来源，不直接覆盖当前主仓。
- 私人输出同步边界：`output_report.txt` 和 `results_extracted.md` 是用户个人星盘复验临时输出，已加入 `.gitignore`，默认不纳入 GitHub 同步。
- 完成 Antigravity Round 10 副手任务单：新增 `docs/research/antigravity_sidecar_work_order_round10_2026_06_25.md`，要求副手复核整机碎片/Git 云端同步、Round 9 校准透明度 P0/P1、全球对标差距，并只产出 `docs/research/*round10*2026_06_25.md` 报告。
- 当前下一最高优先级：提交并推送 Round 9 副手报告、Round 10 任务单和私人输出忽略规则；随后推进网页/app Trust Center 暴露 Dasha/Shadbala calibration status，避免普通用户误解“已完全校准”。