The standalone module owns the frontend-neutral VT engine and ANSI renderer;
vev consumes the released github.com/bnema/vev-vt v0.2.1 module. VT behavior,
renderer output, wire bytes, transport, ACK/rebase, and cursor-tail policy remain
unchanged.
Evidence
- The feature worktree was created from a clean checkout.
make test passes (go test ./... -race).make lint passes (goimports has no changes and go vet ./... passes).- External-package contract tests pass under
-race for parsing, callbacks,
borrowing, snapshots, history views, stable chunk identity, and single-owner
usage.
- VTH3 golden vectors round-trip byte-for-byte across empty, plain,
continuation, styled/RGB, bounded, and line-bound cases. Truncation,
corruption, invalid fields, and trailing bytes are rejected.
- The VEVS v4 restore envelope golden decodes through the existing restore path,
including sealed history, tail history, and recovery transcript blobs.
Truncated, corrupted, trailing, and malformed nested VT payloads are rejected.
- Representative VT/history/snapshot benchmarks pass; benchmark output is
retained in the implementation run rather than committed as machine-specific
data.
git diff --check passes.- The standalone module owns the frontend-neutral Cell, Style, RGB, Frame,
Damage, RuneWidth, VT parser, history, snapshots, and ANSI output packages.
- The cutover has no local VT, core, ANSI, or renderer implementation owner;
vev resolves the released module through normal module download semantics.
- A standalone core-only frame consumer test builds ANSI output without
importing the VT parser.
Scope guard
The vev cutover changes only module ownership and import paths; no VT parser
behavior, VTH3/VEVS bytes, or wire/protocol definition changed. There is no
committed replace directive or compatibility owner in vev. Any unrelated
behavior, wire, or dependency change discovered while maintaining the standalone
module must be split into a separate plan.
source
1# VT extraction preparation checkpoint
2
3The standalone module owns the frontend-neutral VT engine and ANSI renderer;
4vev consumes the released `github.com/bnema/vev-vt v0.2.1` module. VT behavior,
5renderer output, wire bytes, transport, ACK/rebase, and cursor-tail policy remain
6unchanged.
7
8## Evidence
9
10- The feature worktree was created from a clean checkout.
11- `make test` passes (`go test ./... -race`).
12- `make lint` passes (`goimports` has no changes and `go vet ./...` passes).
13- External-package contract tests pass under `-race` for parsing, callbacks,
14 borrowing, snapshots, history views, stable chunk identity, and single-owner
15 usage.
16- VTH3 golden vectors round-trip byte-for-byte across empty, plain,
17 continuation, styled/RGB, bounded, and line-bound cases. Truncation,
18 corruption, invalid fields, and trailing bytes are rejected.
19- The VEVS v4 restore envelope golden decodes through the existing restore path,
20 including sealed history, tail history, and recovery transcript blobs.
21 Truncated, corrupted, trailing, and malformed nested VT payloads are rejected.
22- Representative VT/history/snapshot benchmarks pass; benchmark output is
23 retained in the implementation run rather than committed as machine-specific
24 data.
25- `git diff --check` passes.
26- The standalone module owns the frontend-neutral Cell, Style, RGB, Frame,
27 Damage, RuneWidth, VT parser, history, snapshots, and ANSI output packages.
28- The cutover has no local VT, core, ANSI, or renderer implementation owner;
29 vev resolves the released module through normal module download semantics.
30- A standalone core-only frame consumer test builds ANSI output without
31 importing the VT parser.
32
33## Scope guard
34
35The vev cutover changes only module ownership and import paths; no VT parser
36behavior, VTH3/VEVS bytes, or wire/protocol definition changed. There is no
37committed `replace` directive or compatibility owner in vev. Any unrelated
38behavior, wire, or dependency change discovered while maintaining the standalone
39module must be split into a separate plan.