Describes the static HTML/CSS/JavaScript product surface, local-only controls, model selector, transcript, provenance, benchmark, diagnostics, and developer panels.
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.
Architecture topic: this page does not claim that the WordPress website implements or executes the described runtime behavior.
Static product surface
app/index.html defines the complete UI without a framework. The shell includes prompt and maximum-token inputs, temperature/top-k/top-p/seed controls, Generate, Reset, and Clear actions, model selection, response output, local conversation transcript, model-load state, provenance, benchmark values, runtime diagnostics, token console, and developer mode.
State ownership
Rust owns model, tokenizer, KV cache, generation state, sampling configuration, result text, and diagnostics. JavaScript owns the selected local route, browser transcript, DOM state, host-side timings, and rendering.
Reset semantics
- Reset: clears runtime context and current output while retaining the visible transcript.
- Clear: empties the visible transcript without implicitly freeing the model.
- Model change: disables generation, frees or replaces runtime state, loads the new artifact, and exposes recovery after an error.
Local-only claim
The checked-in route map points only to same-origin app, WASM, model, and manifest files. No analytics, telemetry, external CDN, or remote inference URL appears in the active browser loader.
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?