chore(en): remove extra files to align with zh structure

- Remove Learning Experience.md from 02-methodology - Remove telegram-dev/ from 02-methodology - Remove fate-engine-dev/ from 03-practice - Update 02-methodology README
2026-08-15 03:48:04 +00:00 · 2025-12-19 03:24:56 +08:00
parent fbef741768
commit d178f4f8b6
7 changed files with 0 additions and 119 deletions
@@ -1,21 +0,0 @@
-# 🔮 fate-engine-dev
-
-> Practical experience in developing a numerology engine
-
-## Project Background
-
-A calculation engine based on Bazi numerology, involving complex logic such as Heavenly Stems and Earthly Branches, true solar time, and the strength of the Five Elements.
-
-## Document List
-
-| File | Description |
-|:---|:---|
-| [True Solar Time Correction Experience.md](./True%20Solar%20Time%20Correction%20Experience.md) | Pitfalls of true solar time calculation and correction solutions |
-| [production_incident_2025-12-17_strong_weak.md](./production_incident_2025-12-17_strong_weak.md) | Production incident record: Five Elements strength calculation issue |
-| [Telegram Markdown Code Block Format Fix Log 2025-12-15.md](./Telegram%20Markdown%20Code%20Block%20Format%20Fix%20Log%202025-12-15.md) | Telegram output format issue fix |
-
-## Tech Stack
-
- Python
- Astronomical algorithm library
- Telegram Bot API
@@ -1,32 +0,0 @@
-# True Solar Time Correction Experience (2025-12-16)
-
-## Background
- Feedback from Xinjiang users: The report shows "solar calendar minus 2 hours, true solar time again minus 2 hours", resulting in inconsistencies in Four Pillars/Deities with comparison tools.
- Root cause: Birth time was calculated once for true solar time by the caller, and then calculated again within `BaziCalculator`, forming a "double deduction".
-
-## Current Strategy (Live)
- **Single Correction Point**: All true solar time corrections are performed only once within `BaziCalculator`.
- **Time Baseline**: Entry birth time is uniformly treated as Beijing Time (Asia/Shanghai), and then true solar time correction is performed after assigning the time zone with `ensure_cn`.
- **Calculation Time**: Core and extended modules are all based on `calc_dt` (true solar time or original Beijing time if user disables), maintaining consistency.
- **Display Time**: UI/progress/logs/queue/Help uniformly use Beijing Time; report field `trueSolarTime` displays the time after longitude correction.
-
-## Involved Changes (Key Points)
- `utils/timezone.py`: `now_cn/ensure_cn/fmt_cn` fixed to Asia/Shanghai.
- `bot.py`: Removed outer layer `calc_true_solar_time`; time display uses `fmt_cn(now_cn())`; queue timestamp uses Beijing Time.
- `main.py`: API no longer pre-corrects; `trueSolarTime` is taken from `BaziCalculator` internal results.
- `bazi_calculator.py`: Added `use_true_solar_time`, unified `calc_dt`; extended modules/Ming Gua/Xiao Yun, etc., now use `calc_dt`; metadata time uses Beijing Time.
- `liuyao.py`, `qimen.py`, `system_optimization.py`: Timestamps unified to Beijing Time.
- Documentation: `AGENTS.md` records "Time zone unified to Asia/Shanghai".
-
-## Abstract Problems and Prevention
-1.  **Inconsistent Time Zone Assumptions**: Naive datetime will drift if parsed locally; uniformly assume "input is Beijing Time", first supplement time zone, then calculate.
-2.  **Duplicate Correction**: True solar time formula is only allowed to appear once; secondary correction is strictly prohibited in the call chain.
-3.  **Mixed Baselines**: Display uses Beijing Time, calculation uses true solar time (single correction). If a new module is added, `calc_dt` must be reused, no self-calculation is allowed.
-
-## Verification Suggestions
- Run a Xinjiang example (Urumqi 87E, 08:00): Solar calendar should remain 08:00, Beijing time displays 08:00, true solar time approx. 05:4x, only deducted once.
- Compare Four Pillars/Deities with comparison tools such as "Cece", should be consistent.
-
-## Subsequent Guidelines
- If UTC/other time zones need to be provided externally, first convert to Beijing time, then calculate true solar time based on longitude, still only correcting once.
- When adding new integration modules, it is forbidden to repeatedly calculate true solar time; uniformly accept `calc_dt`.
@@ -1,16 +0,0 @@
-# Production Incident Record: Strong/Weak Self-Assessment Standard Conflict
-
-   **Date**: 2025-12-17
-   **Impact**: Users reported contradictions in "strength judgment: slightly weak" and "strong self-assessment: strong" for the same Bazi chart, leading to misleading advice on favorable elements and a decrease in trust.
-   **Root Cause**: The code simultaneously output two sets of strength/weakness algorithm results—
-    -   External library bazi-1 weak determination (`_calc_wuxing_scores.weakStrong`, including Changsheng/Diwang weights).
-    -   Local self-written simplified algorithm `_calc_strength` (only counts Three Pillars' mutual generation and overcoming).
-    Both were displayed in the report, leading to inconsistent standards.
-   **Resolution**: Removed local `_calc_strength` usage, unified to external library's weak determination as the sole source; report standards were unified accordingly.
-   **Code Change**: `services/telegram-service/src/bazi_calculator.py`
-    -   `strength` only takes `wx_scores['weakStrong']`; deleted `_calc_strength` call and implementation.
-   **Subsequent Actions**:
-    1.  Regression testing: Randomly check 10 Bazi charts to confirm a single strong/weak standard consistent with bazi-1's original output.
-    2.  Add unit tests: Verify abnormal prompts when `weakStrong` is absent (currently no fallback).
-    3.  Review other indicators (e.g., favorable elements, patterns) for potential dual-standard outputs.
-    4.  **Mandatory Specification**: Forbid the introduction of any "self-written alternative algorithms" for core judgments (body strength/weakness, favorable elements, deities, patterns, etc.); must directly call the calculation results of external native libraries. Violators will be considered to have crossed a production red line.