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

i18n/en/documents/02-methodology/Learning Experience.md

@@ -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.

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

i18n/en/documents/02-methodology/telegram-dev/telegram_Markdown_Code_Block_Format_Fix_Log_2025_12_15.md

@@ -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
-
-```

i18n/en/documents/03-practice/fate-engine-dev/README.md

@@ -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

i18n/en/documents/03-practice/fate-engine-dev/True Solar Time Correction Experience.md

@@ -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`.

i18n/en/documents/03-practice/fate-engine-dev/production_incident_2025-12-17_strong_weak.md

@@ -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.