chore: 升级 Trellis 并精简规则（09-05-trellis-upgrade-rule-cleanup）
这个提交包含在：
@@ -1,98 +1,15 @@
|
||||
---
|
||||
name: trellis-check
|
||||
description: "Comprehensive quality verification: spec compliance, lint, type-check, tests, cross-layer data flow, code reuse, and consistency checks. Use when code is written and needs quality verification, before committing changes, or to catch context drift during long sessions."
|
||||
description: "Verify the current task diff against its acceptance criteria and affected-layer contracts. Use after implementation or before an authorized commit, not for unrelated repository cleanup."
|
||||
---
|
||||
|
||||
# Code Quality Check
|
||||
# Task-Scoped Quality Check
|
||||
|
||||
Comprehensive quality verification for recently written code. Combines spec compliance, cross-layer safety, and pre-commit checks.
|
||||
1. Identify files changed by this task. Git dirty state is evidence, not permission to include other work.
|
||||
2. Read acceptance criteria and applicable quality contracts not already loaded. Check the complete task diff, not only the last chunk.
|
||||
3. Run the minimum meaningful checks: targeted regressions for behavior changes, relevant syntax/type/build checks for affected layers, and governance/reference checks for rules. Expand for shared contracts and cross-layer risks.
|
||||
4. Verify permissions, state transitions, error handling, data flow and tests when affected. Review abstractions and fallback behavior only where the task changes them.
|
||||
5. Fix task-caused failures and rerun affected checks. Report pre-existing failures separately; do not repair unrelated business code. Reuse passing checks whose inputs remain unchanged.
|
||||
6. Report what passed, failed, was not run and why. Distinguish static checks, runtime tests, independent review and public deployment. Never claim a separate reviewer when only the main session checked.
|
||||
|
||||
---
|
||||
|
||||
## Step 1: Identify What Changed
|
||||
|
||||
```bash
|
||||
git diff --name-only HEAD
|
||||
git status
|
||||
```
|
||||
|
||||
## Step 2: Read Task Artifacts and Applicable Specs
|
||||
|
||||
Read the current task artifacts in order:
|
||||
|
||||
- `prd.md`
|
||||
- `design.md` if present
|
||||
- `implement.md` if present
|
||||
|
||||
```bash
|
||||
python3 ./.trellis/scripts/get_context.py --mode packages
|
||||
```
|
||||
|
||||
For each changed package/layer, read the spec index and follow its **Quality Check** section:
|
||||
|
||||
```bash
|
||||
cat .trellis/spec/<package>/<layer>/index.md
|
||||
```
|
||||
|
||||
Read the specific guideline files referenced — the index is a pointer, not the goal.
|
||||
|
||||
## Step 3: Run Project Checks
|
||||
|
||||
Run the project's lint, type-check, and test commands. Fix any failures before proceeding.
|
||||
|
||||
## Step 4: Review Against Checklist
|
||||
|
||||
### Code Quality
|
||||
|
||||
- [ ] Linter passes?
|
||||
- [ ] Type checker passes (if applicable)?
|
||||
- [ ] Tests pass?
|
||||
- [ ] No debug logging left in?
|
||||
- [ ] No suppressed warnings or type-safety bypasses?
|
||||
|
||||
### Test Coverage
|
||||
|
||||
- [ ] New function → unit test added?
|
||||
- [ ] Bug fix → regression test added?
|
||||
- [ ] Changed behavior → existing tests updated?
|
||||
|
||||
### Spec Sync
|
||||
|
||||
- [ ] Does `.trellis/spec/` need updates? (new patterns, conventions, lessons learned)
|
||||
|
||||
> "If I fixed a bug or discovered something non-obvious, should I document it so future me won't hit the same issue?" → If YES, update the relevant spec doc.
|
||||
|
||||
## Step 5: Cross-Layer Dimensions (if applicable)
|
||||
|
||||
Skip this step if your change is confined to a single layer.
|
||||
|
||||
### A. Data Flow (changes touch 3+ layers)
|
||||
|
||||
- [ ] Read flow traces correctly: Storage → Service → API → UI
|
||||
- [ ] Write flow traces correctly: UI → API → Service → Storage
|
||||
- [ ] Types/schemas correctly passed between layers?
|
||||
- [ ] Errors properly propagated to caller?
|
||||
|
||||
### B. Code Reuse (modifying constants, creating utilities)
|
||||
|
||||
- [ ] Searched for existing similar code before creating new?
|
||||
```bash
|
||||
grep -r "pattern" src/
|
||||
```
|
||||
- [ ] If 2+ places define same value → extracted to shared constant?
|
||||
- [ ] After batch modification, all occurrences updated?
|
||||
|
||||
### C. Import/Dependency (creating new files)
|
||||
|
||||
- [ ] Correct import paths (relative vs absolute)?
|
||||
- [ ] No circular dependencies?
|
||||
|
||||
### D. Same-Layer Consistency
|
||||
|
||||
- [ ] Other places using the same concept are consistent?
|
||||
|
||||
---
|
||||
|
||||
## Step 6: Report and Fix
|
||||
|
||||
Report violations found and fix them directly. Re-run project checks after fixes.
|
||||
Run one final task-wide acceptance pass before handoff. Do not repeat full-repository tests each iteration or require deployment for pure rules, documentation or local tooling. Capture reusable contracts in the existing spec only when they add value.
|
||||
|
||||
在新工单中引用
屏蔽一个用户