Creating a coroutine in Lua 5.4 doesn't start the design. The host calls coroutine.resume, and only then does the generator run, up to the point where it explicitly yields a proposal. One tile at a time.
A red tile is already accepted. The generator yields a blue square for the neighbouring position. Pause at this handoff. The user rejects it and asks for amber. The host resumes the suspended coroutine with that decision, and the generator reads it from the values its coroutine.yield call returns. Then it prepares another proposal.
What does the rejection change? The palette position could advance, stay put, or roll back to the state from before the proposal. Each gives the artist a different way of revising. Keeping the rejected proposal and the decision visible would explain why the next tile looks different.
If the user stops, the host just stops resuming. The coroutine is left suspended, not finished, so the application needs a policy for the state and resources it still holds.
A Lua coroutine is not an OS thread. Proposal, judgment and continuation each get their own moment. Those explicit handoffs make a revision legible, as long as it's clear what survives each one.
