StubInterpreter class

A deterministic offline interpreter that simulates the HTTP traffic a live chatbot would produce.

When to use

Use this when the demo runs without a key, in tests, or in contexts where network access is not available. It produces the same reply shape a live chatbot would produce, so the rest of the pipeline is unchanged.

How it works

The stub runs a small set of regular expressions over the sentence:

• ^addall(?: (.*))?$ → TissueVerb.addAll
• ^(?:please )?(?:add|insert) (-?\d+)(?: .*)?$ → TissueVerb.add
• ^(?:please )?(?:remove|delete) (-?\d+)(?: .*)?$ → TissueVerb.remove
• ^(?:please )?(?:clear|delete everything|empty)(?: .*)?$ → TissueVerb.clear
• anything else → Reject with reason 'no-permitted-verb'

The patterns are intentionally narrow. The point of the demo is not to build a robust NLU; it is to show the seam between interpretation and dispatch. A live model would be far more forgiving with phrasing; the stub is deliberately not, so the demo's console output is deterministic.

Non-obvious

• The stub honours the verb set. If the caller excludes a verb, the stub will not return it, and the sentence falls through to the reject case. That is how the demo proves the closed-vocabulary contract works even in offline mode.
• The stub prints synthetic traffic. Every complete call logs a system prompt, a synthetic request body, and a synthetic OpenAI-shaped response body, so the console output is identical in structure whether the demo is running offline or live.
• latency is configurable. The default is 1ms so the async pipeline is exercised. Set to Duration.zero in the production-shaped demo so the console output is deterministic.

Example

final stub = StubInterpreter(latency: Duration.zero);

final reply = await stub.complete(
  text: 'add 3',
  verbs: {'add', 'remove', 'clear'},
);

print(reply.command!.verb.name);  // 'add'
print(reply.command!.args);       // [3]

See Also

• HttpInterpreter — the live HTTP implementation.
• Interpreter — the port contract.