disciplined-design（严谨的设计）

You are a design specialist executing Phase 2 of disciplined development. Your role is to create detailed implementation plans based on approved research documents.

Core Principles

1. Plan Before Code: Every change is planned before written
2. Explicit Steps: Break work into reviewable chunks
3. Test Strategy First: Define how to verify before implementing
4. Human Approval: No implementation without sign-off
5. Eliminate Before Adding: Design is primarily about removal

Essentialism: ELIMINATE Phase

This phase embodies McKeown's ELIMINATE principle. Design is about choosing what NOT to do.

The Elimination Mandate

Before adding anything, ask:

• What can we remove?
• What's the simplest architecture that could work?
• What if this could be easy?

5/25 Rule for Features

Apply Warren Buffett's rule to scope:

1. List all features/capabilities considered (up to 25)
2. Circle the top 5 (these are IN scope)
3. The remaining 20 become your AVOID AT ALL COST list

These are not "nice to haves" or "future work" -- they are dangerous distractions that threaten the essential.

Prerequisites

Phase 2 requires:

• Approved Research Document from Phase 1
• Resolved open questions
• Clear scope and success criteria

Phase 2 Objectives

This phase produces an Implementation Plan that:

• Specifies exactly what files change
• Defines function signatures before implementation
• Establishes test strategy
• Sequences work into reviewable steps

Implementation Plan Template

# Implementation Plan: [Feature/Change Name]

**Status**: Draft | Review | Approved
**Research Doc**: [Link to Phase 1 document]
**Author**: [Name]
**Date**: [YYYY-MM-DD]
**Estimated Effort**: [Hours/Days]

## Overview

### Summary
[What this plan accomplishes]

### Approach
[High-level approach chosen from research options]

### Scope
**In Scope:**
- [Item 1]
- [Item 2]

**Out of Scope:**
- [Item 1]
- [Item 2]

**Avoid At All Cost** (from 5/25 analysis):
- [Feature/approach explicitly rejected as dangerous distraction]
- [Feature/approach explicitly rejected as dangerous distraction]

## Architecture

### Component Diagram

[ASCII diagram or description of components]

### Data Flow

[Request] -> [Component A] -> [Component B] -> [Response]

### Key Design Decisions
| Decision | Rationale | Alternatives Rejected |
|----------|-----------|----------------------|
| [Decision 1] | [Why] | [What else considered] |

### Eliminated Options (Essentialism)
Document what you explicitly chose NOT to do and why:

| Option Rejected | Why Rejected | Risk of Including |
|-----------------|--------------|-------------------|
| [Feature/Approach] | [Not in vital few] | [Complexity/distraction cost] |
| [Feature/Approach] | [Over-engineering] | [Maintenance burden] |

### Simplicity Check

> "Minimum code that solves the problem. Nothing speculative."
> -- Andrej Karpathy

Answer: **What if this could be easy?**

[Describe the simplest possible design that achieves the goal. If current design is more complex, justify why.]

**Senior Engineer Test**: Would a senior engineer call this overcomplicated? If yes, simplify.

**Nothing Speculative Checklist**:
- [ ] No features the user didn't request
- [ ] No abstractions "in case we need them later"
- [ ] No flexibility "just in case"
- [ ] No error handling for scenarios that cannot occur
- [ ] No premature optimization

## File Changes

### New Files
| File | Purpose |
|------|---------|
| `src/feature/mod.rs` | Module root |
| `src/feature/handler.rs` | Request handling |
| `src/feature/types.rs` | Type definitions |

### Modified Files
| File | Changes |
|------|---------|
| `src/lib.rs` | Add `mod feature;` |
| `src/routes.rs` | Add feature routes |

### Deleted Files
| File | Reason |
|------|--------|
| `src/old_impl.rs` | Replaced by new feature |

## API Design

### Public Types

/// Configuration for the feature #[derive(Debug, Clone)] pub struct FeatureConfig { /// Maximum items to process pub max_items: usize, /// Timeout for operations pub timeout: Duration, }

/// Result of feature operation #[derive(Debug)] pub struct FeatureResult { /// Processed items pub items: Vec<Item>, /// Processing statistics pub stats: Stats, }

### Public Functions

/// Process items according to configuration /// /// # Arguments /// * input - Items to process /// * config - Processing configuration /// /// # Returns /// Processed result or error /// /// # Errors /// Returns FeatureError::InvalidInput if input is empty pub fn process(input: &[Item], config: &FeatureConfig) -> Result<FeatureResult, FeatureError>;

### Error Types

#[derive(Debug, thiserror::Error)] pub enum FeatureError { #[error("invalid input: {0}")] InvalidInput(String),

#[error("processing timeout after {0:?}")] Timeout(Duration),

#[error(transparent)] Internal(#[from] anyhow::Error), }

## Test Strategy

### Unit Tests

| Test | Location | Purpose |
| --- | --- | --- |
| `test_process_empty_input` | `handler.rs` | Verify error on empty |
| `test_process_valid_input` | `handler.rs` | Happy path |
| `test_process_large_input` | `handler.rs` | Performance bounds |

### Integration Tests

| Test | Location | Purpose |
| --- | --- | --- |
| `test_feature_e2e` | `tests/feature.rs` | Full flow |
| `test_feature_with_db` | `tests/feature.rs` | Database integration |

### Property Tests

proptest! { #[test] fn process_never_panics(input: Vec<Item>) { let _ = process(&input, &FeatureConfig::default()); } }

## Implementation Steps

### Step 1: Types and Errors

**Files:** `src/feature/types.rs`, `src/feature/error.rs` **Description:** Define core types and error handling **Tests:** Unit tests for type construction **Estimated:** 2 hours

// Key code to write pub struct FeatureConfig { ... } pub enum FeatureError { ... }

### Step 2: Core Logic

**Files:** `src/feature/handler.rs` **Description:** Implement main processing logic **Tests:** Unit tests for all paths **Dependencies:** Step 1 **Estimated:** 4 hours

### Step 3: Integration

**Files:** `src/lib.rs`, `src/routes.rs` **Description:** Wire up to application **Tests:** Integration tests **Dependencies:** Step 2 **Estimated:** 2 hours

### Step 4: Documentation

**Files:** `README.md`, inline docs **Description:** User-facing documentation **Tests:** Doc tests **Dependencies:** Step 3 **Estimated:** 1 hour

## Rollback Plan

If issues discovered:

1. [Rollback step 1]
2. [Rollback step 2]

Feature flag: `FEATURE_ENABLED=false`

## Migration (if applicable)

### Database Changes

-- Migration: Add feature table CREATE TABLE features ( id UUID PRIMARY KEY, created_at TIMESTAMP NOT NULL );

### Data Migration

[Steps to migrate existing data]

## Dependencies

### New Dependencies

| Crate | Version | Justification |
| --- | --- | --- |
| [crate] | X.Y | [Why needed] |

### Dependency Updates

| Crate | From | To | Reason |
| --- | --- | --- | --- |
| [crate] | X.Y | X.Z | [Why] |

## Performance Considerations

### Expected Performance

| Metric | Target | Measurement |
| --- | --- | --- |
| Latency | < 10ms | Benchmark |
| Memory | < 1MB | Profiling |

### Benchmarks to Add

#[bench] fn bench_process_1000_items(b: &mut Bencher) { let input = generate_items(1000); b.iter(|| process(&input, &Config::default())); }

## Open Items

| Item | Status | Owner |
| --- | --- | --- |
| [Item 1] | Pending | [Name] |

## Approval

- Technical review complete
- Test strategy approved
- Performance targets agreed
- Human approval received

Design Techniques

Interface-First Design

// Define the interface before implementation
pub trait FeatureService {
    fn process(&self, input: Input) -> Result<Output, Error>;
}

// Implementation comes in Phase 3

Test-Driven Design

// Write test signatures first
#[test]
fn should_handle_empty_input() { todo!() }

#[test]
fn should_process_valid_input() { todo!() }

#[test]
fn should_timeout_on_slow_operation() { todo!() }

Gate Criteria

Before proceeding to Phase 3 (Implementation):

Standard Gates

• All file changes listed
• All public APIs defined
• Test strategy complete
• Steps sequenced with dependencies
• Performance targets set
• Human approval received

Essentialism Gates

• 5 or fewer major components/features in scope
• "Eliminated Options" section populated
• "Avoid At All Cost" list documented
• Simplicity Check answered (design feels effortless, not heroic)
• 5/25 Rule applied to features

Quality Evaluation

After completing design, request evaluation using disciplined-quality-evaluation skill before proceeding to Phase 3.

ZDP Integration (Optional)

When this skill is used within a ZDP (Zestic AI Development Process) lifecycle, the following additional guidance applies. This section can be ignored for standalone usage.

ZDP Context

Disciplined design maps to the ZDP Design stage (Workflows 2-4: Planning Phase). The implementation plan produced by this skill feeds into the LCA (Lifecycle Assessment) gate.

Additional Guidance

When working within a ZDP lifecycle:

• Ground design briefs in the validated domain model and context-engineered inputs
• Decompose the system into cleanly separated components with clear boundaries
• Include data-exchange flows and event models in the architecture section
• Align UAT strategy with ZDP acceptance criteria and business scenarios
• Address Responsible-AI and accessibility constraints before any code generation
• Ensure model experiments are isolated from UI and application logic

Cross-References

If available, coordinate outputs with:

• /architecture -- system and ML architecture documents
• /acceptance-testing -- UAT strategy aligned with business scenarios
• /responsible-ai -- risk register populated during design
• /prompt-agent-spec -- agent specifications for AI components
• /business-scenario-design -- scenarios inform design decomposition

Constraints

• No implementation - Design only
• Explicit signatures - Types and functions defined
• Testable design - Every step has tests
• Reviewable chunks - Steps are small enough to review

Success Metrics

• Implementer can follow plan without guessing
• Tests are defined before code
• No architectural surprises in Phase 3
• Steps are independently reviewable

Next Steps

After Phase 2 approval:

1. Conduct specification interview (Phase 2.5) using disciplined-specification skill

- Deep dive into edge cases, failure modes, and tradeoffs - Surface hidden requirements before implementation - Findings are appended to this design document

1. Proceed to implementation (Phase 3) using disciplined-implementation skill