Prior Art and Project Evidence¶
Status: living research note
Last reviewed: 2026-08-30
This document compares selected terminal mechanisms and application designs that inform the project’s content model, history behavior, and test scenarios.
Protocol and terminal mechanisms¶
Work |
Content model |
Historical mutation |
Reading-anchor semantics |
Relevance |
|---|---|---|---|---|
Stateful character-imaging controls |
No stable application-level block mutation |
None for logical content |
Establishes the byte-stream and active-screen baseline |
|
Prompt, command, and output boundaries |
No general replacement operation |
Navigation between marks, not mutation anchoring |
Demonstrates deployed semantic marking |
|
Sanitized HTML inserted into a DOM-backed terminal |
Replaces the latest keyed replaceable element |
No general terminal-native history policy is specified |
Demonstrates keyed historical replacement |
|
Identified MIME content blocks |
|
No terminal-native reading-anchor behavior is specified |
Closest block lifecycle, fallback, capability, and trust design |
|
Identified start/end regions |
Existing blocks can be folded or unfolded |
No arbitrary content replacement anchor |
Demonstrates deployed block identity and limited updates |
For this project, SpaceTerm is the closest prior-art design reference. Its protocol provides designs for:
block identity and live-block lifecycle;
capability negotiation;
plain-text fallback;
rich representation selection;
trust tiers;
in-band and optional side-channel transport.
SpaceTerm describes itself as a web-native terminal, and its core models scrollback as a block list. The remaining comparison is whether TBP can be extended or profiled to define mutation and anchor behavior for terminal-owned history with terminal-native interaction.
Application architecture evidence¶
Project |
Approach |
Observed trade-off |
|---|---|---|
Skips repaint only for same-line-count, image-free changes above the viewport |
Avoids destructive redraw in a provable subset but explicitly accepts stale scrollback; layout changes retain the destructive baseline |
|
Documents scrollback clearing during full redraw |
Removing the clear alone does not provide historical identity or safe replay semantics |
|
Application-owned document, scrolling, selection, and follow mode |
Controls reflow and updates but moves live history out of terminal-native scrollback |
|
Retired a transcript-owned viewport experiment |
Strong rewrap and copy behavior came with a long cross-terminal compatibility tail |
|
Opt-in alternate-screen, application-owned transcript |
Reimplements scrolling, selection, search, and export; classic mode retains native scrollback |
Kimi Code also records the failed general redraw chain:
The failure classes reported by that chain are requirements for this project’s test oracle: blank screens, duplicated scrollback spans, vanished rows, growing blank space, and incorrect cursor bookkeeping.
Current conclusion¶
The surveyed mechanisms cover pieces of the problem:
semantic boundaries without general mutation;
keyed mutation in DOM or block-list terminals;
application-owned history with controllable reflow;
terminal-native history with frozen or destructively replayed offscreen content.
No surveyed source currently specifies all three target properties together: terminal-owned native history, correct mutation after content leaves the active screen, and preservation of a logical reading anchor.
The project uses an independent logical protocol because its baseline concerns terminal-owned mutable history and reading-anchor preservation rather than a bundle of rich representations. It reuses the demonstrated deployment pattern of OSC carrying Base64-encoded structured data without adopting TBP’s content model or patch semantics.