Imagine a Lua 5.4 pattern generator that proposes one tile at a time. Creating its coroutine does not start the design. The host first calls coroutine.resume, and the generator works until it explicitly yields a proposal.
Take a tiny hypothetical revision. A red tile is already accepted. The generator yields a blue square for the neighbouring position. The user rejects it and asks for amber. The host resumes the suspended coroutine with that decision, and the generator can use the values returned from its yield to prepare another proposal.
The useful detail is what rejection changes. Does it advance the palette position, preserve the current position, or restore the state from before the proposal? Each choice gives the artist a different revision process. Keeping the rejected proposal and the decision visible would help explain why the next tile differs.
If the user stops, the host can stop resuming the generator. That leaves a suspended computation rather than establishing that it completed, so the application still needs a policy for retained state and resources.
This sequence gives proposal, judgment and continuation separate moments. A Lua coroutine is not an OS thread. Its explicit handoffs can make revisions legible, but the application must decide what survives each one.
