MicroFish/.kiro/settings/rules/design-synthesis.md

Design Synthesis

After discovery and before writing the design document, apply these three lenses to the collected findings. This step requires the full picture — do not parallelize.

1. Generalization

Look across all requirements as a group. Identify cases where multiple requirements are variations of the same underlying problem.

• If feature A is a special case of a more general capability X, design X with an interface that naturally supports A (and potentially B, C later)
• Keep the implementation scope to what the current requirements demand — generalize the interface, not the implementation
• Record identified generalizations in research.md under Design Decisions

2. Build vs. Adopt

For each major component in the emerging design, ask: is this problem already solved?

• Search for established standards (RFCs, protocols), battle-tested libraries, or platform-native capabilities that address the requirement
• Prefer adopting existing solutions over building custom ones when they fit the requirements without significant adaptation
• If adopting: verify the solution is actively maintained, compatible with the project's stack (check steering), and meets non-functional requirements
• If building: document why existing solutions were rejected (capture in research.md)

3. Simplification

For each component and abstraction layer in the emerging design, ask: is this necessary?

• Remove components that exist "just in case" or for hypothetical future requirements not in the current spec
• Flatten unnecessary abstraction layers — if an interface has only one implementation with no foreseeable second, it may not need the indirection
• Prefer fewer, cohesive components over many fine-grained ones
• The right design is the smallest one that satisfies all requirements and remains extensible at the interface level