Dispatching feature work¶

The tracked todo.md groups remaining work into bounded IDs with dependencies, acceptance criteria and stopping points. This page records the shared interfaces so an implementation task can use existing plumbing without silently expanding into another feature.

The T1a/C1/T1c/W1/P2a batch is complete. Its behavior and evidence are recorded in the compatibility ledger and probe reference. Dispatch only remaining items from todo.md; do not reopen completed policy or hold work as a prerequisite for T1b or the other P2 options.

Start a task with its ID, expected behavior, dependencies, test oracle and file ownership. Implement one reviewable feature at a time. Shared startup, backend, widget and build files require coordination even when features are independent. Read the handoff's parser, rendering, selection and reset invariants before editing those paths.

Feature identifiers for pending chunks¶

Work IDs such as S2 name dispatch units; TDN IDs name stable, independently assessed behavior. Keep these associations when splitting or reordering the local checklist. Dependencies, acceptance criteria and optional/upstream-blocked status remain in that checklist; a registry entry does not schedule the feature or assert support. This table captures the pending queue at registration time; remove a row when its chunk is completed, preserving the feature IDs and evidence.

The handoff records durable Window/Title/Color Ops contracts and longer-term designs. Internal refactors and release verification are maintenance tasks, not terminal compatibility features.

Manual fixtures¶

The primary manual entry point is just probe, which builds the native Go runner and opens a keyboard/mouse browser. Its cases have the same handlers in menu and command mode, with TDN IDs and optional JSON evidence. For example:

just probe dcs-xtgettcap identity-tcap --cap TN --cap Co
just probe dec-mode-1000-mouse input-mouse --seconds 60
just probe sgr-58-underline-color text-underline

New feature work adds or extends native cases in tools/probe/cases.go and their Go handlers. Give each case stable TDN feature IDs, a curated browser location, expected behavior, policy and cleanup. Refresh embedded metadata with just update-probe-registry when changing the registry/navigation, and run just test-probe and just check-tdn. Check completion and early exit at 80×24.

Keep the legacy Python/shell probes and their recipes for comparison until the maintainer finishes the TDN migration checklist and resolves its gaps. New features do not need a duplicate legacy probe.

The runner emits protocol requests or synthetic data. It does not implement features or turn an unanswered request into a pass. Use the same invocation in the comparison emulator and record versions/resources. The probe reference explains the commands, cleanup and limitations.

A fixture must be extended when a task introduces behavior it cannot yet exercise. In particular, the graphics fixture is not evidence for file or shared-memory transport, storage limits, Unicode placeholders or animation.

Permission interfaces already prepared¶

Ctrl+right-click opens the font/options menu containing the Ops controls. Use the actual family associated with a protocol; do not invent a permission for every TODO item. An Ops switch is an application permission, not a renderer feature switch.

src/request_ops.h exposes XtpFontOps / XtpTcapOps, parse helpers and operation predicates. Lists use the shared ops_list wildcard/negation semantics. The default lists are SetFont,GetFont and SetTcap,GetTcap; a true master permission overrides the list. Font policy is stored and queryable via XtpVtFontOps, with XtpVtAllowFontOps for the master value. The future OSC 50 handler must consult both and only then enable the menu.

The mouse gate lives in XtpTerminalSetAllowMouseOps; it suppresses mouse tracking, mouse encoding and focus encoding without clearing the application's requested modes. The widget clears remembered reported buttons when the permission changes. Read requested mode state separately from permitted reporting. Do not infer the encoder's effective tracking family from a priority ordering of mode bits when implementing named exceptions.

XtpTerminalSetTcapOpsPolicy updates the capability reply gate. It recognizes libghostty's complete generated DCS 0/1 + r replies in the PTY write effect; it does not parse application input or alter capabilities. Preserve unrelated replies in mixed feeds and revisit this boundary if upstream changes callback batching. The current API emits a complete callback per capability reply.

SGR underline color, startup cursor shape, OSC 7/133, answerback and DA are not covered by these xterm Ops families. OSC 22 is a modern pointer-shape extension, not xterm's mouse-reporting permission. Search/copy actions belong to local UI behavior. Notifications and graphics need explicit design choices rather than an unrelated Ops checkbox.

Evidence required when a feature lands¶

Add focused backend tests and external Xvfb checks where behavior is visible. For an application-controlled feature, cover startup policy and changing its menu permission live. For a query, check exact bytes, denied silence, split feeds and unrelated replies before/after it. Preserve the final fixes in the color-policy tests; do not reintroduce after-the-fact rollback.

The probe-features test uses a fake PTY to check every runner command, reply decoding, interruption cleanup and termios restoration. It proves fixture behavior, not terminal feature support. xvfb-request-ops exercises the real Mouse/Tcap menu entries, startup denial, a GetTcap exception and restoration after toggling. Extend these tests when extending their policy.

Keep resource support reports, menu feasibility, the drift ledger and the handoff aligned with implemented behavior. A parser accepting a future operation name does not make that operation supported. Missing hooks become explicit upstream asks; the APC-only unknown callback cannot carry OSC 22, OSC 50 or arbitrary CSI controls.