Design Thinking
design-thinking owns:
How should this known behavior and system contract become code?
Use when
Section titled “Use when”Implementation reasoning is non-trivial around data shapes, execution order, errors, dependencies, trust boundaries, concurrency, runtime policy, or resource lifecycle.
Don’t use when
Section titled “Don’t use when”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 proofTry it
Section titled “Try it”Use $design-thinking to implement recurring-task expansionagainst the existing scheduling contract.If verification becomes a separate hard problem, hand it to test-engineering.