admin343/browser
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: 自动更新

Browse Source
This commit is contained in:
npc0-hue
2026-07-15 19:43:06 +08:00
parent f64eb0831f
commit f3b14b7945
54 changed files with 3207 additions and 589 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+4 -12
View File
@@ -10,12 +10,6 @@ The platform's required first-party areas are 首页、服务器管理、插件
The platform_web visual direction is a unified magical-girl crystal-moonlight game operations console. Preserve the style rules in `platform_web/AGENTS.md` and `platform_web/theme/README.md`; do not replace it with generic opaque SaaS cards or unrelated visual systems without a future OpenSpec change. Global magical ultimate effects belong in `platform_web/components/MagicalParticleLayer.tsx`, not in page-local fixed decoration spans or one-off backdrop CSS.
## Frontend Design and Browser Tools
For frontend work, agents are allowed and encouraged to use [@浏览器](plugin://browser@openai-bundled) to automatically open local frontend pages, inspect UI behavior, debug visual issues, and perform browser walkthrough verification.
For frontend design work, agents are allowed and encouraged to use [$design-taste-frontend](/Users/tasia/.agents/skills/design-taste-frontend/SKILL.md) as a design review and implementation aid. Apply it in support of this repository's existing platform_web visual direction and local theme rules; it must not override the magical-girl crystal-moonlight game operations console style without a future OpenSpec change.
## Project Roots
- `platform/` contains backend platform code.
@@ -28,10 +22,10 @@ Do not place implementation code outside the matching root. Shared contracts mus
## OpenSpec Rules
- Every non-trivial change must start with an OpenSpec change under `openspec/changes/`.
- Update proposal/design/specs/tasks before implementation when behavior, architecture, or validation rules change.
- Do not mark tasks complete until their verification evidence exists.
- Run `openspec validate <change> --strict` before completion.
- Use judgment before creating an OpenSpec change. Create one when the work changes behavior, architecture, public/API contracts, validation rules, persistence, security boundaries, cross-root workflows, or the required product/visual direction.
- OpenSpec is not required for small scoped bug fixes, copy/documentation updates, tests, local refactors without behavior change, or styling/label fixes that preserve the existing visual system. For those, reason through the steps, make the edit directly, and report the verification performed.
- If an OpenSpec change is created, update proposal/design/specs/tasks before implementation when behavior, architecture, or validation rules change.
- If an OpenSpec change is created, do not mark its tasks complete until verification evidence exists, and run `openspec validate <change> --strict` before completion.
## Structure Rules
@@ -88,5 +82,3 @@ scripts/check-structure.sh
```
If you add or change a structural rule, update `scripts/check-structure.sh` in the same change.
If work touches frontend pages, use a browser walkthrough before claiming the UI is accepted.