Skip to content

[Task] Track runtime boundary hardening follow-ups #414

@Astro-Han

Description

@Astro-Han

Goal

Track the remaining runtime-boundary hardening work that was intentionally left after the narrower fixes in #412 and #413.

This is a tracker issue, not a directly implementable PR. It should stay open only while it helps keep the child tasks visible. Each implementation must happen through a smaller child issue or PR with its own scope and verification.

Scope

In scope for this tracker:

  • Keep the runtime-boundary follow-up map current.
  • Split broad architecture work into review-sized child issues before implementation.
  • Link child PRs or issues back here when they land.
  • Close this tracker only when the remaining useful follow-ups are either completed, superseded, or moved into clearer standalone issues.

Tracked boundary areas:

  1. Navigation ownership

    • Core route-ownership hardening for openProject(projectRoot), openSession(directory, sessionID), and newSession(directory) landed in [Task] Harden interaction locks and session route ownership #413.
    • Keep explicit session URLs as the source of truth for session pages.
    • Any remaining work here should be a narrower follow-up, not a reopening of the original broad route-ownership task.
  2. Interaction locks

  3. Desktop runtime manifest

    • Define the packaged native/runtime resources the embedded desktop runtime requires.
    • Keep watcher/native dependency packaging from being rediscovered by accident.
    • Make packaging config and packaging tests read from one manifest-like source where practical.
  4. Diagnostics

    • Renderer diagnostics precedent landed in [Task] Add renderer diagnostics for session jump and flicker observability #389 for session jump and flicker observability.
    • Remaining work here should stay focused on runtime-boundary diagnostics that are still missing, especially route-action and interaction-lock-specific signals where needed.
    • Prefer data that helps debug packaged-app failures and agent-led triage.

Out of scope

  • Do not implement all four areas in one PR.
  • Do not rewrite the router or change route shapes from this tracker alone.
  • Do not replace Solid, Electron, the sidecar, or the SDK layer.
  • Do not include a normalized entity-store rewrite, timeline virtualization, or broad prefetch scheduler work.
  • Do not create local-only design docs unless they are tied to an implementation PR.

Relevant files or context

Related context:

Likely areas:

  • packages/app/src/pages/layout.tsx
  • packages/app/src/pages/layout/helpers.ts
  • packages/app/src/pages/session/helpers.ts
  • packages/ui/src/components/resize-handle.tsx
  • packages/desktop-electron/electron-builder.config.ts
  • packages/desktop-electron/scripts/prepare-embedded-server.ts
  • packages/app/e2e/sidebar/
  • packages/app/e2e/commands/

Verification

For each child PR or child issue:

  • Add focused unit tests for the boundary contract being changed.
  • Add or update the smallest relevant user-path E2E coverage, especially delayed route stability and post-interaction clickability.
  • Run targeted app/ui typechecks and affected Playwright specs.
  • Confirm there are no route-shape, product-copy, or broad layout changes unless that child issue explicitly asks for them.

Priority

P2.

This is important architecture hardening, but concrete user-visible or release-blocking regressions should stay in narrower P1 issues. Do not raise this tracker just because one child task becomes urgent; raise that child issue instead.

Execution mode

Agent should propose a small child issue or PR plan before editing. Keep each implementation independently reviewable and reversible.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Medium priorityappApplication behavior and product flowsplatformElectron shell, OS integration, packaging, updater, signing, paths, and permissionstaskNarrow execution, audit, spike, migration, tracking, or upstream follow-up work

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions