- Context: 仓库原有文档、包元数据和构建资产策略彼此不一致，容易误导后续维护。
- Decision: 统一版本为
v1.0.0 Release，默认依赖工作流为uv，同时补requirements.txt保留pip兼容安装。 - Why: 既保留当前真实依赖源头，又避免旧环境或外部使用者完全失去
pip安装入口。 - Action/Command: 新增
requirements.txt与LICENSE，同步更新pyproject.toml、.gitignore、AGENTS.md、README。 - Verification: 依赖清单按
pyproject.toml对齐，SplitGrid.spec不再被.gitignore忽略。 - Follow-up: README 需要继续保持“用户文档”定位，项目约束和维护规则继续放在
AGENTS.md。
- Context: README 和包元数据已统一到
v1.0.0 Release，但帮助文档、首页 footer 与 About 弹窗仍保留v1.0。 - Decision: 应用内所有直接面向用户的版本文案同步改为
v1.0.0 Release。 - Why: 正式版发布时，应用内外版本口径必须一致，避免用户在界面上看到旧版号。
- Action/Command: 更新
docs/help.md、ui/home_interface.py、ui/main_window.py的版本文本。 - Verification: 帮助文档标题、帮助正文、首页 footer、About 弹窗版本号已统一。
- Follow-up: 下次正式版发布时，统一检查 README、帮助文档、首页 footer、About 弹窗和
pyproject.toml。
- Context: Git 历史中曾出现
3.0-alpha一类旧版本命名，需要确认它是否仍影响当前项目文本。 - Decision: 当前工作树中的正式口径保持
v1.0.0 Release；Git 历史里出现的3.0-alpha、更早开发期版本名，统一视为开发阶段命名，不再作为当前产品版本语义的一部分。 - Why: 历史提交标题和旧 UI 文案会误导后续版本梳理，需要一个明确解释口径。
- Action/Command: 核对
git log与历史文件内容，确认ui/main_window.py、ui/home_interface.py的旧版本文案只存在于历史提交，不存在于当前工作树。 - Verification: 当前仓库文本未检出
3.0-alpha/3.0.0alpha；历史提交中确认出现过版本: 3.0-alpha与SplitGrid v3.0-alpha。 - Follow-up: 以后讨论版本演进时，默认将
3.0-alpha等表述归类为 UI 重构期的开发版本，而非正式发布序列。
- Context: 历史 Git 中同时出现过
2.0、3.0-alpha等旧命名，但当前软著申报需要以1.0.0作为正式版本起点。 - Decision: 自软著申报口径起，项目正式发布序列从
v1.0.0 Release开始；后续版本正常递增，历史旧命名不再参与当前正式版本比较。 - Why: 继续沿用历史内部命名会和软著、README、UI 文案、包元数据发生长期冲突。
- Action/Command: 将规则写入
AGENTS.md，要求未来正式版和预发布版统一使用语义化版本及其标准预发布后缀。 - Verification: 当前项目约束已明确
v1.0.0 Release为正式起点，历史2.0/3.0-alpha被归档为内部开发阶段命名。 - Follow-up: 下次进入开发版时，直接使用
1.0.1-dev或1.1.0-alpha.1等形式，不再创造脱离正式序列的独立大版本名。
- Context: 当前远端结构为
dev领先于master，且平台提示可无冲突合并。 - Decision:
dev作为默认开发分支，日常开发与整理工作都先进入dev；master作为稳定发布分支，默认不直接手动开发，而是等待从dev合并。 - Why: 这样可以保持
master稳定，并让每次进入主分支的改动都具备完整主题和可审阅性。 - Action/Command: 当前两笔提交先进入
dev，后续通过远端合并进入master。 - Verification: 远端已存在
origin/dev与origin/master的明确分流状态，且dev可无冲突合并到master。 - Follow-up: 除紧急修复外，后续默认不要直接在
master上做日常改动；若master发生热修复，需同步回补到dev。