feat: background-task tracking and task-progress parity across claude/opencode/hermes/pi

.agents/skills/release-beta/SKILL.md

@@ -1,13 +1,9 @@
 ---
 name: release-beta
-description: Cut a beta release of Paseo. Use when the user says "release beta", "cut a beta", "ship a beta", "beta release", or "/release-beta". Betas are release candidates on the beta channel — they carry an in-place changelog entry, don't move the website download target, and publish npm only on the beta dist-tag.
+description: Cut a beta release of Paseo. Use when the user says "release beta", "cut a beta", "ship a beta", "beta release", or "/release-beta".
 user-invocable: true
 ---
 
 # Release beta
 
-Read `docs/release.md` in the Paseo repo and follow the **Beta flow** section end-to-end. Run the **Beta release** completion checklist at the bottom of that doc.
-
-During preparation, classify the previous-stable-to-`HEAD` diff as patch or minor and show the target version and rationale to the user. Agents never select a major version autonomously.
-
-Each beta updates an in-place `CHANGELOG.md` entry (`## X.Y.Z-beta.N`) that gets overwritten at promotion, and npm publishes only on the explicit `beta` dist-tag.
+Follow the **Beta flow** and **Beta release** completion checklist in `docs/release.md` end-to-end.

.agents/skills/release-stable/SKILL.md

@@ -6,8 +6,4 @@ user-invocable: true
 
 # Release stable
 
-Read `docs/release.md` in the Paseo repo and follow the **Standard release (stable)** flow if cutting fresh, or the **Beta flow** promotion step if promoting an existing beta. Run the **Stable release (or promotion)** completion checklist at the bottom of that doc.
-
-For a fresh release, classify the previous-stable-to-`HEAD` diff as patch or minor and show the target version and rationale to the user. Agents never select a major version autonomously.
-
-The doc covers the changelog, pre-release sanity check, and post-release babysit pattern. Don't skip steps.
+Follow the applicable flow and the **Stable release (or promotion)** completion checklist in `docs/release.md` end-to-end.

.claude/skills/release-beta

@@ -1 +1 @@
-../../.agents/skills/release-beta
+unsupported reparse tag 0xa000000c

.claude/skills/release-stable

@@ -1 +1 @@
-../../.agents/skills/release-stable
+unsupported reparse tag 0xa000000c

.github/ISSUE_TEMPLATE/bug-report.yml

@@ -6,7 +6,7 @@ body:
   - type: markdown
     attributes:
       value: |
-        I'm a solo maintainer and don't always keep up with GitHub Issues daily. If something is urgent or blocking you, [Discord](https://discord.gg/jz8T2uahpH) is the fastest place to reach me.
+        Issues are only for bugs. Product discussions go in [GitHub Discussions](https://github.com/getpaseo/paseo/discussions) or `#product` in [Discord](https://discord.gg/jz8T2uahpH) — feature requests opened as issues get closed automatically.
 
         Before opening, please:
 

.github/ISSUE_TEMPLATE/config.yml

@@ -1,5 +1,8 @@
 blank_issues_enabled: false
 contact_links:
-  - name: Discord
+  - name: Product discussion on Discord
     url: https://discord.gg/jz8T2uahpH
-    about: Urgent or blocking issues, quick questions, sharing a video of a bug, or anything that's better as a chat.
+    about: Product discussion, including feature requests
+  - name: Product discussion on GitHub
+    url: https://github.com/getpaseo/paseo/discussions
+    about: Product discussion, including feature requests

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,43 +1,48 @@
 <!--
 Please follow this template. The PR template applies whether you opened the PR via the web UI, `gh pr create`, or any other tool.
 
-If you're fixing an objective bug or a small focused issue, this should be quick. Big PRs without a prior issue or design discussion are likely to be closed or scoped down. See CONTRIBUTING.md.
+You MUST read CONTRIBUTING.md before sending a PR.
 -->
 
 ### Linked issue
 
 Closes #
 
-<!-- Bug fixes and behavior changes should reference an issue. Pure docs and refactors can skip this. -->
-
 ### Type of change
 
 - [ ] Bug fix
-- [ ] New feature (with prior issue + design alignment)
-- [ ] Refactor / code improvement
+- [ ] New feature
+- [ ] Enhancement
+- [ ] Refactor
 - [ ] Docs
 
-### What does this PR do
+### Reasoning
+
+<!-- A short description of the reasoning of this change in your own words. What was wrong, and how do you hope this PR fixes it. If you can't explain this briefly, the PR is probably too big. This description must be grounded in real user flows and framed as value provided to Paseo users. -->
+
+### Goals
 
-<!-- A short description of the change in your own words. What was wrong, what you changed, why it works. If you can't explain this briefly, the PR is probably too big. -->
+<!-- A bullet list of what this PR wants to accomplish, include requirements and acceptance criteria. This helps lock down the scope of the PR and prevent expanding scope over the intended goal. -->
 
-### How did you verify it
+### Non-goals
+
+<!-- A bullet list of what this PR does not want to accomplish. Add any intentional trade offs taken. This helps lock down the scope of the PR and prevent expanding scope over the intended goal. -->
+
+### QA
 
 <!--
 This is the section I read most carefully. I need to see that *you* tested this, not that the diff looks plausible.
 
 - For UI changes: a screenshot or short video on every affected platform (mobile, web, desktop). UI claims without visual proof are not enough.
 - For behavior changes: the actual steps you ran, and what you observed.
 - For bug fixes: how you reproduced the bug before, and confirmed it's fixed after.
-
-AI-generated PR descriptions are fine in principle. AI-generated *verification claims* with no actual testing behind them are not, and they're easy to spot.
 -->
 
 ### Checklist
 
-- [ ] One focused change. Unrelated cleanups split out.
+- [ ] One focused change
 - [ ] `npm run typecheck` passes
 - [ ] `npm run lint` passes
-- [ ] `npm run format` ran (Biome)
-- [ ] UI changes include screenshots or video for every affected platform
+- [ ] `npm run format` passes
+- [ ] QA evidence
 - [ ] Tests added or updated where it made sense

.github/ci-paths.yml

@@ -0,0 +1,71 @@
+# Pull-request checks are routed by the behavior they prove. Package consumers
+# do not inherit their dependencies' test suites; main and manual runs execute
+# every contract regardless of these paths.
+routing:
+  - ".github/ci-paths.yml"
+
+workspace:
+  - ".mise.toml"
+  - ".tool-versions"
+  - "package.json"
+  - "package-lock.json"
+  - "patches/**"
+  - "scripts/**"
+  - "tsconfig.json"
+  - "tsconfig.base.json"
+  - "vitest.config.ts"
+
+ci:
+  - ".github/actions/**"
+  - ".github/workflows/ci.yml"
+
+format:
+  - ".agents/**/*.{cjs,css,html,js,json,jsonc,jsx,md,mjs,ts,tsx,yaml,yml}"
+  - ".github/**/*.{cjs,css,html,js,json,jsonc,jsx,md,mjs,ts,tsx,yaml,yml}"
+  - "**/*.{cjs,css,html,js,json,jsonc,jsx,md,mjs,ts,tsx,yaml,yml}"
+  - "packages/expo-two-way-audio/**"
+
+quality:
+  - "**/*.{cjs,js,json,jsx,mjs,ts,tsx}"
+  - "packages/expo-two-way-audio/**"
+
+hub:
+  - "packages/cli/src/commands/hub/**"
+  - "packages/server/src/server/hub/**"
+
+server:
+  - "packages/server/**"
+  - "packages/app/e2e/support/fixtures/recording.*"
+
+desktop:
+  - "packages/desktop/**"
+  - "packages/app/src/desktop/**"
+  - "packages/server/src/server/browser-tools/**"
+  - "packages/app/e2e/support/**"
+  - "packages/app/*config.{cjs,js,ts}"
+  - "packages/app/package.json"
+
+app:
+  - "packages/app/**"
+  - "packages/expo-two-way-audio/**"
+
+sdk:
+  - "packages/client/**"
+  - "packages/highlight/**"
+  - "packages/protocol/**"
+
+browser:
+  - "packages/app/src/!(desktop)/**"
+  - "packages/app/e2e/browser/**"
+  - "packages/app/e2e/support/**"
+  - "packages/app/assets/**"
+  - "packages/app/public/**"
+  - "packages/app/index.ts"
+  - "packages/app/*config.{cjs,js,ts}"
+  - "packages/app/package.json"
+
+relay:
+  - "packages/relay/**"
+
+cli:
+  - "packages/cli/**"