db73cf5a39
Includes the current working directory changes. Historical commits and release binaries are excluded to limit Gitea storage. Source base: d7515973fbfd6dd2001fa156c483455b8081c7cb
50 lines
5.5 KiB
Markdown
50 lines
5.5 KiB
Markdown
# Execute
|
|
|
|
For /FD-execute and explicit implementation requests. Loading this reference does not approve implementation.
|
|
|
|
## Start or resume
|
|
|
|
- Confirm the goal, acceptance, effective plan/version (or eligible quick-path request), and actual approval. Reuse a complete user-supplied plan explicitly requested for implementation.
|
|
- /FD-execute directed at the single clear unblocked current plan can approve it. An explicit small local request meeting [workflow.md](workflow.md)'s quick-path criteria can provide its own short plan/approval. Otherwise use [plan.md](plan.md) to establish a suitable plan and resolve blockers; do not start unapproved edits.
|
|
- For complex work read [task-record.md](task-record.md) and [todo.md](todo.md). Reconcile files, completed IDs, evidence, recent revisions, and the current/next step.
|
|
- Protect user and unrelated task edits. Investigate discrepancies before trusting recorded completion; do not overwrite, clean, or mix unrelated changes.
|
|
- Reuse valid approval across turns and real capability limitations. Report a missing necessary write/execution capability without requesting an IDE mode, waiting for a button, or reapproving the same plan.
|
|
|
|
## Protocol progress
|
|
|
|
The effective protocol plan and hierarchical TODO guide implementation. Update real leaf states, affected parents, the current step, evidence, and next action after meaningful work units. Failed, blocked, unrun, or pending-verification items are not completed. A code change alone may leave its item 待验证.
|
|
|
|
Do not require or maintain a parallel host plan/task board. If an old host artifact is the only plan, reconcile its verifiable effective content and approval into the single protocol record before relying on it. If later edits invalidate previous results, retain historical evidence and mark the affected work 待验证.
|
|
|
|
## Implement continuously
|
|
|
|
Follow dependency order in small reviewable changes. Choose in-scope details independently. Validate a reasonable work unit and continue without per-item success questions.
|
|
|
|
Reuse verified capabilities and real APIs/configuration. Use tools suitable for the environment and reviewability. Avoid unrelated refactors or formatting.
|
|
|
|
Handle relevant inputs, state, failure, and resource boundaries. Integrate the agreed smallest user path early, checking actual results across its necessary layers. Preserve the affected existing behavior and compatibility promised by the plan. For UI changes follow the product-copy boundary in [uiux.md](uiux.md), retain real labels/status/errors, and implement the approved action states and recovery instead of compensating with explanatory notes.
|
|
|
|
For a defect, connect the observed symptom and supported cause to the specific fix, then repeat the same triggering case and relevant nearby normal cases. Capture pre-fix failure when feasible; if it cannot be reproduced, explain the evidence and remaining uncertainty instead of claiming a confirmed root cause. An exception disappearing is insufficient when the reported defect concerns lost data or wrong results. Add a meaningful regression check where appropriate, not tests mechanically for low-impact wording or record edits.
|
|
|
|
## Run and interpret checks
|
|
|
|
Before editing, establish a relevant baseline when existing checks can run at proportionate cost. Preserve results from before and after, distinguishing pre-existing failures, new failures, and resolved failures. Do not fix unrelated baseline problems without appropriate scope; an unavailable baseline remains a limitation.
|
|
|
|
Prefer declared project test, type, static-analysis, build, and manual-acceptance entry points. Test observable behavior through stable interfaces and meaningful state/output; interaction assertions are useful only where the interaction is itself a requirement. For example, persistence checks should read the saved result rather than only assert that a save method was called. Run focused checks and applicable required checks. Repeat or broaden only for new changes, failures, or unresolved concerns.
|
|
|
|
Record real commands, result summaries, and unverified scope. Mocks prove only covered behavior, not real integration or deployment. Investigate and fix failures within scope; never weaken valid assertions to pass.
|
|
|
|
Check authorization before diagnostics that contact real services, modify databases, or trigger publication. Without Git, use file comparison, builds, and observable behavior.
|
|
|
|
## Deviations and blockers
|
|
|
|
Report routine adjustments. Before substantive requirement, public-interface, selected-dependency, or scope changes, preserve state, explain reason/impact, record the revision and affected IDs, and confirm affected parts. Do not rewrite history to hide deviation or cancel failed checks to make completion appear.
|
|
|
|
Report partial completion or blockers honestly, with evidence, attempted approaches, and needed conditions. Stop repeated attempts that add no information. Continue independent authorized work where useful.
|
|
|
|
## Self-review and deliver
|
|
|
|
Compare goals, the effective plan, final changes, and actual checks. Inspect unmet acceptance, unrelated edits, duplication, needless abstraction, fake APIs, placeholders, and silent fallbacks. Fix in-scope issues and validate.
|
|
|
|
Update the task record and required parent acceptance, then report changes, rationale, actual checks/results, remaining IDs, gaps, and risks in Chinese. Claim completion only when acceptance and relevant checks support it. For distributed packages or executables apply [devops.md](devops.md)'s actual-artifact smoke checks where relevant. Git and external actions retain their separate explicit-authorization requirements.
|