Delegate terminal presentation mechanics to the model

This commit is contained in:
ms2k 2026-08-20 02:36:22 +09:00
commit 7e68cfdc1f

View file

@ -614,41 +614,17 @@ Interactive terminal control requires:
Disconnected Client Sessions close rather than reattach to an unbounded scrollback
owned by the coordinator.
#### Retained terminal presentation
#### Terminal presentation
The application model owns terminal-route transitions. Their retained-screen
physical refinement is:
Terminal-route and presentation transitions follow the application model. The
terminal protocol additionally requires:
```mermaid
flowchart LR
Guest[Sandbox PTY output]
Buffer[Kernel PTY buffering]
Screen[HC retained screen]
Client[Paired Client terminal]
Trusted[Prompt or HostProcess presentation]
Guest -->|Sandbox route| Screen
Screen -->|derived rendering| Client
Guest -.->|Prompt or HostProcess route: reads paused| Buffer
Trusted --> Client
Trusted -->|return to Sandbox| Restore[redraw retained screen]
Restore --> Client
Buffer -->|resume in byte order| Screen
```
- The retained screen belongs to the existing fixed Host Coordinator and Client
Session pair. Existing Session Terminal cleanup discards it and any partial
input-decoder state; another Client cannot attach to or adopt it.
- Prompt and HostProcess presentation does not mutate the retained sandbox
screen. Returning to `Sandbox` restores that screen without guest input,
signals, resize, or application redraw.
- Requester-controlled bytes render inertly with argument boundaries preserved.
Approval defaults to denial and uses a bounded, fragmentation-independent
escape-sequence interval; incomplete, ambiguous, pre-prompt, interrupted, or
lost input cannot approve.
- The guest terminal profile exposes only qualified parser, renderer,
key-translation, and terminal-reply behavior. Replies derive from retained
state rather than the physical Client terminal.
- Guest terminal behavior is confined to the qualified terminal profile.
Terminal-reply bytes cannot originate from physical Client terminal input.
The session connection carries the terminal events and messages described by
this refinement. Interactive sessions negotiate `lazaret-control/2` through
@ -663,11 +639,10 @@ backpressure; terminal data for one session cannot consume another session's
control capacity. The event loop applies the model's terminal interaction
admissibility and authority decisions before performing these physical actions.
The Host Coordinator reads and forwards PTY output while the modeled terminal
route is `Sandbox`. While the route is `Prompt` or `HostProcess`, it stops reading
the PTY master and relies on bounded kernel PTY buffering and backpressure; it
does not accumulate an unbounded user-space queue. It resumes PTY reads when the
model restores the `Sandbox` route. Prompt input is read from the exact Client
Sandbox output is not delivered while the modeled terminal route is `Prompt` or
`HostProcess`, and the implementation does not accumulate an unbounded
user-space output queue. Output delivery resumes in byte order when the model
restores the `Sandbox` route. Prompt input is read from the exact Client
connection rather than the PTY.
Normal guest completion refines `CompleteSessionTerminal`. Its physical sequence
@ -1260,7 +1235,6 @@ not duplicated here.
| **FR-20** | Physical network readiness shall use product-owned known-live targets. DNS, public egress, and configured destination availability shall not gate it. |
| **FR-21** | The Domain Store and Storage Catalog shall preserve the independently recoverable ownership, identities, and authority relationships described by the durable-generation and prepared-lower refinements. |
| **FR-22** | Preparation shall use a supported OCI-aware preparer that materialises a Lazaret-owned immutable rootfs with source identity and prepared-artifact ID. |
| **FR-23** | Each interactive Client Session shall use the retained-screen refinement defined in **Retained terminal presentation**. |
### 4.3 Developer-Experience Requirements