db73cf5a39
Includes the current working directory changes. Historical commits and release binaries are excluded to limit Gitea storage. Source base: d7515973fbfd6dd2001fa156c483455b8081c7cb
34 lines
4.1 KiB
Markdown
34 lines
4.1 KiB
Markdown
# Plan: executable protocol specification
|
|
|
|
For /FD-plan and substantive revisions. Apply core scope/approval rules and [workflow.md](workflow.md). Planning may maintain records when permitted; business code, dependencies, and engineering configuration remain unchanged.
|
|
|
|
## Establish decisions and evidence
|
|
|
|
Use research, an existing task, requirements, or a new goal. Investigate relevant files, symbols, dependencies, configuration, and current behavior; reuse established decisions.
|
|
|
|
Use [grill.md](grill.md) for unresolved consequential choices, one Chinese question per round. Preferences and tradeoffs stay open until confirmed or explicitly delegated. A plan with blocking unknowns is a draft, not approved work.
|
|
|
|
Compare real alternatives only when a tradeoff exists. Prefer reuse and direct solutions; justify new dependencies, replacements, and abstractions against present needs.
|
|
|
|
## Construct and self-review
|
|
|
|
Include applicable goals/scope/observable acceptance, chosen approach and reasons, module responsibilities and data flow, changed contracts/configuration/dependencies, ordered steps, validation and failure scenarios, compatibility risks, and necessary rollback. Specify actual interfaces only when relevant and verified. Match depth to task size.
|
|
|
|
For a new feature, prioritize the smallest meaningful user path through the actual required layers before expanding variants: input → action → observable result, including persistence/reopen when relevant. For local changes identify their real entry and outcome; do not invent a full application or infrastructure. Order TODOs around usable outcomes rather than postponing all integration until components are complete. Prototype mock behavior remains separate from production integration evidence.
|
|
|
|
State the existing affected behaviors that must remain: relevant callers/public contracts, saved files/configuration, defaults, and output formats. Where a change affects persistent data, identify compatibility/migration, representative old data, restoration needs, and whether data effects are reversible; reverting code does not itself restore changed data. Use staged compatibility only when actual consumers or risk justify it.
|
|
|
|
If a consequential technical assumption could invalidate this plan, settle it using the bounded experiment in [research.md](research.md), or keep the plan conditional/draft with explicit impact. For UI work carry the approved copy boundary and key action/state/recovery expectations from [uiux.md](uiux.md) into implementation acceptance, including the ban on unrequested annotations.
|
|
|
|
Convert implementation into [hierarchical TODO](todo.md): stable IDs, suitable nesting, leaf actions/results/checks, dependencies, and meaningful parent acceptance. Include necessary verification and self-review, not only coding. Pending approval is not an in-progress implementation item.
|
|
|
|
Self-review completeness, real references, dependencies, unsupported premises, responsibilities, complexity, error handling, and checks. A planning self-review is not evidence that implementation tests passed.
|
|
|
|
## Save, present, and approve
|
|
|
|
For complex work, put the effective protocol plan and TODO in the same [task record](task-record.md) with version and approval status. Do not create a second authoritative plan or require an IDE plan artifact. Short work may present its complete concise plan in conversation. If record writes are unavailable, retain the full usable plan in conversation, mark persistence pending, and continue permitted planning.
|
|
|
|
Present the Chinese plan or its real file reference plus the decisions needed for review, blockers, risks, and approval status. Do not hide critical content behind a file that was not created. Await implementation approval; reuse an explicit implementation request for the same complete plan rather than asking again.
|
|
|
|
After approval, continue under [execute.md](execute.md). Preserve the approved content and substantive replacement history. When importing an older host-created plan, retain its original reference and approval provenance, copy only verifiable effective content into this protocol record, and disclose unavailable content or unclear approval instead of inventing it.
|