fix: preserve profile scope across loop run views - #583

@richardfogaca is attempting to deploy a commit to the Compozy Team on Vercel.

A member of the Team first needs to authorize it.

No actionable comments were generated in the recent review. 🎉

Walkthrough

Loop run reads, streams, mutations, caches, route preloads, and server handlers now carry profile scope. Tests cover profile mismatches, profile switching, owner resolution, cache isolation, and cross-workspace preloading.

Changes

Profile-scoped loop execution

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~25 minutes

Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 7f6f2

This change keeps the find-bar committed-query test behavior while using paste input to avoid intermediate debounce effects. No merge-blocking risk remains.

Sequence Diagram(s)

sequenceDiagram
  participant ProfileSelector
  participant LoopRunHook
  participant QueryOptions
  participant LoopAPI
  ProfileSelector->>LoopRunHook: select profile
  LoopRunHook->>QueryOptions: build profile-scoped query
  QueryOptions->>LoopAPI: request run data with profile
  LoopAPI-->>QueryOptions: return scoped run data
  QueryOptions-->>LoopRunHook: update profile-scoped cache
  LoopRunHook-->>ProfileSelector: render selected run

• Fix all pre-merge checks with AI

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Confidence Score: 5/5

The PR appears safe to merge with no outstanding correctness, security, or repository-rule findings.

The current implementation consistently binds Loop reads, projections, streams, cache entries, preloads, and controls to the selected or authoritative owner Profile. All previous findings are either fully fixed or withdrawn, and no new changes were made after the previous review SHA.

sequenceDiagram
    participant UI as Loop run view
    participant Scope as Workspace Profile lens
    participant Cache as Query cache
    participant API as Loop API
    participant Guard as Profile guard
    participant Run as Loop service

    UI->>Scope: Resolve selected Profile scope
    Scope-->>UI: "profile=name or all_profiles=true"
    UI->>Cache: Read run using scoped query key
    Cache->>API: Scoped detail/projection request
    API->>Guard: Resolve run owner and match read scope
    Guard->>Run: Read authorized run or projection
    Run-->>UI: Profile-owned data
    UI->>API: Control using resolved owner Profile
    API->>Guard: Verify owner-bound mutation scope
    Guard->>Run: Apply lifecycle control

_{Reviews (4): Last reviewed commit: "test: align memory fixtures and stabiliz..." | Re-trigger Greptile}

Refreshed authoritative run ownership before controls, resolved route preloads through the destination workspace's Profile lens, and preserved the projection endpoints' existing not-found response through the ownership guard. Added renamed-owner, cross-workspace preload, and real browser Profile/reload/All Profiles control coverage. Corrected the shared Knowledge browser fixture's portaled-dialog locators.

Impact audit (recorded here per docs/_memory/change-impact.md): native tool IDs, descriptors, and capability gates are unchanged; existing CLI projection errors remain compatible. No extension, bridge SDK, hook, configuration, or registry changes. Workspace IDs and Profile scope remain bound through HTTP/UDS guards, query keys, preloads, and SSE; foreign Profile reads remain not found. Official skill instructions already use the existing Profile contract, so no skill changes are needed. Loop Web reads/controls and generated projection contracts are affected; the existing Profile QA scenario owns the browser evidence. No persisted-state migration or new public selector is introduced.

The shared Knowledge browser failure also required explicitly enabling memory in that journey after the opt-in default changed. The harness now exposes a per-journey option; other journeys retain the default.

Validation: the daemon-served Profile browser journey passes (owning/foreign reads, reload, aggregate navigation, and confirmed owner-bound cancellation); the complete Knowledge browser journey passes; the unchanged CLI projection journey passes with race detection. The QA scenario now records the bounded Loop verdict.

Updated the three request-response E2E matchers to inspect the URL pathname now that owner-bound requests include a Profile query parameter; status, persisted state, and submitted JSON assertions remain intact.

All three previously failing response journeys now pass, including the real daemon enum-ask completion and both browser rendering journeys.

Final make gate passes on the complete batch: generated contracts, API race tests, frontend lint/typecheck, and all 7,113 web tests. Preview authorization remains a team-owned blocker.

Aligned the shared memory fixture declarations and wiring with main, eliminating the duplicate key introduced by overlapping additions in the PR merge. Stabilized the committed-query session-search test by pasting the complete query, so a debounced partial query cannot consume its single mocked response; all request, result-count, and highlighting assertions remain intact.

The focused six-test search suite and final make gate pass, including all 7,113 web tests. The verified Loop and Knowledge browser regressions are unchanged.

Current-head desktop CI has the same E2E-004 launch-burst failure as #582: 28 cases pass, but the window remains on /tasks rather than the final /settings/general deep link. #581 passes the complete desktop lane with identical desktop source. The root cause is not yet established; a targeted rerun or desktop timing investigation is needed. My rerun request for the shared failure was rejected with HTTP 403 (repository admin rights required).

All other current-head CI checks have now passed, including frontend, backend race suites, runtime E2E, and all four browser shards. The combined E2E result is red solely because of the desktop failure.