Expose Neural Link window ops for harness popouts

Context

The v13.1 cockpit scoping pass found a real gap under #13376: the creation primitive proof is closed (#13373), but the Neural Link multi-window window-ops pillar is still only represented by the parent epic. Grace flagged this as not done, @neo-gpt re-verified it in #13376, and Vega accepted the gap for the #13436 graduation chain.

Release classification: ON Project 13 + v13.1 milestone. This is a v13.1 planning/implementation gap because the cockpit can treat NL as the mechanism for live widgets, but it must not claim agent-controlled multi-window/popout behavior without a concrete NL-facing leaf.

The Problem

Current Neural Link can inspect connected windows, but it does not expose a bounded write-side window-control surface for the harness.

Verified current state:

• ai/mcp/server/neural-link/toolService.mjs maps get_window_topology to RuntimeService.getWindowTopology.
• ai/mcp/server/neural-link/openapi.yaml defines /window/topology with operationId get_window_topology and x-neo-tool-tier: read.
• ai/services/neural-link/RuntimeService.mjs#getWindowTopology() returns known windows from ConnectionService.sessionData.
• Targeted source search found no create_window, position_window, focus_window, or equivalent write-side window operation in the NL server surface.
• #13025 and #13028 cover engine/gesture behavior for terminal popup drop and OS-titlebar reintegration; #13158 covers docking/QT unification. None of those creates the NL agent-control tool surface named by #13376.

So v13.1 currently has a live widget proof and a live window engine, but no explicit NL tool leaf that lets an agent drive the window/popout surface instead of relying on user gesture or app-local methods.

The Architectural Reality

#13376 names pillar 1 as multi-window window-ops: agent-driven create / move / position / split / pop-out / reintegrate over Neo.manager.Window, driving the docking substrate without re-implementing it.

Relevant existing surfaces:

• get_window_topology is read-only topology, not control.
• src/dashboard/Container.mjs#openWidgetInPopup() already opens a live widget in a popup using the dashboard/container substrate.
• src/manager/Window.mjs and src/main/addon/WindowPosition.mjs are the window topology/geometry authority.
• #13025/#13028 and #13158 are lower-level engine/docking tracks; this ticket must consume their primitives, not fork them.
• #13376's trust-tier model matters: window write ops belong to the trusted harness/development world unless a separate projection gate deliberately widens them.

The Fix

Add a minimal Neural Link window-ops write surface for the Agent Harness, scoped to the first useful popout/control path rather than the entire Infinite Canvas.

Target shape:

1. Keep get_window_topology as the read baseline.
2. Add a bounded write-side operation to open/pop out a known live harness component or pane through an existing app/window primitive, rather than inventing a second popup manager.
3. Add bounded position/focus control for known window ids returned by topology, with honest fallback when the current runtime cannot support movement or focus.
4. Keep dock-zone persistence, drag-to-dock, native titlebar reintegration, and dynamic-import/code trust outside this leaf.

Exact operation names may be refined in the PR, but the implementing Contract Ledger must settle the public tool names before merge and update OpenAPI, toolService, service code, and docs together.

Contract Ledger

Decision Record impact

aligned-with ADR 0020 and depends on #13376. No ADR amendment expected: this implements the ADR 0020 / #13376 possession premise at the NL tool-surface layer.

Acceptance Criteria

• A bounded Neural Link write-side operation can open/pop out a known live harness component or pane through an existing app/dashboard/window primitive.
• A bounded Neural Link operation can position and/or focus a known window id returned by get_window_topology, or returns a fail-loud unsupported result when the active runtime cannot support it.
• OpenAPI, toolService, service implementation, and Neural Link docs name the same operations and trust tier.
• The write operations are server-projected/gated for the trusted harness write tier and cannot be enabled by client assertion alone.
• Tests or whitebox e2e prove the positive path on a known harness widget/pane and the fail-loud path for unknown target/window id.
• The PR body reconciles the Contract Ledger against the implemented method names and any runtime limitations discovered during implementation.

Out of Scope

• Dynamic import / class registration ceiling-breaker work from #13376.
• create_instance itself; #13373 owns that and is closed.
• Cross-window drag gesture mechanics (#13025, #13028).
• Dock-zone persistence, drag-to-dock integration, and windowPlacementHints.v1 (#13158 / Discussion #13370).
• Full v14 institution cockpit / COP UX (#13444).
• Treating EvidencePane as the product surface; this leaf is window control for the live widget/app pane path, not provenance UI.

Avoided Traps

• Forking the window engine: rejected. This must drive dashboard.Container, Neo.manager.Window, and existing window primitives rather than creating an NL-private popup manager.
• Claiming v13.1 multi-window complete from topology reads: rejected. get_window_topology proves inspection, not control.
• Client-asserted trust widening: rejected. Window writes belong behind server-forced projection/trust-tier gates.
• Serializing OS window state into dock-zone layout: rejected. Dock persistence stays with #13158 / #13370's separate semantic hint layer.

Related

Parent epic: #13376. Planning source: #13436. First-widget/cockpit consumers: #13349, #13445, #13361. Engine/docking prerequisites and siblings: #13025, #13028, #13158. Creation primitive proof: #13373.

Duplicate / freshness sweep

Live latest-open sweep: checked the latest 30 open GitHub issues immediately before creation on 2026-06-17; no equivalent NL window-ops leaf was present. The only live search hit for Neural Link window ops open_component_window position_window focus_window popup #13376 was parent #13376.

A2A in-flight claim sweep: checked the latest 30 A2A messages immediately before creation. No competing [lane-claim] or [lane-intent] for an NL window-ops leaf surfaced; the only new relevant message was Vega accepting this as a missing #13376 gap for #13436.

Exact/local sweep: rg over resources/content/issues, resources/content/discussions, learn, ai, apps, and test surfaced the engine/docking/window-manager issues #13025/#13028/#13158 and current get_window_topology, but no open NL write-side window-ops leaf.

Semantic sweep: ask_knowledge_base("existing open ticket Neural Link multi-window window operations create move position popup window ops #13376", type:"ticket") did not surface an equivalent open ticket.

Origin Session ID

5b3cb9d5-7567-489c-9234-5dc6af99edbc

Handoff Retrieval Hints

query_raw_memories: "v13.1 #13376 NL multi-window window ops missing leaf EvidencePane keeper proof split"; exact anchors: RuntimeService.getWindowTopology, get_window_topology, src/dashboard/Container.mjs#openWidgetInPopup, #13376 latest v13.1 planning marker.