From d178f4f8b6863d2ada462b3ab49a971d2c42ea26 Mon Sep 17 00:00:00 2001 From: tukuaiai Date: Fri, 19 Dec 2025 03:24:56 +0800 Subject: [PATCH] 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 --- .../02-methodology/Learning Experience.md | 5 --- i18n/en/documents/02-methodology/README.md | 2 - ...wn_Code_Block_Format_Fix_Log_2025_12_15.md | 43 ------------------- .../03-practice/fate-engine-dev/README.md | 21 --------- .../True Solar Time Correction Experience.md | 32 -------------- ...duction_incident_2025-12-17_strong_weak.md | 16 ------- ...wn Code Block Format Fix Log 2025-12-15.md | 0 7 files changed, 119 deletions(-) delete mode 100644 i18n/en/documents/02-methodology/Learning Experience.md delete mode 100644 i18n/en/documents/02-methodology/telegram-dev/telegram_Markdown_Code_Block_Format_Fix_Log_2025_12_15.md delete mode 100644 i18n/en/documents/03-practice/fate-engine-dev/README.md delete mode 100644 i18n/en/documents/03-practice/fate-engine-dev/True Solar Time Correction Experience.md delete mode 100644 i18n/en/documents/03-practice/fate-engine-dev/production_incident_2025-12-17_strong_weak.md delete mode 100644 i18n/en/documents/03-practice/fate-engine-dev/telegram Markdown Code Block Format Fix Log 2025-12-15.md diff --git a/i18n/en/documents/02-methodology/Learning Experience.md b/i18n/en/documents/02-methodology/Learning Experience.md deleted file mode 100644 index 277a53d..0000000 --- a/i18n/en/documents/02-methodology/Learning Experience.md +++ /dev/null @@ -1,5 +0,0 @@ -The texts that impressed me the most - -Huangdi Yinfu Jing: Sever the benefit from one source, and use the master ten times. Three repetitions day and night, and use the master ten thousand times. - -Douyin says: People are driven by profit; great profit leads to great deeds, small profit to small deeds, and no profit to no deeds. diff --git a/i18n/en/documents/02-methodology/README.md b/i18n/en/documents/02-methodology/README.md index 39e0d42..38ceb8d 100644 --- a/i18n/en/documents/02-methodology/README.md +++ b/i18n/en/documents/02-methodology/README.md @@ -9,6 +9,4 @@ Tools, tutorials, and development guides. - [auggie-mcp Configuration Document](./auggie-mcp%20Configuration%20Document.md) - [SSH via Mobile with FRP](./How%20to%20SSH%20to%20Local%20Computer%20from%20Any%20Location%20via%20Mobile%2C%20Based%20on%20FRP%20Implementation.md) - [Gemini Headless Mode Translation Guide](./Gemini%20Headless%20Mode%20Translation%20Guide.md) -- [Learning Experience](./Learning%20Experience.md) - [Vibe Coding Experience Collection](./vibe-coding-experience-collection.md) -- [telegram-dev/](./telegram-dev/) - Telegram development resources diff --git a/i18n/en/documents/02-methodology/telegram-dev/telegram_Markdown_Code_Block_Format_Fix_Log_2025_12_15.md b/i18n/en/documents/02-methodology/telegram-dev/telegram_Markdown_Code_Block_Format_Fix_Log_2025_12_15.md deleted file mode 100644 index fb79530..0000000 --- a/i18n/en/documents/02-methodology/telegram-dev/telegram_Markdown_Code_Block_Format_Fix_Log_2025_12_15.md +++ /dev/null @@ -1,43 +0,0 @@ -# Telegram Markdown Code Block Format Fix Log 2025-12-15 - -## Problem - -After completing the astrological chart generation, sending a message reports an error: -``` -❌ Chart generation failed: Can't parse entities: can't find end of the entity starting at byte offset 168 -``` - -## Cause - -The Markdown code block format for the `header` message in `bot.py` is incorrect. - -The original code used string concatenation, adding `\n` after ```, which caused the Telegram Markdown parser to incorrectly identify the code block boundary: - -```python -# Incorrect way -header = ( - "```\n" - f"{filename}\n" - "```\n" -) -``` - -## Fix - -Changed to a triple-quoted string to ensure ``` is on a separate line: - -```python -# Correct way -header = f"""Report attached -``` -{filename} -{ai_filename} -``` -""" -``` - -## Modified File - -- `services/telegram-service/src/bot.py` lines 293-308 - -``` \ No newline at end of file diff --git a/i18n/en/documents/03-practice/fate-engine-dev/README.md b/i18n/en/documents/03-practice/fate-engine-dev/README.md deleted file mode 100644 index f0c97c4..0000000 --- a/i18n/en/documents/03-practice/fate-engine-dev/README.md +++ /dev/null @@ -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 diff --git a/i18n/en/documents/03-practice/fate-engine-dev/True Solar Time Correction Experience.md b/i18n/en/documents/03-practice/fate-engine-dev/True Solar Time Correction Experience.md deleted file mode 100644 index a85984e..0000000 --- a/i18n/en/documents/03-practice/fate-engine-dev/True Solar Time Correction Experience.md +++ /dev/null @@ -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`. diff --git a/i18n/en/documents/03-practice/fate-engine-dev/production_incident_2025-12-17_strong_weak.md b/i18n/en/documents/03-practice/fate-engine-dev/production_incident_2025-12-17_strong_weak.md deleted file mode 100644 index 2b87770..0000000 --- a/i18n/en/documents/03-practice/fate-engine-dev/production_incident_2025-12-17_strong_weak.md +++ /dev/null @@ -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. diff --git a/i18n/en/documents/03-practice/fate-engine-dev/telegram Markdown Code Block Format Fix Log 2025-12-15.md b/i18n/en/documents/03-practice/fate-engine-dev/telegram Markdown Code Block Format Fix Log 2025-12-15.md deleted file mode 100644 index e69de29..0000000