statechart

原文涵盖的主题

• statechart
• First: does the work have states?
• Steps
• Brownfield work (from shape)
• Toolchain
• Rules

A chart of how a system moves between states, checked by TLC, in the words of the person who decides whether the behavior is right: the reader. A hand-drawn diagram proves nothing; this one comes from every state the model can reach. SC= /scripts/statechart Use it when the work has three or more states, or a rule about order, duplicates or retries (charged twice, a late webhook, a retry after cancel). Otherwise decline: say the code or flow has no states worth charting (a pure function maps input to output; a single request and reply has no lifecycle), write no model and draw no diagram, and suggest a table of inputs and outputs as tests instead. 1. Name the states and the rules in the reader's words. Rules come from the reader. When you chart code, today's behavior is the code's: read every guard and every path that changes state, and keep what the code does, not what it should do. 2. Write the model in the folder the user names, else a scratch folder outside the repo: Spec.tla and Spec.cfg. Each rule the reader agrees to is an INVARIANT; never weaken one to make it hold. Keep constants small. Read references/spec.md before writing it: Next as a disjunction of named actions, and e

这里只展示节选，请以完整原文和当前要求为准。