更新web版本

.cursor/commands/openspec-apply.md

@@ -0,0 +1,23 @@
+---
+name: /openspec-apply
+id: openspec-apply
+category: OpenSpec
+description: 实施已批准的 OpenSpec 变更并保持任务同步。
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+Track these steps as TODOs and complete them one by one.
+1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
+2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
+3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
+4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
+5. Reference `openspec list` or `openspec show <item>` when additional context is required.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
+<!-- OPENSPEC:END -->

.cursor/commands/openspec-archive.md

@@ -0,0 +1,27 @@
+---
+name: /openspec-archive
+id: openspec-archive
+category: OpenSpec
+description: 归档已部署的 OpenSpec 变更并更新规范。
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+1. Determine the change ID to archive:
+   - If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
+   - If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
+   - Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
+   - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
+2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
+3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
+4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
+5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
+
+**Reference**
+- Use `openspec list` to confirm change IDs before archiving.
+- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
+<!-- OPENSPEC:END -->

.cursor/commands/openspec-proposal.md

@@ -0,0 +1,27 @@
+---
+name: /openspec-proposal
+id: openspec-proposal
+category: OpenSpec
+description: 搭建新的 OpenSpec 变更并进行严格验证。
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
+
+**Steps**
+1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
+2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
+3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
+4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
+5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
+6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
+7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
+- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
+- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
+<!-- OPENSPEC:END -->

.devcontainer/Dockerfile

@@ -1,4 +1,4 @@
-ARG DOCKER_TAG=latest
+ARG DOCKER_TAG=v5.3.2
 FROM espressif/idf:${DOCKER_TAG}
 
 ENV LC_ALL=C.UTF-8

.github/workflows/release.yml

@@ -0,0 +1,82 @@
+name: Build and Release
+
+on:
+  push:
+    tags:
+      - 'v*'  # 匹配 v 开头的标签，如 v1.0.0
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Get tag name
+        id: tag
+        run: echo "name=${GITHUB_REF#refs/tags/}" >> $GITHUB_OUTPUT
+
+      - name: Build MOTORS_4 version
+        uses: espressif/esp-idf-ci-action@v1
+        with:
+          esp_idf_version: v5.3.2
+          target: esp32c3
+          command: |
+            idf.py build -DMOTOR_CONFIG=MOTORS_4 && \
+            python -m esptool --chip esp32c3 merge_bin -o Top-AMS-MOTORS_4.bin \
+              --flash_mode dio --flash_freq 80m --flash_size 4MB \
+              0x0 build/bootloader/bootloader.bin \
+              0x10000 build/Top-AMS.bin \
+              0x8000 build/partition_table/partition-table.bin && \
+            rm -rf build
+
+      - name: Build MOTORS_6 version
+        uses: espressif/esp-idf-ci-action@v1
+        with:
+          esp_idf_version: v5.3.2
+          target: esp32c3
+          command: |
+            idf.py build -DMOTOR_CONFIG=MOTORS_6 && \
+            python -m esptool --chip esp32c3 merge_bin -o Top-AMS-MOTORS_6.bin \
+              --flash_mode dio --flash_freq 80m --flash_size 4MB \
+              0x0 build/bootloader/bootloader.bin \
+              0x10000 build/Top-AMS.bin \
+              0x8000 build/partition_table/partition-table.bin && \
+            rm -rf build
+
+      - name: Build MOTORS_8 version
+        uses: espressif/esp-idf-ci-action@v1
+        with:
+          esp_idf_version: v5.3.2
+          target: esp32c3
+          command: |
+            idf.py build -DMOTOR_CONFIG=MOTORS_8 && \
+            python -m esptool --chip esp32c3 merge_bin -o Top-AMS-MOTORS_8.bin \
+              --flash_mode dio --flash_freq 80m --flash_size 4MB \
+              0x0 build/bootloader/bootloader.bin \
+              0x10000 build/Top-AMS.bin \
+              0x8000 build/partition_table/partition-table.bin
+
+      - name: Create Release
+        uses: softprops/action-gh-release@v1
+        with:
+          tag_name: ${{ steps.tag.outputs.name }}
+          name: Release ${{ steps.tag.outputs.name }}
+          body: |
+            ## 版本说明
+
+            本次发布包含以下三个版本的固件：
+            - **MOTORS_4**: 4通道版本
+            - **MOTORS_6**: 6通道版本
+            - **MOTORS_8**: 8通道版本（其它）
+
+            ## 使用说明
+
+            请根据您的硬件配置选择对应的固件进行刷入。
+          files: |
+            Top-AMS-MOTORS_4.bin
+            Top-AMS-MOTORS_6.bin
+            Top-AMS-MOTORS_8.bin
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.gitignore

@@ -6,4 +6,5 @@ managed_components/
 localconfig.hpp
 temp/
 main/index.hpp
-Top-AMS.bin
+Top-AMS.bin
+.DS_Store

AGENTS.md

@@ -0,0 +1,18 @@
+<!-- OPENSPEC:START -->
+# OpenSpec Instructions
+
+These instructions are for AI assistants working in this project.
+
+Always open `@/openspec/AGENTS.md` when the request:
+- Mentions planning or proposals (words like proposal, spec, change, plan)
+- Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work
+- Sounds ambiguous and you need the authoritative spec before coding
+
+Use `@/openspec/AGENTS.md` to learn:
+- How to create and apply change proposals
+- Spec format and conventions
+- Project structure and guidelines
+
+Keep this managed block so 'openspec update' can refresh the instructions.
+
+<!-- OPENSPEC:END -->

RELEASE_NOTES.md

@@ -0,0 +1,51 @@
+# Release Notes
+
+## 版本信息
+- **版本号**: v{{VERSION}}
+- **发布日期**: {{DATE}}
+- **固件版本**: {{FIRMWARE_VERSION}}
+
+## 更新内容
+
+### 🎉 新功能
+- 
+
+### 🐛 问题修复
+- 
+
+### ⚡ 性能优化
+- 
+
+### 📝 文档更新
+- 
+
+### 🔧 配置变更
+- 
+
+## 升级说明
+
+### 重要提示
+- 
+
+### 兼容性
+- 支持的打印机型号: A1 mini, A1, P1S
+- 支持的固件版本: 1.04.00及以上
+
+### 升级步骤
+1. 下载最新固件文件
+2. 使用 ESP-IDF 工具刷入固件
+3. 重启设备
+4. 检查 Web 界面是否正常
+
+## 下载
+- 固件文件: [下载链接]({{RELEASE_URL}})
+
+## 反馈
+如有问题或建议，请通过以下方式反馈：
+- GitHub Issues
+- QQ群: 8820913⑨九
+
+
+
+
+