refactor: 切换 OpenSpec workflow 从 spec-driven 到 fast-drive

- 新增 fast-drive 自定义 schema 及模板（design.md、tasks.md） - 更新 config.yaml schema 为 fast-drive，调整 rules - 重构 proposal-review 和 apply-review 提示词适配 fast-drive - 删除 spec-review 提示词（fast-drive 不需要 spec 审查） - 删除 openspec/specs/ 下的稳定规范文件 - 更新 README 和 DEVELOPMENT.md 相关描述
2026-05-24 22:45:46 +08:00
parent 1e3269380e
commit bc54f8352a
13 changed files with 451 additions and 527 deletions
--- a/openspec/schemas/fast-drive/schema.yaml
+++ b/openspec/schemas/fast-drive/schema.yaml
@@ -0,0 +1,181 @@
+name: fast-drive
+version: 1
+description: Fast OpenSpec workflow - design -> tasks -> apply
+artifacts:
+  - id: design
+    generates: design.md
+    description: Self-contained solution brief and execution plan
+    template: design.md
+    instruction: |
+      Create design.md as the self-contained source of truth for what will
+      change, why it is changing, and how the work will be executed.
+
+      This workflow does not use proposal or specs artifacts. design.md MUST
+      preserve the important outcomes from prior exploration and user
+      discussion so a later apply phase can proceed correctly even after
+      context compression or in a new session.
+
+      Write for someone who cannot see the earlier conversation. Keep simple
+      changes concise, but include enough detail to make execution
+      unambiguous. Add more detail when any apply:
+
+      - Cross-cutting change across multiple systems, teams, workstreams, or
+      artifacts
+
+      - New dependency, integration, vendor, tool, policy, or external input
+
+      - Significant information model, process model, data model, or ownership
+      changes
+
+      - Security, privacy, compliance, performance, operational, or migration
+      complexity
+
+      - Ambiguity that benefits from decisions before execution
+
+      - Prior discussion settled non-obvious requirements, constraints, or
+      rejected alternatives
+
+      Required sections:
+
+      - **Context**: Problem, current state, relevant references, and the user
+      request that triggered this change
+
+      - **Discussion Notes**: Key points from exploration or prior discussion
+      that must not be lost. Include agreed conclusions, user preferences,
+      constraints, and important rejected ideas.
+
+      - **Requirements**: Expected outcomes, behavior/process/interface/content
+      changes, continuity expectations, and acceptance criteria.
+
+      - **Goals / Non-Goals**: What this change will achieve and what is
+      explicitly out of scope.
+
+      - **Execution Guardrails**: Must-follow constraints, forbidden approaches,
+      preserved behavior/processes, dependency limits, and project- or
+      workflow-specific boundaries.
+
+      - **Affected Areas**: Concrete artifacts, references, stakeholders,
+      systems, workstreams, documents, configurations, assets, or handoffs that
+      are relevant to the change.
+
+      - **Decisions**: Key choices with rationale (why X over Y?). For each
+      important decision, include alternatives considered and why they were not
+      chosen.
+
+      - **Execution Plan**: Main workstreams or artifacts to change, integration
+      or handoff points, sequencing, and any rollout notes.
+
+      - **Verification Plan**: Validation checks, reviews, approvals,
+      acceptance checks, documentation checks, communication checks, and manual
+      checks needed to prove the change is complete.
+
+      - **Risks / Trade-offs**: Known limitations and things that could go
+      wrong.
+      Format: [Risk] -> Mitigation
+
+      - **Open Questions**: Outstanding decisions, assumptions, or unknowns to
+      resolve before execution. Separate blocking questions that must pause
+      apply from non-blocking follow-ups. Use "None" if there are no open
+      questions.
+
+      Optional sections when relevant:
+
+      - **Migration / Rollout Plan**: Rollout steps, communication, ownership,
+      rollback, or continuity strategy.
+
+      Focus on preserving requirements, rationale, constraints, and approach.
+      Avoid line-by-line or step-by-step details unless a detail is a deliberate
+      decision from the discussion.
+
+      Prefer durable summaries over chat transcripts. Use concrete artifact
+      names, data/information shapes, examples, stakeholders, ownership, and
+      edge cases when they affect execution.
+
+      Do not use task checkboxes in design.md; checkboxes belong only in
+      tasks.md.
+
+      Final design.md must not contain unresolved template comments, empty
+      table rows, or placeholder text.
+
+      If information is missing, state assumptions and open questions instead
+      of inventing hidden requirements. Do not rely on unstated chat context.
+    requires: []
+  - id: tasks
+    generates: tasks.md
+    description: Trackable execution checklist derived from design.md
+    template: tasks.md
+    instruction: |
+      Create tasks.md by breaking design.md into executable work.
+
+      **IMPORTANT: Follow the template below exactly.** The apply phase parses
+      checkbox format to track progress. Tasks not using `- [ ]` will not be
+      tracked.
+
+      Guidelines:
+
+      - Derive tasks from design.md. Do not depend on proposal.md or specs
+      artifacts; any relevant prior discussion must already be captured in
+      design.md.
+
+      - Group related tasks under `##` numbered headings
+
+      - Each task MUST be a single-line checkbox: `- [ ] X.Y Task description`
+
+      - Tasks should be small enough to complete in one session
+
+      - Order tasks by dependency (what must be done first?)
+
+      - Start with context review tasks when execution depends on guardrails,
+      affected areas, or open questions
+
+      - Include validation tasks for checks, reviews, approvals, acceptance,
+      documentation, communication, and manual checks when required
+
+      - Do not include repository, version-control, or release operation tasks
+      unless they are explicitly part of the change scope
+
+      - Final tasks.md must not contain unresolved template comments, empty
+      table rows, or placeholder task text
+
+      Example:
+
+      ```
+      ## 1. Context Review
+
+      - [ ] 1.1 Read design.md and identify scope, requirements, decisions, guardrails, and open questions
+      - [ ] 1.2 Review relevant artifacts and references listed in Affected Areas
+
+      ## 2. Execution
+
+      - [ ] 2.1 Execute first concrete work item from design.md
+      - [ ] 2.2 Execute next concrete work item from design.md
+
+      ## 3. Validation
+
+      - [ ] 3.1 Run required validation from Verification Plan
+      - [ ] 3.2 Perform quality checks required by the project or workflow
+      - [ ] 3.3 Perform required manual review or acceptance checks from Verification Plan
+
+      ## 4. Documentation / Communication
+
+      - [ ] 4.1 Update relevant documentation, runbooks, communication materials, or project references if behavior, process, interface, configuration, or usage changed
+      ```
+
+      Reference design.md for scope, requirements, decisions, execution
+      direction, and verification expectations.
+
+      Each task should be verifiable: it must be clear when the task is done.
+    requires:
+      - design
+apply:
+  requires:
+    - design
+    - tasks
+  tracks: tasks.md
+  instruction: |
+    Read design.md first, then tasks.md.
+    Also follow workflow context/configuration, such as openspec/config.yaml when available, and any relevant project or workflow documentation referenced by design.md.
+    Treat design.md as the source of truth for scope, requirements, decisions, guardrails, execution direction, and verification expectations.
+    Work through pending tasks in dependency order and mark complete as you go.
+    Mark a task complete only after its execution and required verification are done.
+    Pause if tasks conflict with design.md, if design.md has blocking open questions, or if clarification is needed.