Execute concurrent terminal panes through a replaceable provider #730

Description

@taras

Story

As an executable-document host, I want the panes in a terminal grid to execute
concurrently through one replaceable terminal provider, so the document keeps
one lifecycle and replay contract whether the presentation is tmux, a controlled
test surface, or a future native interface.

This is the provider-neutral execution Story under #717. It begins after #729
has frozen the structural language. Native Session.Launch integration and the
production tmux provider are separate consumers of the boundary established
here.

Contract

Core validates the complete resolved layout, takes the document execution's one
foreground-terminal lease, flushes root output, and issues one provider request
for the exact grid expansion. The host supplies a terminal provider and a
non-contextual terminal authority. The stable contextual API routes the request
and permits observation, narrowing, refusal, wrapping, and delegation; no
handler return value can authorize or settle a grid. Only the direct authority
can validate the request, mint one-use pane claims, and acquire or release root
and pane terminal ownership.

The provider prepares the whole composite while it remains hidden. Core creates
one durable child operation per authored pane ordinal and starts those children
concurrently. A paired pane expands its document flow in an isolated binding,
evaluation, checked-failure, and control-flow scope while inheriting the grid
site's providers, configuration, working directory, repository selection, and
bindings. A self-closing pane starts the host-configured default interactive
shell through its pane claim. Pane display reaches that pane only; the grid
renders "", and native terminal bytes are neither captured nor journaled.

Each pane becomes ready only when its first interactive child reports the
runtime's successful spawn event through the private one-use readiness latch in
its pane claim. Endpoint or PID allocation, preparation, first output, or child
settlement without a spawn event is not readiness. The provider attaches the
composite only after every pane is ready. Any provider-preparation or pane-start
failure before that barrier cancels every pane, awaits complete teardown,
discards the hidden composite, restores the root terminal, and reports the first
failure by authored pane order. Effects completed before the failed start remain
durable.

After attachment, pane success and ordinary failure are independent visible
statuses and do not cancel siblings. The composite remains visible after all
panes settle until the reader closes it. Close prevents new launches, cancels
live pane scopes, awaits every child and finalizer, destroys the exact
composite, restores the root terminal, releases its lease, and only then lets
the document continue. The first failed pane in authored order fails the grid
at close; close-induced cancellation is not a pane failure. Provider failure
cancels and fails the whole grid. Parent cancellation follows the same complete
teardown and remains cancellation.

The terminal authority and pane claims grant terminal ownership only. They
grant no Agent-session authority. This Story exposes the pane-scoped launch seam
that later integrations consume, but it neither changes Session.Launch nor
installs an Agent provider.

Durability and replay

The grid is one core-owned structured durable region. Its identity contains the
resolved columns and ordered pane forms and titles. Pane child identities derive
from the grid expansion and ordinal, never a title, schedule, or provider
identifier.

The completed record retains the provider-neutral layout, close kind, and
ordered pane outcomes after the ordinary secret gate. Completed replay restores
the exact result without contacting a terminal provider, expanding pane content,
or starting a shell. Partial replay compares the complete layout before provider
work, builds a fresh live composite, restores completed panes as statuses, and
continues incomplete pane children from their own durable histories. An
incomplete self-closing pane starts the current authorized default shell and
claims no terminal-history continuity.

Commands, sockets, paths, process identifiers, layout identifiers, argv,
environment, terminal bytes, and provider topology remain live provider state
and enter no public request result, retained identity, record, or diagnostic.

Acceptance

  • A controlled provider that is not tmux runs one through eight panes using the
    exact row-major layout from Describe terminal grids as executable document structure #729 and begins all authored pane operations
    concurrently.
  • Each pane inherits grid-site state but isolates its own later bindings,
    contextual changes, checked failures, Break, and Return from siblings and
    enclosing control flow.
  • Root output is flushed before preparation; pane output reaches only its pane;
    the grid and a surrounding capture receive no pane display or terminal bytes.
  • Readiness is exactly the runtime child-spawn event. Every earlier candidate is
    rejected by a crossed test, and a child that spawns then immediately exits is
    both ready and settled.
  • Every provider-preparation and pane-start position can fail without attaching
    a partial grid. All acquired pane work and finalizers settle, and simultaneous
    failures select the first authored ordinal.
  • After attach, one pane can succeed or fail while siblings remain live. Its
    final status remains visible until reader close.
  • Reader close, parent cancellation at preparation/readiness/active phases, and
    provider failure each perform complete teardown with the specified result and
    failure precedence. No later document sibling starts while any acquired pane
    or provider resource remains live.
  • One pane claim admits only one interactive operation at a time; distinct pane
    claims do not contend. A claim from another grid, ordinal, provider generation,
    or completed invocation authorizes nothing.
  • The default shell uses live host policy and the pane terminal; provider
    absence refuses before pane start or shell execution.
  • Completed replay performs no provider or pane work. Partial replay restores
    completed pane statuses, continues incomplete durable children, and refuses a
    changed layout before provider contact.
  • Retained and diagnostic data contain only provider-neutral layout and outcome
    facts.

This Story owns TG6–TG10 and TG12–TG17, plus the controlled-provider half of
TG18. TG5 and Agent-session contention in TG11 belong to the native-launch
Story. The tmux half of TG18 belongs to the production-provider Story.

Focused evidence

Add the controlled provider and terminal-authority tests beside the core
structured execution they exercise:

deno task test packages/core/tests/terminal-grid.test.ts
deno task test packages/runtime/tests/terminal-provider.test.ts

The suite uses test-controlled readiness, settlement, close, failure, and
teardown operations. It must prove provider non-observation and teardown
ordering directly rather than infer them from process timing.

Dependencies and exclusions

Verification stack

This Story is the third layer of #717's linear verification stack.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
       blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
      }
      } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
      })();
      (function(){
      try {
      var __m = "github.com";
      var __re = new RegExp('^' + "github\\.com" + '
      
      Skip to content

      Execute concurrent terminal panes through a replaceable provider #730

      Description

      @taras

      Story

      As an executable-document host, I want the panes in a terminal grid to execute
      concurrently through one replaceable terminal provider, so the document keeps
      one lifecycle and replay contract whether the presentation is tmux, a controlled
      test surface, or a future native interface.

      This is the provider-neutral execution Story under #717. It begins after #729
      has frozen the structural language. Native Session.Launch integration and the
      production tmux provider are separate consumers of the boundary established
      here.

      Contract

      Core validates the complete resolved layout, takes the document execution's one
      foreground-terminal lease, flushes root output, and issues one provider request
      for the exact grid expansion. The host supplies a terminal provider and a
      non-contextual terminal authority. The stable contextual API routes the request
      and permits observation, narrowing, refusal, wrapping, and delegation; no
      handler return value can authorize or settle a grid. Only the direct authority
      can validate the request, mint one-use pane claims, and acquire or release root
      and pane terminal ownership.

      The provider prepares the whole composite while it remains hidden. Core creates
      one durable child operation per authored pane ordinal and starts those children
      concurrently. A paired pane expands its document flow in an isolated binding,
      evaluation, checked-failure, and control-flow scope while inheriting the grid
      site's providers, configuration, working directory, repository selection, and
      bindings. A self-closing pane starts the host-configured default interactive
      shell through its pane claim. Pane display reaches that pane only; the grid
      renders "", and native terminal bytes are neither captured nor journaled.

      Each pane becomes ready only when its first interactive child reports the
      runtime's successful spawn event through the private one-use readiness latch in
      its pane claim. Endpoint or PID allocation, preparation, first output, or child
      settlement without a spawn event is not readiness. The provider attaches the
      composite only after every pane is ready. Any provider-preparation or pane-start
      failure before that barrier cancels every pane, awaits complete teardown,
      discards the hidden composite, restores the root terminal, and reports the first
      failure by authored pane order. Effects completed before the failed start remain
      durable.

      After attachment, pane success and ordinary failure are independent visible
      statuses and do not cancel siblings. The composite remains visible after all
      panes settle until the reader closes it. Close prevents new launches, cancels
      live pane scopes, awaits every child and finalizer, destroys the exact
      composite, restores the root terminal, releases its lease, and only then lets
      the document continue. The first failed pane in authored order fails the grid
      at close; close-induced cancellation is not a pane failure. Provider failure
      cancels and fails the whole grid. Parent cancellation follows the same complete
      teardown and remains cancellation.

      The terminal authority and pane claims grant terminal ownership only. They
      grant no Agent-session authority. This Story exposes the pane-scoped launch seam
      that later integrations consume, but it neither changes Session.Launch nor
      installs an Agent provider.

      Durability and replay

      The grid is one core-owned structured durable region. Its identity contains the
      resolved columns and ordered pane forms and titles. Pane child identities derive
      from the grid expansion and ordinal, never a title, schedule, or provider
      identifier.

      The completed record retains the provider-neutral layout, close kind, and
      ordered pane outcomes after the ordinary secret gate. Completed replay restores
      the exact result without contacting a terminal provider, expanding pane content,
      or starting a shell. Partial replay compares the complete layout before provider
      work, builds a fresh live composite, restores completed panes as statuses, and
      continues incomplete pane children from their own durable histories. An
      incomplete self-closing pane starts the current authorized default shell and
      claims no terminal-history continuity.

      Commands, sockets, paths, process identifiers, layout identifiers, argv,
      environment, terminal bytes, and provider topology remain live provider state
      and enter no public request result, retained identity, record, or diagnostic.

      Acceptance

      • A controlled provider that is not tmux runs one through eight panes using the
        exact row-major layout from Describe terminal grids as executable document structure #729 and begins all authored pane operations
        concurrently.
      • Each pane inherits grid-site state but isolates its own later bindings,
        contextual changes, checked failures, Break, and Return from siblings and
        enclosing control flow.
      • Root output is flushed before preparation; pane output reaches only its pane;
        the grid and a surrounding capture receive no pane display or terminal bytes.
      • Readiness is exactly the runtime child-spawn event. Every earlier candidate is
        rejected by a crossed test, and a child that spawns then immediately exits is
        both ready and settled.
      • Every provider-preparation and pane-start position can fail without attaching
        a partial grid. All acquired pane work and finalizers settle, and simultaneous
        failures select the first authored ordinal.
      • After attach, one pane can succeed or fail while siblings remain live. Its
        final status remains visible until reader close.
      • Reader close, parent cancellation at preparation/readiness/active phases, and
        provider failure each perform complete teardown with the specified result and
        failure precedence. No later document sibling starts while any acquired pane
        or provider resource remains live.
      • One pane claim admits only one interactive operation at a time; distinct pane
        claims do not contend. A claim from another grid, ordinal, provider generation,
        or completed invocation authorizes nothing.
      • The default shell uses live host policy and the pane terminal; provider
        absence refuses before pane start or shell execution.
      • Completed replay performs no provider or pane work. Partial replay restores
        completed pane statuses, continues incomplete durable children, and refuses a
        changed layout before provider contact.
      • Retained and diagnostic data contain only provider-neutral layout and outcome
        facts.

      This Story owns TG6–TG10 and TG12–TG17, plus the controlled-provider half of
      TG18. TG5 and Agent-session contention in TG11 belong to the native-launch
      Story. The tmux half of TG18 belongs to the production-provider Story.

      Focused evidence

      Add the controlled provider and terminal-authority tests beside the core
      structured execution they exercise:

      deno task test packages/core/tests/terminal-grid.test.ts
      deno task test packages/runtime/tests/terminal-provider.test.ts

      The suite uses test-controlled readiness, settlement, close, failure, and
      teardown operations. It must prove provider non-observation and teardown
      ordering directly rather than infer them from process timing.

      Dependencies and exclusions

      Verification stack

      This Story is the third layer of #717's linear verification stack.

      Activity

      Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

      Metadata

      Metadata

      Assignees

      No one assigned

        Labels

        enhancementNew feature or request

        Projects

        No projects

          Milestone

          No milestone

          Relationships

          None yet

          Development

          No branches or pull requests

          Issue actions

          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
          Skip to content

          Execute concurrent terminal panes through a replaceable provider #730

          Description

          @taras

          Story

          As an executable-document host, I want the panes in a terminal grid to execute
          concurrently through one replaceable terminal provider, so the document keeps
          one lifecycle and replay contract whether the presentation is tmux, a controlled
          test surface, or a future native interface.

          This is the provider-neutral execution Story under #717. It begins after #729
          has frozen the structural language. Native Session.Launch integration and the
          production tmux provider are separate consumers of the boundary established
          here.

          Contract

          Core validates the complete resolved layout, takes the document execution's one
          foreground-terminal lease, flushes root output, and issues one provider request
          for the exact grid expansion. The host supplies a terminal provider and a
          non-contextual terminal authority. The stable contextual API routes the request
          and permits observation, narrowing, refusal, wrapping, and delegation; no
          handler return value can authorize or settle a grid. Only the direct authority
          can validate the request, mint one-use pane claims, and acquire or release root
          and pane terminal ownership.

          The provider prepares the whole composite while it remains hidden. Core creates
          one durable child operation per authored pane ordinal and starts those children
          concurrently. A paired pane expands its document flow in an isolated binding,
          evaluation, checked-failure, and control-flow scope while inheriting the grid
          site's providers, configuration, working directory, repository selection, and
          bindings. A self-closing pane starts the host-configured default interactive
          shell through its pane claim. Pane display reaches that pane only; the grid
          renders "", and native terminal bytes are neither captured nor journaled.

          Each pane becomes ready only when its first interactive child reports the
          runtime's successful spawn event through the private one-use readiness latch in
          its pane claim. Endpoint or PID allocation, preparation, first output, or child
          settlement without a spawn event is not readiness. The provider attaches the
          composite only after every pane is ready. Any provider-preparation or pane-start
          failure before that barrier cancels every pane, awaits complete teardown,
          discards the hidden composite, restores the root terminal, and reports the first
          failure by authored pane order. Effects completed before the failed start remain
          durable.

          After attachment, pane success and ordinary failure are independent visible
          statuses and do not cancel siblings. The composite remains visible after all
          panes settle until the reader closes it. Close prevents new launches, cancels
          live pane scopes, awaits every child and finalizer, destroys the exact
          composite, restores the root terminal, releases its lease, and only then lets
          the document continue. The first failed pane in authored order fails the grid
          at close; close-induced cancellation is not a pane failure. Provider failure
          cancels and fails the whole grid. Parent cancellation follows the same complete
          teardown and remains cancellation.

          The terminal authority and pane claims grant terminal ownership only. They
          grant no Agent-session authority. This Story exposes the pane-scoped launch seam
          that later integrations consume, but it neither changes Session.Launch nor
          installs an Agent provider.

          Durability and replay

          The grid is one core-owned structured durable region. Its identity contains the
          resolved columns and ordered pane forms and titles. Pane child identities derive
          from the grid expansion and ordinal, never a title, schedule, or provider
          identifier.

          The completed record retains the provider-neutral layout, close kind, and
          ordered pane outcomes after the ordinary secret gate. Completed replay restores
          the exact result without contacting a terminal provider, expanding pane content,
          or starting a shell. Partial replay compares the complete layout before provider
          work, builds a fresh live composite, restores completed panes as statuses, and
          continues incomplete pane children from their own durable histories. An
          incomplete self-closing pane starts the current authorized default shell and
          claims no terminal-history continuity.

          Commands, sockets, paths, process identifiers, layout identifiers, argv,
          environment, terminal bytes, and provider topology remain live provider state
          and enter no public request result, retained identity, record, or diagnostic.

          Acceptance

          • A controlled provider that is not tmux runs one through eight panes using the
            exact row-major layout from Describe terminal grids as executable document structure #729 and begins all authored pane operations
            concurrently.
          • Each pane inherits grid-site state but isolates its own later bindings,
            contextual changes, checked failures, Break, and Return from siblings and
            enclosing control flow.
          • Root output is flushed before preparation; pane output reaches only its pane;
            the grid and a surrounding capture receive no pane display or terminal bytes.
          • Readiness is exactly the runtime child-spawn event. Every earlier candidate is
            rejected by a crossed test, and a child that spawns then immediately exits is
            both ready and settled.
          • Every provider-preparation and pane-start position can fail without attaching
            a partial grid. All acquired pane work and finalizers settle, and simultaneous
            failures select the first authored ordinal.
          • After attach, one pane can succeed or fail while siblings remain live. Its
            final status remains visible until reader close.
          • Reader close, parent cancellation at preparation/readiness/active phases, and
            provider failure each perform complete teardown with the specified result and
            failure precedence. No later document sibling starts while any acquired pane
            or provider resource remains live.
          • One pane claim admits only one interactive operation at a time; distinct pane
            claims do not contend. A claim from another grid, ordinal, provider generation,
            or completed invocation authorizes nothing.
          • The default shell uses live host policy and the pane terminal; provider
            absence refuses before pane start or shell execution.
          • Completed replay performs no provider or pane work. Partial replay restores
            completed pane statuses, continues incomplete durable children, and refuses a
            changed layout before provider contact.
          • Retained and diagnostic data contain only provider-neutral layout and outcome
            facts.

          This Story owns TG6–TG10 and TG12–TG17, plus the controlled-provider half of
          TG18. TG5 and Agent-session contention in TG11 belong to the native-launch
          Story. The tmux half of TG18 belongs to the production-provider Story.

          Focused evidence

          Add the controlled provider and terminal-authority tests beside the core
          structured execution they exercise:

          deno task test packages/core/tests/terminal-grid.test.ts
          deno task test packages/runtime/tests/terminal-provider.test.ts

          The suite uses test-controlled readiness, settlement, close, failure, and
          teardown operations. It must prove provider non-observation and teardown
          ordering directly rather than infer them from process timing.

          Dependencies and exclusions

          Verification stack

          This Story is the third layer of #717's linear verification stack.

          Activity

          Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

          Metadata

          Metadata

          Assignees

          No one assigned

            Labels

            enhancementNew feature or request

            Projects

            No projects

              Milestone

              No milestone

              Relationships

              None yet

              Development

              No branches or pull requests

              Issue actions

              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
              Skip to content

              Execute concurrent terminal panes through a replaceable provider #730

              Description

              @taras

              Story

              As an executable-document host, I want the panes in a terminal grid to execute
              concurrently through one replaceable terminal provider, so the document keeps
              one lifecycle and replay contract whether the presentation is tmux, a controlled
              test surface, or a future native interface.

              This is the provider-neutral execution Story under #717. It begins after #729
              has frozen the structural language. Native Session.Launch integration and the
              production tmux provider are separate consumers of the boundary established
              here.

              Contract

              Core validates the complete resolved layout, takes the document execution's one
              foreground-terminal lease, flushes root output, and issues one provider request
              for the exact grid expansion. The host supplies a terminal provider and a
              non-contextual terminal authority. The stable contextual API routes the request
              and permits observation, narrowing, refusal, wrapping, and delegation; no
              handler return value can authorize or settle a grid. Only the direct authority
              can validate the request, mint one-use pane claims, and acquire or release root
              and pane terminal ownership.

              The provider prepares the whole composite while it remains hidden. Core creates
              one durable child operation per authored pane ordinal and starts those children
              concurrently. A paired pane expands its document flow in an isolated binding,
              evaluation, checked-failure, and control-flow scope while inheriting the grid
              site's providers, configuration, working directory, repository selection, and
              bindings. A self-closing pane starts the host-configured default interactive
              shell through its pane claim. Pane display reaches that pane only; the grid
              renders "", and native terminal bytes are neither captured nor journaled.

              Each pane becomes ready only when its first interactive child reports the
              runtime's successful spawn event through the private one-use readiness latch in
              its pane claim. Endpoint or PID allocation, preparation, first output, or child
              settlement without a spawn event is not readiness. The provider attaches the
              composite only after every pane is ready. Any provider-preparation or pane-start
              failure before that barrier cancels every pane, awaits complete teardown,
              discards the hidden composite, restores the root terminal, and reports the first
              failure by authored pane order. Effects completed before the failed start remain
              durable.

              After attachment, pane success and ordinary failure are independent visible
              statuses and do not cancel siblings. The composite remains visible after all
              panes settle until the reader closes it. Close prevents new launches, cancels
              live pane scopes, awaits every child and finalizer, destroys the exact
              composite, restores the root terminal, releases its lease, and only then lets
              the document continue. The first failed pane in authored order fails the grid
              at close; close-induced cancellation is not a pane failure. Provider failure
              cancels and fails the whole grid. Parent cancellation follows the same complete
              teardown and remains cancellation.

              The terminal authority and pane claims grant terminal ownership only. They
              grant no Agent-session authority. This Story exposes the pane-scoped launch seam
              that later integrations consume, but it neither changes Session.Launch nor
              installs an Agent provider.

              Durability and replay

              The grid is one core-owned structured durable region. Its identity contains the
              resolved columns and ordered pane forms and titles. Pane child identities derive
              from the grid expansion and ordinal, never a title, schedule, or provider
              identifier.

              The completed record retains the provider-neutral layout, close kind, and
              ordered pane outcomes after the ordinary secret gate. Completed replay restores
              the exact result without contacting a terminal provider, expanding pane content,
              or starting a shell. Partial replay compares the complete layout before provider
              work, builds a fresh live composite, restores completed panes as statuses, and
              continues incomplete pane children from their own durable histories. An
              incomplete self-closing pane starts the current authorized default shell and
              claims no terminal-history continuity.

              Commands, sockets, paths, process identifiers, layout identifiers, argv,
              environment, terminal bytes, and provider topology remain live provider state
              and enter no public request result, retained identity, record, or diagnostic.

              Acceptance

              • A controlled provider that is not tmux runs one through eight panes using the
                exact row-major layout from Describe terminal grids as executable document structure #729 and begins all authored pane operations
                concurrently.
              • Each pane inherits grid-site state but isolates its own later bindings,
                contextual changes, checked failures, Break, and Return from siblings and
                enclosing control flow.
              • Root output is flushed before preparation; pane output reaches only its pane;
                the grid and a surrounding capture receive no pane display or terminal bytes.
              • Readiness is exactly the runtime child-spawn event. Every earlier candidate is
                rejected by a crossed test, and a child that spawns then immediately exits is
                both ready and settled.
              • Every provider-preparation and pane-start position can fail without attaching
                a partial grid. All acquired pane work and finalizers settle, and simultaneous
                failures select the first authored ordinal.
              • After attach, one pane can succeed or fail while siblings remain live. Its
                final status remains visible until reader close.
              • Reader close, parent cancellation at preparation/readiness/active phases, and
                provider failure each perform complete teardown with the specified result and
                failure precedence. No later document sibling starts while any acquired pane
                or provider resource remains live.
              • One pane claim admits only one interactive operation at a time; distinct pane
                claims do not contend. A claim from another grid, ordinal, provider generation,
                or completed invocation authorizes nothing.
              • The default shell uses live host policy and the pane terminal; provider
                absence refuses before pane start or shell execution.
              • Completed replay performs no provider or pane work. Partial replay restores
                completed pane statuses, continues incomplete durable children, and refuses a
                changed layout before provider contact.
              • Retained and diagnostic data contain only provider-neutral layout and outcome
                facts.

              This Story owns TG6–TG10 and TG12–TG17, plus the controlled-provider half of
              TG18. TG5 and Agent-session contention in TG11 belong to the native-launch
              Story. The tmux half of TG18 belongs to the production-provider Story.

              Focused evidence

              Add the controlled provider and terminal-authority tests beside the core
              structured execution they exercise:

              deno task test packages/core/tests/terminal-grid.test.ts
              deno task test packages/runtime/tests/terminal-provider.test.ts

              The suite uses test-controlled readiness, settlement, close, failure, and
              teardown operations. It must prove provider non-observation and teardown
              ordering directly rather than infer them from process timing.

              Dependencies and exclusions

              Verification stack

              This Story is the third layer of #717's linear verification stack.

              Activity

              Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

              Metadata

              Metadata

              Assignees

              No one assigned

                Labels

                enhancementNew feature or request

                Projects

                No projects

                  Milestone

                  No milestone

                  Relationships

                  None yet

                  Development

                  No branches or pull requests

                  Issue actions

                  , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
                  Skip to content

                  Execute concurrent terminal panes through a replaceable provider #730

                  Description

                  @taras

                  Story

                  As an executable-document host, I want the panes in a terminal grid to execute
                  concurrently through one replaceable terminal provider, so the document keeps
                  one lifecycle and replay contract whether the presentation is tmux, a controlled
                  test surface, or a future native interface.

                  This is the provider-neutral execution Story under #717. It begins after #729
                  has frozen the structural language. Native Session.Launch integration and the
                  production tmux provider are separate consumers of the boundary established
                  here.

                  Contract

                  Core validates the complete resolved layout, takes the document execution's one
                  foreground-terminal lease, flushes root output, and issues one provider request
                  for the exact grid expansion. The host supplies a terminal provider and a
                  non-contextual terminal authority. The stable contextual API routes the request
                  and permits observation, narrowing, refusal, wrapping, and delegation; no
                  handler return value can authorize or settle a grid. Only the direct authority
                  can validate the request, mint one-use pane claims, and acquire or release root
                  and pane terminal ownership.

                  The provider prepares the whole composite while it remains hidden. Core creates
                  one durable child operation per authored pane ordinal and starts those children
                  concurrently. A paired pane expands its document flow in an isolated binding,
                  evaluation, checked-failure, and control-flow scope while inheriting the grid
                  site's providers, configuration, working directory, repository selection, and
                  bindings. A self-closing pane starts the host-configured default interactive
                  shell through its pane claim. Pane display reaches that pane only; the grid
                  renders "", and native terminal bytes are neither captured nor journaled.

                  Each pane becomes ready only when its first interactive child reports the
                  runtime's successful spawn event through the private one-use readiness latch in
                  its pane claim. Endpoint or PID allocation, preparation, first output, or child
                  settlement without a spawn event is not readiness. The provider attaches the
                  composite only after every pane is ready. Any provider-preparation or pane-start
                  failure before that barrier cancels every pane, awaits complete teardown,
                  discards the hidden composite, restores the root terminal, and reports the first
                  failure by authored pane order. Effects completed before the failed start remain
                  durable.

                  After attachment, pane success and ordinary failure are independent visible
                  statuses and do not cancel siblings. The composite remains visible after all
                  panes settle until the reader closes it. Close prevents new launches, cancels
                  live pane scopes, awaits every child and finalizer, destroys the exact
                  composite, restores the root terminal, releases its lease, and only then lets
                  the document continue. The first failed pane in authored order fails the grid
                  at close; close-induced cancellation is not a pane failure. Provider failure
                  cancels and fails the whole grid. Parent cancellation follows the same complete
                  teardown and remains cancellation.

                  The terminal authority and pane claims grant terminal ownership only. They
                  grant no Agent-session authority. This Story exposes the pane-scoped launch seam
                  that later integrations consume, but it neither changes Session.Launch nor
                  installs an Agent provider.

                  Durability and replay

                  The grid is one core-owned structured durable region. Its identity contains the
                  resolved columns and ordered pane forms and titles. Pane child identities derive
                  from the grid expansion and ordinal, never a title, schedule, or provider
                  identifier.

                  The completed record retains the provider-neutral layout, close kind, and
                  ordered pane outcomes after the ordinary secret gate. Completed replay restores
                  the exact result without contacting a terminal provider, expanding pane content,
                  or starting a shell. Partial replay compares the complete layout before provider
                  work, builds a fresh live composite, restores completed panes as statuses, and
                  continues incomplete pane children from their own durable histories. An
                  incomplete self-closing pane starts the current authorized default shell and
                  claims no terminal-history continuity.

                  Commands, sockets, paths, process identifiers, layout identifiers, argv,
                  environment, terminal bytes, and provider topology remain live provider state
                  and enter no public request result, retained identity, record, or diagnostic.

                  Acceptance

                  • A controlled provider that is not tmux runs one through eight panes using the
                    exact row-major layout from Describe terminal grids as executable document structure #729 and begins all authored pane operations
                    concurrently.
                  • Each pane inherits grid-site state but isolates its own later bindings,
                    contextual changes, checked failures, Break, and Return from siblings and
                    enclosing control flow.
                  • Root output is flushed before preparation; pane output reaches only its pane;
                    the grid and a surrounding capture receive no pane display or terminal bytes.
                  • Readiness is exactly the runtime child-spawn event. Every earlier candidate is
                    rejected by a crossed test, and a child that spawns then immediately exits is
                    both ready and settled.
                  • Every provider-preparation and pane-start position can fail without attaching
                    a partial grid. All acquired pane work and finalizers settle, and simultaneous
                    failures select the first authored ordinal.
                  • After attach, one pane can succeed or fail while siblings remain live. Its
                    final status remains visible until reader close.
                  • Reader close, parent cancellation at preparation/readiness/active phases, and
                    provider failure each perform complete teardown with the specified result and
                    failure precedence. No later document sibling starts while any acquired pane
                    or provider resource remains live.
                  • One pane claim admits only one interactive operation at a time; distinct pane
                    claims do not contend. A claim from another grid, ordinal, provider generation,
                    or completed invocation authorizes nothing.
                  • The default shell uses live host policy and the pane terminal; provider
                    absence refuses before pane start or shell execution.
                  • Completed replay performs no provider or pane work. Partial replay restores
                    completed pane statuses, continues incomplete durable children, and refuses a
                    changed layout before provider contact.
                  • Retained and diagnostic data contain only provider-neutral layout and outcome
                    facts.

                  This Story owns TG6–TG10 and TG12–TG17, plus the controlled-provider half of
                  TG18. TG5 and Agent-session contention in TG11 belong to the native-launch
                  Story. The tmux half of TG18 belongs to the production-provider Story.

                  Focused evidence

                  Add the controlled provider and terminal-authority tests beside the core
                  structured execution they exercise:

                  deno task test packages/core/tests/terminal-grid.test.ts
                  deno task test packages/runtime/tests/terminal-provider.test.ts

                  The suite uses test-controlled readiness, settlement, close, failure, and
                  teardown operations. It must prove provider non-observation and teardown
                  ordering directly rather than infer them from process timing.

                  Dependencies and exclusions

                  Verification stack

                  This Story is the third layer of #717's linear verification stack.

                  Activity

                  Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

                  Metadata

                  Metadata

                  Assignees

                  No one assigned

                    Labels

                    enhancementNew feature or request

                    Projects

                    No projects

                      Milestone

                      No milestone

                      Relationships

                      None yet

                      Development

                      No branches or pull requests

                      Issue actions

                      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
                      Skip to content

                      Execute concurrent terminal panes through a replaceable provider #730

                      Description

                      @taras

                      Story

                      As an executable-document host, I want the panes in a terminal grid to execute
                      concurrently through one replaceable terminal provider, so the document keeps
                      one lifecycle and replay contract whether the presentation is tmux, a controlled
                      test surface, or a future native interface.

                      This is the provider-neutral execution Story under #717. It begins after #729
                      has frozen the structural language. Native Session.Launch integration and the
                      production tmux provider are separate consumers of the boundary established
                      here.

                      Contract

                      Core validates the complete resolved layout, takes the document execution's one
                      foreground-terminal lease, flushes root output, and issues one provider request
                      for the exact grid expansion. The host supplies a terminal provider and a
                      non-contextual terminal authority. The stable contextual API routes the request
                      and permits observation, narrowing, refusal, wrapping, and delegation; no
                      handler return value can authorize or settle a grid. Only the direct authority
                      can validate the request, mint one-use pane claims, and acquire or release root
                      and pane terminal ownership.

                      The provider prepares the whole composite while it remains hidden. Core creates
                      one durable child operation per authored pane ordinal and starts those children
                      concurrently. A paired pane expands its document flow in an isolated binding,
                      evaluation, checked-failure, and control-flow scope while inheriting the grid
                      site's providers, configuration, working directory, repository selection, and
                      bindings. A self-closing pane starts the host-configured default interactive
                      shell through its pane claim. Pane display reaches that pane only; the grid
                      renders "", and native terminal bytes are neither captured nor journaled.

                      Each pane becomes ready only when its first interactive child reports the
                      runtime's successful spawn event through the private one-use readiness latch in
                      its pane claim. Endpoint or PID allocation, preparation, first output, or child
                      settlement without a spawn event is not readiness. The provider attaches the
                      composite only after every pane is ready. Any provider-preparation or pane-start
                      failure before that barrier cancels every pane, awaits complete teardown,
                      discards the hidden composite, restores the root terminal, and reports the first
                      failure by authored pane order. Effects completed before the failed start remain
                      durable.

                      After attachment, pane success and ordinary failure are independent visible
                      statuses and do not cancel siblings. The composite remains visible after all
                      panes settle until the reader closes it. Close prevents new launches, cancels
                      live pane scopes, awaits every child and finalizer, destroys the exact
                      composite, restores the root terminal, releases its lease, and only then lets
                      the document continue. The first failed pane in authored order fails the grid
                      at close; close-induced cancellation is not a pane failure. Provider failure
                      cancels and fails the whole grid. Parent cancellation follows the same complete
                      teardown and remains cancellation.

                      The terminal authority and pane claims grant terminal ownership only. They
                      grant no Agent-session authority. This Story exposes the pane-scoped launch seam
                      that later integrations consume, but it neither changes Session.Launch nor
                      installs an Agent provider.

                      Durability and replay

                      The grid is one core-owned structured durable region. Its identity contains the
                      resolved columns and ordered pane forms and titles. Pane child identities derive
                      from the grid expansion and ordinal, never a title, schedule, or provider
                      identifier.

                      The completed record retains the provider-neutral layout, close kind, and
                      ordered pane outcomes after the ordinary secret gate. Completed replay restores
                      the exact result without contacting a terminal provider, expanding pane content,
                      or starting a shell. Partial replay compares the complete layout before provider
                      work, builds a fresh live composite, restores completed panes as statuses, and
                      continues incomplete pane children from their own durable histories. An
                      incomplete self-closing pane starts the current authorized default shell and
                      claims no terminal-history continuity.

                      Commands, sockets, paths, process identifiers, layout identifiers, argv,
                      environment, terminal bytes, and provider topology remain live provider state
                      and enter no public request result, retained identity, record, or diagnostic.

                      Acceptance

                      • A controlled provider that is not tmux runs one through eight panes using the
                        exact row-major layout from Describe terminal grids as executable document structure #729 and begins all authored pane operations
                        concurrently.
                      • Each pane inherits grid-site state but isolates its own later bindings,
                        contextual changes, checked failures, Break, and Return from siblings and
                        enclosing control flow.
                      • Root output is flushed before preparation; pane output reaches only its pane;
                        the grid and a surrounding capture receive no pane display or terminal bytes.
                      • Readiness is exactly the runtime child-spawn event. Every earlier candidate is
                        rejected by a crossed test, and a child that spawns then immediately exits is
                        both ready and settled.
                      • Every provider-preparation and pane-start position can fail without attaching
                        a partial grid. All acquired pane work and finalizers settle, and simultaneous
                        failures select the first authored ordinal.
                      • After attach, one pane can succeed or fail while siblings remain live. Its
                        final status remains visible until reader close.
                      • Reader close, parent cancellation at preparation/readiness/active phases, and
                        provider failure each perform complete teardown with the specified result and
                        failure precedence. No later document sibling starts while any acquired pane
                        or provider resource remains live.
                      • One pane claim admits only one interactive operation at a time; distinct pane
                        claims do not contend. A claim from another grid, ordinal, provider generation,
                        or completed invocation authorizes nothing.
                      • The default shell uses live host policy and the pane terminal; provider
                        absence refuses before pane start or shell execution.
                      • Completed replay performs no provider or pane work. Partial replay restores
                        completed pane statuses, continues incomplete durable children, and refuses a
                        changed layout before provider contact.
                      • Retained and diagnostic data contain only provider-neutral layout and outcome
                        facts.

                      This Story owns TG6–TG10 and TG12–TG17, plus the controlled-provider half of
                      TG18. TG5 and Agent-session contention in TG11 belong to the native-launch
                      Story. The tmux half of TG18 belongs to the production-provider Story.

                      Focused evidence

                      Add the controlled provider and terminal-authority tests beside the core
                      structured execution they exercise:

                      deno task test packages/core/tests/terminal-grid.test.ts
                      deno task test packages/runtime/tests/terminal-provider.test.ts

                      The suite uses test-controlled readiness, settlement, close, failure, and
                      teardown operations. It must prove provider non-observation and teardown
                      ordering directly rather than infer them from process timing.

                      Dependencies and exclusions

                      Verification stack

                      This Story is the third layer of #717's linear verification stack.

                      Activity

                      Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

                      Metadata

                      Metadata

                      Assignees

                      No one assigned

                        Labels

                        enhancementNew feature or request

                        Projects

                        No projects

                          Milestone

                          No milestone

                          Relationships

                          None yet

                          Development

                          No branches or pull requests

                          Issue actions

                          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
                          Skip to content

                          Execute concurrent terminal panes through a replaceable provider #730

                          Description

                          @taras

                          Story

                          As an executable-document host, I want the panes in a terminal grid to execute
                          concurrently through one replaceable terminal provider, so the document keeps
                          one lifecycle and replay contract whether the presentation is tmux, a controlled
                          test surface, or a future native interface.

                          This is the provider-neutral execution Story under #717. It begins after #729
                          has frozen the structural language. Native Session.Launch integration and the
                          production tmux provider are separate consumers of the boundary established
                          here.

                          Contract

                          Core validates the complete resolved layout, takes the document execution's one
                          foreground-terminal lease, flushes root output, and issues one provider request
                          for the exact grid expansion. The host supplies a terminal provider and a
                          non-contextual terminal authority. The stable contextual API routes the request
                          and permits observation, narrowing, refusal, wrapping, and delegation; no
                          handler return value can authorize or settle a grid. Only the direct authority
                          can validate the request, mint one-use pane claims, and acquire or release root
                          and pane terminal ownership.

                          The provider prepares the whole composite while it remains hidden. Core creates
                          one durable child operation per authored pane ordinal and starts those children
                          concurrently. A paired pane expands its document flow in an isolated binding,
                          evaluation, checked-failure, and control-flow scope while inheriting the grid
                          site's providers, configuration, working directory, repository selection, and
                          bindings. A self-closing pane starts the host-configured default interactive
                          shell through its pane claim. Pane display reaches that pane only; the grid
                          renders "", and native terminal bytes are neither captured nor journaled.

                          Each pane becomes ready only when its first interactive child reports the
                          runtime's successful spawn event through the private one-use readiness latch in
                          its pane claim. Endpoint or PID allocation, preparation, first output, or child
                          settlement without a spawn event is not readiness. The provider attaches the
                          composite only after every pane is ready. Any provider-preparation or pane-start
                          failure before that barrier cancels every pane, awaits complete teardown,
                          discards the hidden composite, restores the root terminal, and reports the first
                          failure by authored pane order. Effects completed before the failed start remain
                          durable.

                          After attachment, pane success and ordinary failure are independent visible
                          statuses and do not cancel siblings. The composite remains visible after all
                          panes settle until the reader closes it. Close prevents new launches, cancels
                          live pane scopes, awaits every child and finalizer, destroys the exact
                          composite, restores the root terminal, releases its lease, and only then lets
                          the document continue. The first failed pane in authored order fails the grid
                          at close; close-induced cancellation is not a pane failure. Provider failure
                          cancels and fails the whole grid. Parent cancellation follows the same complete
                          teardown and remains cancellation.

                          The terminal authority and pane claims grant terminal ownership only. They
                          grant no Agent-session authority. This Story exposes the pane-scoped launch seam
                          that later integrations consume, but it neither changes Session.Launch nor
                          installs an Agent provider.

                          Durability and replay

                          The grid is one core-owned structured durable region. Its identity contains the
                          resolved columns and ordered pane forms and titles. Pane child identities derive
                          from the grid expansion and ordinal, never a title, schedule, or provider
                          identifier.

                          The completed record retains the provider-neutral layout, close kind, and
                          ordered pane outcomes after the ordinary secret gate. Completed replay restores
                          the exact result without contacting a terminal provider, expanding pane content,
                          or starting a shell. Partial replay compares the complete layout before provider
                          work, builds a fresh live composite, restores completed panes as statuses, and
                          continues incomplete pane children from their own durable histories. An
                          incomplete self-closing pane starts the current authorized default shell and
                          claims no terminal-history continuity.

                          Commands, sockets, paths, process identifiers, layout identifiers, argv,
                          environment, terminal bytes, and provider topology remain live provider state
                          and enter no public request result, retained identity, record, or diagnostic.

                          Acceptance

                          • A controlled provider that is not tmux runs one through eight panes using the
                            exact row-major layout from Describe terminal grids as executable document structure #729 and begins all authored pane operations
                            concurrently.
                          • Each pane inherits grid-site state but isolates its own later bindings,
                            contextual changes, checked failures, Break, and Return from siblings and
                            enclosing control flow.
                          • Root output is flushed before preparation; pane output reaches only its pane;
                            the grid and a surrounding capture receive no pane display or terminal bytes.
                          • Readiness is exactly the runtime child-spawn event. Every earlier candidate is
                            rejected by a crossed test, and a child that spawns then immediately exits is
                            both ready and settled.
                          • Every provider-preparation and pane-start position can fail without attaching
                            a partial grid. All acquired pane work and finalizers settle, and simultaneous
                            failures select the first authored ordinal.
                          • After attach, one pane can succeed or fail while siblings remain live. Its
                            final status remains visible until reader close.
                          • Reader close, parent cancellation at preparation/readiness/active phases, and
                            provider failure each perform complete teardown with the specified result and
                            failure precedence. No later document sibling starts while any acquired pane
                            or provider resource remains live.
                          • One pane claim admits only one interactive operation at a time; distinct pane
                            claims do not contend. A claim from another grid, ordinal, provider generation,
                            or completed invocation authorizes nothing.
                          • The default shell uses live host policy and the pane terminal; provider
                            absence refuses before pane start or shell execution.
                          • Completed replay performs no provider or pane work. Partial replay restores
                            completed pane statuses, continues incomplete durable children, and refuses a
                            changed layout before provider contact.
                          • Retained and diagnostic data contain only provider-neutral layout and outcome
                            facts.

                          This Story owns TG6–TG10 and TG12–TG17, plus the controlled-provider half of
                          TG18. TG5 and Agent-session contention in TG11 belong to the native-launch
                          Story. The tmux half of TG18 belongs to the production-provider Story.

                          Focused evidence

                          Add the controlled provider and terminal-authority tests beside the core
                          structured execution they exercise:

                          deno task test packages/core/tests/terminal-grid.test.ts
                          deno task test packages/runtime/tests/terminal-provider.test.ts

                          The suite uses test-controlled readiness, settlement, close, failure, and
                          teardown operations. It must prove provider non-observation and teardown
                          ordering directly rather than infer them from process timing.

                          Dependencies and exclusions

                          Verification stack

                          This Story is the third layer of #717's linear verification stack.

                          Activity

                          Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

                          Metadata

                          Metadata

                          Assignees

                          No one assigned

                            Labels

                            enhancementNew feature or request

                            Projects

                            No projects

                              Milestone

                              No milestone

                              Relationships

                              None yet

                              Development

                              No branches or pull requests

                              Issue actions

                              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
                              Skip to content

                              Execute concurrent terminal panes through a replaceable provider #730

                              Description

                              @taras

                              Story

                              As an executable-document host, I want the panes in a terminal grid to execute
                              concurrently through one replaceable terminal provider, so the document keeps
                              one lifecycle and replay contract whether the presentation is tmux, a controlled
                              test surface, or a future native interface.

                              This is the provider-neutral execution Story under #717. It begins after #729
                              has frozen the structural language. Native Session.Launch integration and the
                              production tmux provider are separate consumers of the boundary established
                              here.

                              Contract

                              Core validates the complete resolved layout, takes the document execution's one
                              foreground-terminal lease, flushes root output, and issues one provider request
                              for the exact grid expansion. The host supplies a terminal provider and a
                              non-contextual terminal authority. The stable contextual API routes the request
                              and permits observation, narrowing, refusal, wrapping, and delegation; no
                              handler return value can authorize or settle a grid. Only the direct authority
                              can validate the request, mint one-use pane claims, and acquire or release root
                              and pane terminal ownership.

                              The provider prepares the whole composite while it remains hidden. Core creates
                              one durable child operation per authored pane ordinal and starts those children
                              concurrently. A paired pane expands its document flow in an isolated binding,
                              evaluation, checked-failure, and control-flow scope while inheriting the grid
                              site's providers, configuration, working directory, repository selection, and
                              bindings. A self-closing pane starts the host-configured default interactive
                              shell through its pane claim. Pane display reaches that pane only; the grid
                              renders "", and native terminal bytes are neither captured nor journaled.

                              Each pane becomes ready only when its first interactive child reports the
                              runtime's successful spawn event through the private one-use readiness latch in
                              its pane claim. Endpoint or PID allocation, preparation, first output, or child
                              settlement without a spawn event is not readiness. The provider attaches the
                              composite only after every pane is ready. Any provider-preparation or pane-start
                              failure before that barrier cancels every pane, awaits complete teardown,
                              discards the hidden composite, restores the root terminal, and reports the first
                              failure by authored pane order. Effects completed before the failed start remain
                              durable.

                              After attachment, pane success and ordinary failure are independent visible
                              statuses and do not cancel siblings. The composite remains visible after all
                              panes settle until the reader closes it. Close prevents new launches, cancels
                              live pane scopes, awaits every child and finalizer, destroys the exact
                              composite, restores the root terminal, releases its lease, and only then lets
                              the document continue. The first failed pane in authored order fails the grid
                              at close; close-induced cancellation is not a pane failure. Provider failure
                              cancels and fails the whole grid. Parent cancellation follows the same complete
                              teardown and remains cancellation.

                              The terminal authority and pane claims grant terminal ownership only. They
                              grant no Agent-session authority. This Story exposes the pane-scoped launch seam
                              that later integrations consume, but it neither changes Session.Launch nor
                              installs an Agent provider.

                              Durability and replay

                              The grid is one core-owned structured durable region. Its identity contains the
                              resolved columns and ordered pane forms and titles. Pane child identities derive
                              from the grid expansion and ordinal, never a title, schedule, or provider
                              identifier.

                              The completed record retains the provider-neutral layout, close kind, and
                              ordered pane outcomes after the ordinary secret gate. Completed replay restores
                              the exact result without contacting a terminal provider, expanding pane content,
                              or starting a shell. Partial replay compares the complete layout before provider
                              work, builds a fresh live composite, restores completed panes as statuses, and
                              continues incomplete pane children from their own durable histories. An
                              incomplete self-closing pane starts the current authorized default shell and
                              claims no terminal-history continuity.

                              Commands, sockets, paths, process identifiers, layout identifiers, argv,
                              environment, terminal bytes, and provider topology remain live provider state
                              and enter no public request result, retained identity, record, or diagnostic.

                              Acceptance

                              • A controlled provider that is not tmux runs one through eight panes using the
                                exact row-major layout from Describe terminal grids as executable document structure #729 and begins all authored pane operations
                                concurrently.
                              • Each pane inherits grid-site state but isolates its own later bindings,
                                contextual changes, checked failures, Break, and Return from siblings and
                                enclosing control flow.
                              • Root output is flushed before preparation; pane output reaches only its pane;
                                the grid and a surrounding capture receive no pane display or terminal bytes.
                              • Readiness is exactly the runtime child-spawn event. Every earlier candidate is
                                rejected by a crossed test, and a child that spawns then immediately exits is
                                both ready and settled.
                              • Every provider-preparation and pane-start position can fail without attaching
                                a partial grid. All acquired pane work and finalizers settle, and simultaneous
                                failures select the first authored ordinal.
                              • After attach, one pane can succeed or fail while siblings remain live. Its
                                final status remains visible until reader close.
                              • Reader close, parent cancellation at preparation/readiness/active phases, and
                                provider failure each perform complete teardown with the specified result and
                                failure precedence. No later document sibling starts while any acquired pane
                                or provider resource remains live.
                              • One pane claim admits only one interactive operation at a time; distinct pane
                                claims do not contend. A claim from another grid, ordinal, provider generation,
                                or completed invocation authorizes nothing.
                              • The default shell uses live host policy and the pane terminal; provider
                                absence refuses before pane start or shell execution.
                              • Completed replay performs no provider or pane work. Partial replay restores
                                completed pane statuses, continues incomplete durable children, and refuses a
                                changed layout before provider contact.
                              • Retained and diagnostic data contain only provider-neutral layout and outcome
                                facts.

                              This Story owns TG6–TG10 and TG12–TG17, plus the controlled-provider half of
                              TG18. TG5 and Agent-session contention in TG11 belong to the native-launch
                              Story. The tmux half of TG18 belongs to the production-provider Story.

                              Focused evidence

                              Add the controlled provider and terminal-authority tests beside the core
                              structured execution they exercise:

                              deno task test packages/core/tests/terminal-grid.test.ts
                              deno task test packages/runtime/tests/terminal-provider.test.ts

                              The suite uses test-controlled readiness, settlement, close, failure, and
                              teardown operations. It must prove provider non-observation and teardown
                              ordering directly rather than infer them from process timing.

                              Dependencies and exclusions

                              Verification stack

                              This Story is the third layer of #717's linear verification stack.

                              Activity

                              Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

                              Metadata

                              Metadata

                              Assignees

                              No one assigned

                                Labels

                                enhancementNew feature or request

                                Projects

                                No projects

                                  Milestone

                                  No milestone

                                  Relationships

                                  None yet

                                  Development

                                  No branches or pull requests

                                  Issue actions