docs(devguide): file the open items as proposals, and retire the JIT premise

The pending work surfaced by the full devguide read now has documents where
future sessions will look for it, instead of living as notes inside the pages
that happened to mention it.

New:

- opt_in_hover_telemetry.md — stop forwarding hover to the kernel when nobody is
  listening. The July round deduplicated identical hovers, which fixes a resting
  mouse and does nothing for a moving one, so the original ~16 messages/s during
  real hovering remain. Blocked on one decision: what view.hover_target means
  when telemetry is off. An empty target that looks like "nothing under the
  cursor" is the silent staleness Contract S7 forbids, so the honest option is an
  explicit disabled state.
- post_1.0/qt_popout_parity.md — the Qt shell is built with include_popout=False,
  so the whole popup control plane runs only on AnyWidget. Staged at Stage 4 of
  the host plan, not a defect, but worth naming: the host plan warns about
  features that work only in standalone and says nothing about the mirror case,
  which is what R3 was about.
- post_1.0/scene_object_owner_field.md — an add-on's shape is indistinguishable
  from one the user drew. Records why it must not be built by generalising the
  transient-region mechanism: those hide objects the user should not manage, and
  an add-on's shape is explicitly theirs to delete.

Retired, same day it was drafted: a JIT cold-start proposal. MolSysMT was
rewritten in Rust for 1.0 and no longer uses Numba — verified, no .py under
molsysmt/ references it and it ships _rust.abi3.so. That removes the premise of
standalone_performance_and_depythonization.md: its Path A is moot, its Path B
already happened years ahead of its v2.0.0 target, and only Path C survives.

The consequence for standalone_v2_evolution_plan.md cuts both ways and both are
recorded. Against Option 3: startup latency was its strongest argument, and the
Rust half already delivered that without removing Python. For it: the
Development Cost row priced a full Rust rewrite that is now done, leaving a
wasm32 target and the JS surface. The startup cost of Option 1 has not been
measured since the rewrite and must not be quoted from the old figures.

pending_proposals/README.md was still directing the reader to finish R2, close
D3 and implement D4, all of which landed. It now states that the two implemented
proposals are retained deliberately as the design record, which is an exception
to its own triage rule and was worth making explicit rather than leaving as an
apparent oversight.

Author: dprada

devguide/benchmarks/README.md

@@ -70,7 +70,7 @@ Measures fresh file loading duration (H5MSM structure files from demo package).
 | `1TCD` | 422.61 | 551.85 | 465.83 | 45.98 |
 | `chicken_villin_HP35` | 452.68 | 728.14 | 579.79 | 102.57 |
 
-*Note: The high maximum and standard deviation on the `dialanine` loading are caused by the initial python import, dynamic compiler JIT cache load (Numba/MolSysMT), and library warming during the first iteration.*
+*Note: The high maximum and standard deviation on the `dialanine` loading are caused by the initial python import and library warming during the first iteration. (This note used to also credit a "dynamic compiler JIT cache load (Numba/MolSysMT)". **MolSysMT was rewritten in Rust for 1.0 and no longer uses Numba**, so that component of the variance no longer exists and these figures predate the change.)*
 
 ### 🔄 2. Coordinate Transfer Performance
 Measures coordinate extraction (`get_coordinates`) and replacement/scene-rebuild (`set_coordinates`).

devguide/pending_proposals/README.md

@@ -3,25 +3,45 @@
 Only unresolved designs belong here. Implemented plans are promoted to durable
 documentation or removed; Git retains their development history.
 
-## Before 1.0
-
-Two accepted pre-1.0 improvements are active:
+## Implemented, retained as the design record
 
 - [`data_plane_architecture.md`](data_plane_architecture.md): typed buffers for
   already materialized structural arrays, with behaviorally equivalent JSON
-  fallback;
+  fallback. **Closed 2026-07-30.**
 - [`runtime_message_router.md`](runtime_message_router.md): one authority and a
   typed route across Python, widget/Qt hosts, canvases, and popups.
+  **Closed 2026-07-30.**
 
-They preserve the current 1.0 scientific model: `view.molsys` remains a complete
-selected `molsysmt.MolSys`. The data-plane work removes avoidable
+They preserve the 1.0 scientific model: `view.molsys` remains a complete selected
+`molsysmt.MolSys`. The data-plane work removed avoidable
 `ViewerJSON`/nested-list/text-JSON amplification without introducing partial
 residency.
 
+*These two are a deliberate exception to the triage rule "once implemented,
+remove the document from this directory."* They are the only written account of
+**why** the envelope, the shared manifest and the array-native layout are shaped
+the way they are, several documents link to them by path, and the decisions they
+record are still load-bearing. Read them as history, not as pending work. If they
+are ever moved, the links in `roadmap.md`, `checkpoints.md` and this file move
+with them.
+
 Structure windowing, eager/windowed modes, compression, workers, shared memory,
 BroadcastChannel, and multiview remain post-1.0. Camera acquisition/movie export
 is also explicitly post-1.0.
 
+## Open before 1.0
+
+- [`documentation_execution_in_ci.md`](documentation_execution_in_ci.md): run
+  `docs/execute_notebooks.py` in CI. Sphinx does not execute notebooks, which is
+  how ten broken ones survived unnoticed. Postponed by decision, not closed.
+- [`opt_in_hover_telemetry.md`](opt_in_hover_telemetry.md): stop forwarding hover
+  to the kernel when nobody is listening. The July round deduplicated identical
+  hovers, which fixes a resting mouse and not a moving one. **Blocked on one
+  product decision** — what `view.hover_target` means when telemetry is off.
+*(A JIT cold-start proposal was drafted here on 2026-07-31 and withdrawn the same
+day: MolSysMT no longer uses Numba. See
+[`../standalone_performance_and_depythonization.md`](../standalone_performance_and_depythonization.md).)*
+
 ## Deferred until after 1.0
 
 See [`post_1.0/`](post_1.0/). It contains:
@@ -32,7 +52,16 @@ See [`post_1.0/`](post_1.0/). It contains:
 - multiview synchronization;
 - advanced annotation, representation, and chemical-metadata work;
 - typing-generation and test-output studies;
-- deeper large-system rendering analysis.
+- deeper large-system rendering analysis;
+- [`qt_popout_parity.md`](post_1.0/qt_popout_parity.md): the Qt shell is built
+  with `include_popout=False`, so the entire popup control plane — manifest
+  validation, canonical snapshot, endpoint identity — is exercised only on
+  AnyWidget. Staged at Stage 4 of the host plan, not a defect;
+- [`scene_object_owner_field.md`](post_1.0/scene_object_owner_field.md): an
+  add-on's shape is indistinguishable from one the user drew;
+- [`qt_render_check_on_a_gpu_runner.md`](post_1.0/qt_render_check_on_a_gpu_runner.md):
+  the render gate is closed on real GPU; what is missing is a machine that proves
+  it again automatically.
 
 These remain useful, but they expand product scope or require benchmark and
 upstream decisions. They do not block the current release.

devguide/pending_proposals/opt_in_hover_telemetry.md

@@ -0,0 +1,78 @@
+# Opt-in hover telemetry
+
+**Status:** open. Design blocked on one product decision, stated below.
+
+**Origin:** the scalability note in
+[`../interaction_targets_and_selection.md`](../interaction_targets_and_selection.md)
+§`hover_target`. Promoted to its own proposal on 2026-07-31 because the July
+transport round attacked the same problem from a different angle and only solved
+half of it — which is exactly the kind of partial fix that gets mistaken for a
+closed one.
+
+## The problem
+
+Every debounced hover is forwarded to the kernel. The frontend debounce is
+60 ms, so continuous hovering is ~16 messages per second crossing the Comm
+channel. On a remote or high-latency deployment (cloud JupyterHub) that competes
+with everything else the kernel is doing, and most sessions never read hover
+from Python at all — they use it for frontend tooltips.
+
+## What already landed, and why it is not enough
+
+Mol\* re-emits hover on every resolved pick, storing `prevLoci` but never using
+it to suppress. A mouse **resting** on one atom therefore produced ~30 identical
+messages per second. `registerInteractionObservers`
+(`js/src/managers/viewer-controller.ts`) now deduplicates the Python-bound
+projection by comparing the serialized payload; local UI still sees every tick.
+
+That fixes the resting mouse completely and the **moving** mouse not at all:
+while the pointer travels across the structure every tick is a genuinely
+different payload, so nothing is suppressed and the original ~16/s remains.
+Deduplication and opt-in are complementary; opt-in is the one that addresses the
+case the note was written about.
+
+## The proposal
+
+Forward hover to the kernel only when someone is actually listening:
+
+- a Python callback is registered (`view.on_hover(cb)`), or
+- telemetry is explicitly enabled (`view.enable_hover_telemetry = True`).
+
+The frontend is told which state it is in, so the suppression happens **before**
+the message is sent, not after it arrives.
+
+## The blocker — decide this first
+
+`view.hover_target` became a public query object *after* the original note was
+written, and it is populated **from** the forwarded events. Gating forwarding on
+`on_hover(cb)` alone would leave `view.hover_target.info()` silently empty for
+anyone who queries it without registering a callback.
+
+That trades a performance problem for a correctness one, and it is precisely the
+failure `scene_contracts.md` Contract S7 forbids: an empty target that *looks*
+like "nothing under the cursor" is indistinguishable from the truth, and the user
+has no way to tell. **A plausible wrong answer is worse than a loud one.**
+
+So the decision to make is: **what does `view.hover_target` mean when telemetry
+is off?**
+
+- an explicit "telemetry disabled" state that `info()` reports honestly — the
+  query still answers, and it answers about itself;
+- or `hover_target` counts as a listener, so merely touching it turns telemetry
+  on for the rest of the session (discoverable, but surprising);
+- or telemetry defaults on and the flag is opt-*out* (no correctness risk, no
+  default gain).
+
+Only the first preserves both properties. It costs one extra state in a public
+object.
+
+## Acceptance
+
+- With no callback and telemetry off, hovering sends **zero** hover messages to
+  the kernel, verified by counting messages at the seam, not by timing.
+- `view.hover_target.info()` never reports "nothing hovered" when the truth is
+  "not being told" — mutation-verified by disabling telemetry and asserting the
+  reported state changes shape.
+- Registering `on_hover` mid-session starts forwarding without a reload.
+- The existing deduplication stays: it is what keeps a resting mouse quiet once
+  telemetry *is* on.

devguide/pending_proposals/post_1.0/qt_popout_parity.md

@@ -0,0 +1,70 @@
+# Popout parity in the Qt standalone host
+
+**Status:** post-1.0, and deliberately staged rather than missing.
+
+**Found:** 2026-07-31, while checking the July popup round against every host.
+
+## What is true today
+
+The Qt shell is built with `include_popout=False`
+(`standalone_qt/utils.py:_rebuild_qt_html`), so **no popup window can be opened
+in the standalone host at all**. `QtViewChannel.enable_popout` is `False` as
+well, though that attribute is inert — Qt bakes its configuration into the shell
+HTML at build time.
+
+The consequence is not a broken feature; it is an **untested path**. The whole
+popup control plane exists and is exercised only on AnyWidget:
+
+- the `popup_actions` group of `runtime_actions.json` — eleven host/popup actions
+  with the directions each may carry, validated on both ends;
+- `MolSysView.build_popup_scene_snapshot(mode, endpoint)` and the canonical
+  bootstrap that replaced the replay journal;
+- the endpoint identity, token authentication and revocation on close/reopen.
+
+None of it runs in Qt, so none of it is protected there by anything.
+
+## Why this is not a 1.0 gate
+
+`standalone_host_plan.md` §Proposed Execution Stages puts the auxiliary
+panel/workbench window at **Stage 4**, explicitly "only after the single-window
+host feels solid", and `standalone_direction.md` records the two-screen layout as
+"not a near-term implementation target". Roadmap gate 4 asks for real-window
+Qt/WebGL validation of load, interaction, context menu and the live-replacement
+regression — it does not ask for popout.
+
+`standalone_v2_evolution_plan.md` Phase 1 already lists implementing the
+`createWindow` handler as an action item. This document exists so the *current*
+asymmetry is recorded where the popup work can find it, not to reopen the
+staging decision.
+
+## The asymmetry worth naming
+
+`standalone_host_plan.md` §Non-Negotiable Invariants warns about features that
+work **only in standalone** because the host invented viewer logic. It says
+nothing about the mirror case: a feature that works in the notebook and not in
+standalone. That mirror is exactly what R3 was about — an unknown action was
+rejected observably on AnyWidget and accepted in silence on Qt — and popout is
+the same shape at the level of windows rather than actions.
+
+The invariant list should be read as symmetric: **one workbench model, multiple
+hosts** is violated in both directions.
+
+## What it needs
+
+1. A `createWindow` handler on the Qt page, mapping the request to a real
+   `QWebEngineView` in its own window.
+2. Building the shell with `include_popout=True` for the host that has such a
+   handler, and keeping it `False` where there is nowhere for a window to go.
+3. The popup channel's identity handshake over the Qt transport — the token and
+   endpoint model is transport-agnostic by construction, but that is an
+   assertion until something runs it.
+
+## Acceptance
+
+- A canvas popout opens from the Qt standalone and receives the canonical
+  snapshot, with the same scene the host canvas shows.
+- A panel popout opens and every Studio subpanel is populated — the Contract S1
+  failure (a blank section, because a runtime-only summary was not projected) is
+  host-independent and must be checked here too.
+- The popup-channel E2E, or its Qt equivalent, runs against the real host rather
+  than only against Chromium.

devguide/pending_proposals/post_1.0/scene_object_owner_field.md

@@ -0,0 +1,62 @@
+# An `owner` field on scene objects
+
+**Status:** post-1.0. Deferred on purpose, recorded so it stays a choice.
+
+**Origin:** `scene_contracts.md` §0.12, which decided the behaviour and deferred
+the field in the same breath.
+
+## The situation
+
+Add-ons do not have a private channel. They create shapes by calling the public
+API — ElastNetMT does exactly this:
+
+```python
+layer = view.shapes.add_displacement_vectors(...)   # adapters/modes.py
+layer = view.shapes.add_links(...)                  # adapters/contacts.py
+```
+
+So an add-on's shape lands in `_scene_objects` like any other, appears in
+`shapes.info()`, and shows up in the Shapes panel **with a trash button next to
+it**.
+
+**That was decided to be correct and it stays.** It is the user's scene; a viewer
+that displays an object it refuses to let you remove is worse than one that lets
+you delete something an add-on made. The add-on's obligation is to tolerate it:
+the handle it kept goes `_active = False`, and it must check rather than assume.
+
+## What is missing
+
+There is no `owner` field in the model, so a shape produced by ElastNetMT is
+**indistinguishable** from one the user drew by hand. The panel cannot say
+`· from elastnetmt`, and the user has no way to tell which objects will
+reappear if the add-on re-runs and which are theirs.
+
+## Why it was deferred
+
+It is new public API surface, and the block that surfaced it already carried
+enough. That reasoning still holds; this is not urgent.
+
+## What it would take
+
+- an `owner` on the scene-object record, set at creation from the calling add-on
+  when there is one, `None` otherwise;
+- the field in the authoritative summary (Contract S1) so the panel can render it
+  without a second projection;
+- serialisation (Contract S5), or an explicit decision that ownership is a
+  session-scoped annotation and does not survive a reload — either is defensible,
+  but it must be *decided*, because an owner that silently disappears on import
+  is worse than no owner at all;
+- a row affordance that is informative, not a second permission system. Ownership
+  labels what made an object; it does not restrict what the user may do to it.
+
+## Related, and deliberately not the same thing
+
+Transient regions (`focus`, `orientation`, `plane`) are already filtered from the
+panel and from `export_state` by `_TRANSIENT_REGION_TAG`, and Contract V's
+*owned primitives* — shapes a measurement creates for its own realisation — must
+be filtered the same way. Both are about objects the user did not create and
+should not manage directly.
+
+`owner` is different: an add-on's shape **is** the user's to manage. Do not
+implement `owner` by generalising the transient mechanism; they answer opposite
+questions.

devguide/standalone_performance_and_depythonization.md

@@ -1,5 +1,32 @@
 # Standalone Performance and De-pythonization Roadmap
 
+> **Overtaken by events (2026-07-31). Read the rest of this document as the
+> analysis that led to a decision, not as pending work.**
+>
+> **MolSysMT no longer uses Numba. It was rewritten in Rust for 1.0.** Verified
+> against the installed package: zero `.py` files under `molsysmt/` reference
+> `numba`, and it ships a compiled `_rust.abi3.so`.
+>
+> That means **Path B / Phase 2 has already happened**, years ahead of the
+> v2.0.0 target this roadmap assigned it — and it happened in MolSysMT rather
+> than as a separate `molsys_core` crate. The consequences for this document:
+>
+> | Section | Status |
+> |---|---|
+> | §1 "The Cold Start Problem" — the 3–5 s JIT freeze | **Gone.** The premise no longer exists. |
+> | Path A (Numba cache / AOT) | **Moot.** There are no `@jit` decorators left to cache. |
+> | Path B (Rust + PyO3) | **Done**, in MolSysMT itself. |
+> | Path C (WASM / de-pythonization) | **Still open**, and now much closer: the Rust core it presupposed exists. Its own preconditions — API parity between the Python library and a WASM/JS surface, and a Tauri-class shell — are untouched. |
+> | Phase 1 of the Recommended Roadmap | Withdrawn. |
+>
+> What is worth re-deriving rather than assumed: the standalone host's *actual*
+> startup cost today. This document's numbers all measured JIT compilation. Any
+> remaining startup latency now has a different cause — import cost, Qt WebEngine
+> initialization, or first-load serialization — and none of it has been measured
+> since the rewrite. **Do not quote the 3–5 seconds below as current.**
+>
+> Path C's evaluation stands and is the only part of this file still live.
+
 This document outlines the strategic roadmap for addressing the JIT compilation latency ("cold start" problem) in the `molsysmt` / `molsysviewer` backend, particularly for non-programmer desktop environments. It analyzes immediate workarounds and long-term architectural transitions to Rust and WebAssembly (WASM).
 
 ---