Skip to content

Design Thinking

design-thinking owns:

How should this known behavior and system contract become code?

Implementation reasoning is non-trivial around data shapes, execution order, errors, dependencies, trust boundaries, concurrency, runtime policy, or resource lifecycle.

Do not reopen settled product or architecture decisions without evidence that they are contradictory or impossible.

known contract
↓
domain/data shapes
↓
execution graph
↓
errors + dependencies
↓
runtime boundaries
↓
implementation
↓
targeted proof
Use $design-thinking to implement recurring-task expansion
against the existing scheduling contract.

If verification becomes a separate hard problem, hand it to test-engineering.

Read the complete design-thinking instructions.