#!/usr/bin/env python3
"""记录今天的日记和经验总结"""
import os
import sys
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'diary_system.settings')
sys.path.insert(0, '/root/.openclaw/workspace/diary-system/backend')

import django
django.setup()

from diary.models import DiaryEntry, Experience
from datetime import date

# ============ 创建日记 ============
today = date.today()
entry, created = DiaryEntry.objects.get_or_create(date=today)

entry.title = "教训深刻的一天 - 丢失功能的警示"
entry.completed_tasks = """- 开发日记系统 Web 版本
- 添加经验总结模块
- 部署到云服务器
- 创建软件需求文档
- 配置双 git 仓库同步"""

entry.learned = """- Git 版本控制的重要性
- 修改前必须先备份
- 功能清单必须维护
- 小步迭代，多次验证
- 不确定时先问用户"""

entry.problems = """- 修改前端时覆盖了原有的日历组件
- 没有查看现有代码就直接修改
- 没有功能清单对照
- 修改后没有验证所有功能
- 导致用户多次要求回退版本"""

entry.reflections = """这是一个严重的工程习惯问题。作为开发者，应该：
1. 敬畏现有代码 - 每行代码都有价值
2. 先理解再修改 - 不要盲目覆盖
3. 小步快跑 - 每次只改一点，立即验证
4. 文档先行 - 功能清单、需求文档必须维护
5. 用户沟通 - 不确定时先问，不要自作主张

今天的错误虽然造成了时间浪费，但换来了深刻的教训，值得记录。"""

entry.improvements = """1. 创建了 FEATURES.md 功能清单
2. 创建了 DEV_GUIDE.md 开发规范
3. 创建了 REQUIREMENTS.md 需求文档
4. 建立了修改前的备份流程
5. 建立了修改后的验证清单"""

entry.plans = """- 严格执行开发规范
- 每次修改前查看功能清单
- 使用 git 分支开发
- 修改后对照清单验证
- 定期回顾今天的教训"""

entry.save()
print(f"✅ 日记已保存：{entry.date}")

# ============ 创建经验总结 ============
exp = Experience.objects.create(
    title="修改前端时丢失日历功能的教训",
    category="development",
    problem="""在添加经验总结板块时，直接覆盖了 frontend/index.html，导致已有的日历组件丢失。
用户发现后要求回退版本，来回折腾了 3 次才恢复到正确的版本。

具体问题：
1. 没有先查看现有代码
2. 没有功能清单对照
3. 没有使用 git 分支开发
4. 修改后没有验证所有功能
5. 自作主张添加了不需要的功能""",
    solution="""1. 立即使用 git restore 恢复文件
2. 回退到正确的 commit (4aeb21c)
3. 同步到云服务器
4. 创建功能清单和开发规范
5. 建立修改前后的检查流程

长期解决方案：
- 维护 FEATURES.md 功能清单
- 维护 DEV_GUIDE.md 开发规范
- 修改前创建 git 备份分支
- 使用功能分支开发
- 修改后对照清单验证""",
    lesson_learned="""📌 核心教训：
1. **敬畏现有代码** - 每行代码都有它的价值，不要随意覆盖
2. **先理解再修改** - 修改前必须先查看现有代码和功能
3. **小步迭代** - 每次只改一个功能，立即验证
4. **文档先行** - 功能清单、需求文档必须在开发前维护
5. **用户沟通** - 不确定时先问用户，不要自作主张
6. **版本控制** - 善用 git 分支和回滚功能

💡 这个教训的价值远超今天浪费的时间，它会成为以后开发中的警示灯。"""
)

print(f"✅ 经验总结已保存：{exp.title}")
print(f"   类别：{exp.get_category_display()}")