melandlabs/openloomi

Is your feature request related to a problem? Please describe. Loop today is all-or-nothing per toolkit: enabling Linear means watching every issue in every team the user has access to. For projects like TN-Alpha with sensitive or noisy neighbors, users want to scope Loop to a single Linear project (or a labeled set of issues). The current mute-rules-after-the-fact approach still pays the polling and classification cost. Describe the solution you'd like In the Loop settings panel, replace the per-toolkit toggle with a per-target scope picker: Linear: pick team + project (or "issues labeled X") Gmail / Calendar: account-level (already supported via #360) plus optional label / calendar filter GitHub: repo allowlist Persist scope via the existing MuteScope discriminated union (apps/web/lib/loop/types.ts:381-401), which already supports { kind: "linear_issue", team, project }. Pre-flight check: when the picker detects a scope change, surface a one-line summary "Loop will now only watch

Is your feature request related to a problem? Please describe. Even after memory is saved, the user has no in-app way to verify it's actually retrievable in a future session. The current "Workflow generated Markdown" step produces an output file but provides no in-app confirmation, no location indicator, and no follow-up to test recall. From the user's perspective, the action's success state is opaque. Describe the solution you'd like A four-step UX in the memory workflow surface: Preview — render the generated memory in-app (read-only, structured sections: Goals / Tasks / Owners / Branches / Deploy / Risks). Confirm — user explicitly clicks "Save to long-term memory". Show the destination data/memory/projects/<slug>.md and the timestamp. Write — atomic save; on failure, keep the preview visible and surface the error with retry. Verify in new Session — a button that opens a fresh chat session with the project name pre-filled, runs a retrieval probe, and shows whether the long-

Describe the bug When running the web app with pnpm dev, the app gets stuck on the guest login page and never reaches the home page. The browser is redirected to: /guest-login?callbackUrl=%2F The terminal shows: GET /guest-login?callbackUrl=%2F 200 It looks like the guest login flow does not successfully create a browser session in web-only dev mode. A direct request to /api/auth/guest redirects back to /, but the browser still ends up on /guest-login. To Reproduce Steps to reproduce the behavior: Clone the repository. Install dependencies: pnpm install Start the web app: pnpm dev Open the local app in a browser: http://127.0.0.1:3515 The browser redirects to: /guest-login?callbackUrl=%2F The page keeps loading and never reaches the home page. Expected behavior pnpm dev should either successfully create a guest session and redirect to /, or clearly document that local development should use pnpm tauri:dev instead. Screenshots Not available. Desktop OS: Windows Browser: C

Problem When users configure their own API keys, API usage and spending can feel like a black box. Users can hit provider-side billing failures such as 402 Insufficient Balance, but before that point there is no obvious in-app feedback about how much the configured key has been used or what the approximate spend is. This makes it hard for users to build trust in BYOK mode and understand whether OpenLoomi is using their API key lightly or heavily. Desired experience Add API usage / cost visibility for user-configured API keys in two places: A detailed usage surface in the API provider settings page. A lightweight always-visible usage summary under the desktop Loomi Pet, so users can intuitively feel ongoing API consumption without opening settings. The detailed settings view could include: Current provider and model in use Recent requests count Input tokens, output tokens, and total tokens Estimated cost by provider/model, with a clear “estimated” label Usage over time, such as t

Problem When a configured API provider returns a payment/quota error such as HTTP 402 with Insufficient Balance, OpenLoomi currently surfaces a raw technical error in the chat and then shows a generic error card. Observed user-facing output: API Error: 402 {"error":{"message":"Insufficient Balance","type":"unknown_error","param":null,"code":"invalid_request_error"}} An Error Occurred - Please try again later - Contact support if the problem persists This makes the failure look like an OpenLoomi generic error instead of telling the user that the configured API provider account likely has insufficient balance, quota, or billing status. Expected behavior For provider-side 402/payment/quota failures, show an actionable message such as: The API provider returned a 402 billing/quota error: insufficient balance. Please check the API key's provider account balance, billing status, or quota. Raw provider JSON should not be the primary chat message. If needed, keep it in logs or an expandabl