Ideas and gated work that is not scheduled. An entry here is either an idea that is not designed yet, or work that says in its own text what evidence would start it. Anything concrete and committed belongs in a numbered release, and moves there when it is defined.

Done	Area	Item
⬜	GUI	Dynamic Shaders - GPU shader-based visual effects for terminal backgrounds and overlays (CRT scanlines, glassmorphism, noise). An orphan asset already exists - godot/shaders/crt.gdshader (a477d82, never referenced: no path or UID reference in any scene or script) - and it cannot be used as-is: its scanline term (uv.y * SCREEN_PIXEL_SIZE.y * 500.0) scales a 0–1 UV by a 1/resolution factor, so the whole node spans less than half a sine period (~0.46 rad at 1080p - a faint vertical ramp, not lines, and one that shifts with resolution), and COLOR = texture(TEXTURE, uv) drops the vertex/modulate color (a tinted overlay would render opaque white). Structural constraint: the terminal pane paints via batched _draw() commands, and a CanvasItem material runs per command with per-command TEXTURE/UV (font-atlas UVs for glyphs, 1×1 white with the tint in COLOR for rects), so a CRT effect belongs on a single-textured background quad (fixes: pixel-space scanline via FRAGCOORD.y; keep * COLOR) or on an overlay that reads hint_screen_texture / writes alpha to darken - never as a material on the grid Control. Fix or delete the orphan when this item is picked up.
⬜	CONCEPT	Reactive Environments - ambient visual feedback triggered by concept engine events (e.g., red tint when a test fails, green particles on build success)
⬜	TERM	Terminal graphics protocols and font ligatures - sixel and the kitty graphics protocol (image previews in yazi, chafa, timg) and programming-font ligatures. Evidence-gated: none of these is in any release, and the October 2026 assessment found no user demand for either, only that they are absent. Graphics decode untrusted image data, so the media stance applies (memory-safe decoders only, size caps, no sandboxing claim), and the grid’s packed-array wire format has no image channel, so it is a protocol addition for after v0.9.0. Ligatures need shaping across cell runs, which conflicts with the per-cell run batching and the procedurally drawn box characters from v0.8.1. Revisit with a concrete tool or user asking for either.
⬜	TERM	Instanced-quad renderer (alacritty-style glyph atlas + per-instance color) - evidence-gated: revisit only if render batching plus flood rate-limiting still shows frame-time pain. Godot already GPU-composites the canvas; a full Rust-side texture pipeline is deep custom work (atlas management, eviction, per-cell truecolor uploads) for a small incremental gain.
⬜	WIKI	A note near the 1 MiB render cap still costs ~1.1 s per settle render - v0.6.0 removed the superlinear shape term (list tags; minutes → ~1 s for the largest note a pane reads) and moved the render off the keystroke, so typing is smooth; what remains is the linear cost of the update itself, dominated by Godot’s shape pass (0.97 s of the 1.10 s for 1 MiB in release - the v0.6.0 closure carries the full table). Evidence-gated: act only if editing a note near the cap in split mode still hurts. The item’s own alternative is then a paused preview past a size threshold (a “preview updates when you ask” state with an explicit render action) - a UX decision, not a performance one - and edit mode already renders nothing. Not by lowering the render cap (the silent-prefix bug) and not by hiding the shape (the label has to lay out what it shows).
⬜	TERM	ConPTY passthrough mode - PSEUDOCONSOLE_PASSTHROUGH_MODE (0x8, Windows 11 22H2+) makes ConPTY relay the child’s VT stream instead of re-rendering its own model, which would recover the gpty_state OSC (see v0.5.4) and raw-sequence fidelity generally - cursor shapes, unrecognized SGR, private sequences, and the repaint artifacts that come with a translated stream. Surfaced by the Tier 2 Windows work, which measured the loss (a DECSET arrives, the OSC does not) and found the flag defined-but-unused in portable-pty 0.9.0, which does not expose the creation flags at all: this means gpty owning CreatePseudoConsole (raw externs, build-gated the way pin_library is) plus a full Windows fidelity and regression pass over the pane lifecycle the v0.5.4 items just hardened (spawn, resize, exit detection, process-group kill, mouse reporting). The flag also makes creation fail on pre-22H2 builds, so it needs a fallback path. Not started: no evidence yet that the fidelity gain justifies the spawn-path risk on the platforms the project still supports.
⬜	WIKI	Declared link weights cannot follow a note moved outside gPTY - the wiki pane’s rename now re-keys both endpoints (2026-10, closed above), but a move made in a file manager looks exactly like a delete to the index: the next complete graph prunes the declarations as vanished, and an outside move cannot be told apart from a deletion, so guessing would attach authored data to a path the index never saw. Display-only loss with a small blast radius. Fix direction only if a user reports it: an explicit graph-side “re-link declarations from <old path>” action seeded by the vanished endpoint, or a one-graph tombstone the prune respects - neither is worth building ahead of demand.
⬜	TERM	Windows foreground-job detection - the close confirmation’s foreground_job is exact on Unix (tcgetpgrp) and null on Windows/ConPTY, so the GUI treats every live shell as possibly busy: closing or quitting with any terminal open raises the confirmation even at an idle prompt (the v0.7.0 item’s documented fallback). If that proves noisy in use, the fix is a Windows-side direct-child snapshot (CreateToolhelp32Snapshot + Process32NextW, the raw-extern pattern pin_library/win_peer already use) compared against the shell pid - conservative in the other direction (a background child counts) but far closer than “any live shell”. No change until it is observed to annoy; the safe half is already in place.
⬜	IPC	The named-pipe client’s mio path is the last unexamined suspect for the Windows CLI heap corruption - evidence-gated on the v0.7.0 teardown stress loop reporting 0xC0000374 again: the runtime change removed the worker-teardown class (the CLI is single-threaded around process::exit now) and the smoke runs 100 throwaway processes per Windows run (≈ 200 connections), so a recurrence is the evidence that the client path itself is corrupting memory. Do not start by reading mio: collect a WER LocalDumps crash dump of the CLI process first (registry DumpFolder; DumpType 2 for a full dump), or run the loop under Application Verifier with heap checks, because the historical class here - tokio#6369, a ScheduledIo use-after-free on named-pipe disconnect - was fixed in mio 0.8.11 and this tree is on mio 1.2.2; a dump says whether it is that shape, a cancellation race on the eagerly-scheduled read (mio schedules a read at registration; teardown cancels it and the completion is processed later), or something outside the client entirely.