Transcript state versus model context

Documents DOM-safe message rendering, append behavior on failures, reset and clear semantics, and the absence of automatic multi-turn prompt construction.

Experimental
Last verified
2026-06-25 00:00 UTC
Updated
Reading time
1 minutes

Documents DOM-safe message rendering, append behavior on failures, reset and clear semantics, and the absence of automatic multi-turn prompt construction.

Implementation evidence: this topic is grounded in the reviewed GGUF.MiRust.com source snapshot. It documents observed code and artifacts without claiming broad deployment, model quality, or production readiness.

Presentation store

The browser holds messages in a JavaScript array and renders role and text exclusively through textContent, preventing generated text from becoming HTML.

Error visibility

Both the user prompt and an assistant error message are appended when sampling configuration or generation fails.

No automatic conversational context

Each form submission sends only the current prompt field to generate. Earlier transcript turns are not concatenated into the prompt. Runtime context from the prior generation can be extended only through the low-level generate_next_token export, which the UI does not expose.

Scope

This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.

Engineering considerations

  • Identify the source, version, target environment, and owner.
  • Separate observed values from estimates and externally reported values.
  • Record trade-offs, unsupported cases, and fallback behavior.
  • Link performance statements to a compatible benchmark methodology.

Verification questions

  • What exact artifact, revision, backend, and environment were reviewed?
  • Which assumptions could change the result?
  • Which data should be retained so another engineer can reproduce the conclusion?