wangsli
729d90576f
更新Trellis适配、任务归属与归档失败恢复，精简技能入口和知识读取规则。 保留权限、证据、事务及独立复核合同；纳入对应任务及已完成复核记录。 仅本地提交，不启用新平台适配，不推送或部署。
2.3 KiB
name, description
| name | description |
|---|---|
| trellis-update-spec | Maintain an existing spec when a verified change reveals a reusable contract, convention or pitfall; exclude routine status and run logs. |
Maintain Reusable Contracts
First decide whether there is a new, supported lesson worth retaining. No spec edit is needed when the contract is already documented, evidence is inconclusive or the fact belongs only to this run. Model upgrades alone are not evidence that a business safeguard is obsolete.
Use the package index and heading search to locate the owning section. Read its applicable contract and references before editing. Update or consolidate that section; create a new one only for a distinct concept. Keep business facts in the existing docs owner, executable development rules in spec, and thinking prompts in guides that point to those rules. Do not replicate the same contract in each layer.
Preserve concrete depth when commands/APIs, schemas, infrastructure or cross-layer behavior change:
- Applicable scope and the actual signature, fields/types, storage or configuration keys.
- Required invariants, validation/authorization boundaries, failure behavior and compatibility or migration constraints.
- The observable assertions and relevant test commands that distinguish correct behavior from the failure.
Use the shortest clear structure: a paragraph, table or focused example is often enough. A good/bad example helps when it explains a subtle distinction; it is not required for every lesson. Follow any explicitly required task/delivery format, but do not impose seven sections, a code sample or a new document on every change.
Before removing material, inspect its callers/references and preserve unique conditions, exceptions, evidence links and requirement IDs. Retire stale instructions only after confirming the current owner and scope. Historical findings, run counts, timestamps, candidate hashes, approvals and original receipts remain in task/evidence; a new result must not rewrite their past state.
Check links and affected process/doc contracts. Reuse unchanged test results; rerun relevant checks when behavior or inputs changed. Update an index only if discovery or ownership changed. Report the actual maintenance scope and limitations. Do not auto-commit, archive, alter runtime templates/hashes, or modify upstream/global files as a side effect.