Action parsing

# labs/command_loop.py
from labs.automation import ACTION_REGISTRY, RULES, match_rules, register_action

COMMAND_SYSTEM_PROMPT = """You control a house. Reply with one line: the name of the
action that fits the request, chosen from this list, or NONE if none of them fit.

{catalog}

No punctuation, no explanation, no other words."""

def action_catalog() -> str:
    return "\n".join(f"- {name}" for name in sorted(ACTION_REGISTRY))

if __name__ == "__main__":
    print(COMMAND_SYSTEM_PROMPT.format(catalog=action_catalog()))

$ uv run python -m labs.command_loop
You control a house. Reply with one line: the name of the
action that fits the request, chosen from this list, or NONE if none of them fit.

- play_music
- set_timer
- turn_off_lights

No punctuation, no explanation, no other words.

The catalog is generated, never typed. Write those three names into the prompt by hand and you have made a second copy of the registry that nothing compares against the first: register a fourth handler six months from now and the model will never choose it, silently, because it was never told the action exists. Reading the list out of ACTION_REGISTRY makes that bug unrepresentable. The sort keeps the prompt text stable between runs, so two prompts can be diffed to explain a behavior change.

import ollama

MODEL = "llama3.2:3b"

def propose_action(text: str) -> str:
    response = ollama.chat(
        model=MODEL,
        messages=[
            {"role": "system", "content": COMMAND_SYSTEM_PROMPT.format(catalog=action_catalog())},
            {"role": "user", "content": text},
        ],
        options={"temperature": 0},
    )
    return response["message"]["content"]

if __name__ == "__main__":
    for line in ["It's too bright in here.", "Put something on.", "How was your day?"]:
        print(f"{line!r} -> {propose_action(line)!r}")

$ uv run python -m labs.command_loop
"It's too bright in here." -> 'turn_off_lights'
'Put something on.' -> 'play_music.'
'How was your day?' -> "NONE\n\nI don't have days."

Your three replies will read differently; the pattern behind them will not. Print with !r, because the interesting damage is invisible otherwise: the trailing period on the second, the newlines and the editorial comment on the third. That is a model doing its job. It was trained to write for people, and no amount of "no other words" in a system prompt makes a 3b model a parser. Line one is the argument for this chapter in one string: not a single trigger from chapter 17 appears in "It's too bright in here," and she found the lights anyway.

def extract_action(reply: str) -> str | None:
    """Accept one complete registered name, ignoring only case and outer whitespace."""
    name = reply.strip().lower()
    return name if name in ACTION_REGISTRY else None

if __name__ == "__main__":
    for reply in [
        "turn_off_lights",
        "Turn_Off_Lights",
        "play_music.",
        "NONE",
        "do not turn_off_lights",
        "turn_off_lights or play_music",
        "turn_off_lights\nActually, do not.",
        "",
        "I could turn_off_lights, but where would the fun be in that?",
    ]:
        print(f"{extract_action(reply)!s:<16} <- {reply!r}")

$ uv run python -m labs.command_loop
turn_off_lights  <- 'turn_off_lights'
turn_off_lights  <- 'Turn_Off_Lights'
None             <- 'play_music.'
None             <- 'NONE'
None             <- 'do not turn_off_lights'
None             <- 'turn_off_lights or play_music'
None             <- 'turn_off_lights\nActually, do not.'
None             <- ''
None             <- 'I could turn_off_lights, but where would the fun be in that?'

Fixed strings, so this run is identical on your machine and mine: the gate is testable apart from the model that feeds it. Only outer whitespace and case can change. Punctuation, extra lines and every other word cause rejection; a model reply of play_music. now does nothing. That costs a missed command, which you can log and ask the user to repeat. A three-token scan would accept do not turn_off_lights, so short replies need the same complete-name check as long ones. The regression cases run offline with python -m unittest labs.test_command_loop in the reference source.

This parser checks representation, not meaning. A model can still return a perfectly spelled action for a negated request, and the earlier substring rules have that weakness too. Keep this lab's handlers as print statements. A real action needs a caller permission check and confirmation where a mistaken selection could matter; never treat registry membership as evidence of consent.

def execute_action(name: str, text: str) -> bool:
    handler = ACTION_REGISTRY.get(name)
    if handler is None:
        print(f"[WARN] no handler registered for {name!r}")
        return False
    try:
        handler(text)
    except Exception as err:
        print(f"[ERROR] {name} failed: {type(err).__name__}: {err}")
        return False
    return True

if __name__ == "__main__":
    @register_action("open_pod_bay_doors")
    def open_pod_bay_doors(text: str) -> None:
        raise TimeoutError("servo controller did not answer in 2.0 s")

    print(execute_action("open_pod_bay_doors", "open the doors"))
    print(execute_action("dim_lights", "dim the lights"))

$ uv run python -m labs.command_loop
[ERROR] open_pod_bay_doors failed: TimeoutError: servo controller did not answer in 2.0 s
False
[WARN] no handler registered for 'dim_lights'
False

Two gates, one function, one boolean, so a caller can branch without catching anything. The .get() guard is redundant from this call site, since extract_action already refused any name the registry does not hold, and dim_lights is the invention a model offers when the house has dimmers and the registry does not. Keep the guard anyway: chapter 17's rule engine and chapter 19's scheduler both call actions by name without passing through the extractor. The try matters more with every volume. Today a handler prints; in volume 5 it drives a servo over a serial link that can time out, and one hardware fault must not take the voice loop down with it. Catching bare Exception is usually a smell, but a dispatch boundary exists to run code it does not control and keep going, and printing the exception type stops it from being where errors die quietly.

def handle(text: str) -> bool:
    matched = match_rules(text, RULES)
    if matched:
        print(f"[RULE] {matched[0]['trigger']}")
        return execute_action(matched[0]["action"], text)
    reply = propose_action(text)
    name = extract_action(reply)
    if name is None:
        print(f"[MODEL] no action (she said {reply.strip()!r})")
        return False
    print(f"[MODEL] {name}")
    return execute_action(name, text)

if __name__ == "__main__":
    for line in ["Lights off, please.", "It's too bright in here.", "How was your day?"]:
        print(f"> {line}")
        handle(line)

$ uv run python -m labs.command_loop
> Lights off, please.
[RULE] lights off
[ACTION] Turning off lights.
> It's too bright in here.
[MODEL] turn_off_lights
[ACTION] Turning off lights.
> How was your day?
[MODEL] no action (she said 'NONE')

Keyword rules did not become obsolete; they became the fast path. A phrase you say every night hits a substring test, dispatches in microseconds, and never reaches the model. Everything else falls through to the interpreter that reads meaning, at the price named in the first section. Timed on my laptop over ten requests each, the rule path stayed under a tenth of a millisecond and the model path ran between 0.9 and 2.1 seconds; your second figure depends on your CPU and how warm the model is. The two labels are not decoration either: when she does the wrong thing, the first word of the log says whether to go argue with a rule row or with a prompt.