Session 8. Loops and graphs — Wed 23 Sep

Quick quiz (ungraded)

All three; refusing is free
It is free, and the chain has nowhere to do it. There is no branch between its retrieve step and its prompt.
The tool loop and reflection
Correct. Both have a branch after retrieval. The chain sends whatever came back straight into the prompt.
Only reflection, because the critic catches it
The critic runs after a draft exists, so the call is already spent. That is one call too late.

The state moved to done, since answering is where it was heading
That is the fall-through an if/elif gives you for free. The run continues in a state the design never allowed, and the bug surfaces somewhere else.
A raised ValueError, so the caller notices
Every caller then has to remember a try, and the one that forgets takes the process down over a late retry. An out-of-order event is ordinary.
The same state, with rejected naming the event and the state it was refused from
Correct. Nothing moves, nothing raises, and the reason is in the return value where the caller reads it.

An if current == "done": return state guard at the top of step
That works and it is code somebody can delete in a refactor. Terminality then disappears with it, silently.
No row in the table starts with done, so every event there is undeclared
Correct. It is a fact about the data, and adding an outgoing edge would be a deliberate line in a diff.
The graph library enforces it once END is reached
There is no library here. Five states and six edges are a dict, and the dict is what decides.

For the audit log; the machine itself does not read it
The machine does read it. Without the history there is nothing to count, and a retry cap is a count.
Because a cap on a repeated state is a rule about the history
Correct. visited.count('retrieving') is what stops a retry storm, and rewriting the list to the current state erases exactly that.
So the states stay in alphabetical order
It is the order they were entered, which is the only order that tells you what the run did.

Nothing risky; a retry is a normal recovery
A retry is normal. An edge back to the same state with nothing counting on it is a run that never ends.
A run that can loop forever until something external stops it
Correct. The storm is not in the retry, it is in the missing counter. Cap it with visited.count(...) before the move.
A parse failure, which the retry-once rule already covers
That rule lives in answer_question and bounds model calls. It says nothing about a self-edge in your graph.