Specification Synchronizer

Instructions

Phase 1: Scan Specifications

1. •Read all API specs from docs-spec/api/*.md
2. •Read architecture from docs-spec/architecture.md
3. •Read BDD scenarios from docs-spec/behavior/*.feature

For each spec file, extract:

• •Rust code blocks containing struct, enum, trait, fn definitions
• •Thread constraints (スレッド: リアルタイム/非リアルタイム/任意)
• •Module structure diagrams

Phase 2: Scan Implementation

1. •

   Find all Rust files: src/**/*.rs, src-tauri/**/*.rs

2. •

   For each file, search for:

   • •pub struct definitions
   • •pub enum definitions
   • •pub trait definitions
   • •pub fn definitions
   • •impl blocks
3. •

   Find existing tests: tests/**/*.rs

Phase 3: Match and Compare

Use this mapping table:

Compare:

• •Struct names and fields (name, type)
• •Enum variants
• •Trait methods (signature)
• •Function signatures (name, parameters, return type)

Phase 4: Auto-fix or Ask

Auto-fix (high confidence):

• •Missing struct/enum/fn in impl → Add stub to implementation
• •Missing pub item in spec → Add to spec documentation
• •Missing doc comments → Add based on spec description
• •Missing test file → Create test skeleton

Ask user (low confidence):

• •Signature differs (design choice needed)
• •Implementation more complex than spec (generics, extra params)
• •Conflicts with ADR decisions

Use AskUserQuestion when unsure (with recommendation):

• •Always provide a recommended option based on project requirements
• •Explain why the recommendation is best

Example:

• •Question: "Signature mismatch for fn start_capture. Which to fix?"
• •Options:
  1. •"Update implementation (Recommended): Spec is source of truth per CLAUDE.md"
  2. •"Update spec: If implementation has better design rationale"
  3. •"Skip: Defer decision"

Phase 5: Ensure Tests

1. •

   For each Scenario: in docs-spec/behavior/*.feature:

   • •Map to test file: connection.feature → tests/connection_test.rs
   • •If test file missing → Create with test skeleton
   • •If scenario not covered → Add test function
2. •

   Test function structure:

   • •Parse Given → setup code
   • •Parse When → action code
   • •Parse Then → assertion
3. •

   Run cargo test to verify

Check Rules

Type Definition Checks

Function Signature Checks

Module Structure Checks

Test Coverage Checks

Output Format

## Sync Report: [spec_file] <-> [impl_files]

### Auto-fixed
- [FIXED] description (file:line)

### Needs Confirmation
- [QUESTION] description
  - Spec: X
  - Impl: Y

### Tests Created
- [TEST] tests/xxx_test.rs - N scenarios covered

### Summary
- Matched: N items
- Auto-fixed: N items
- User decisions: N items
- Tests created: N files