Click-to-Call: Dial Phone Numbers Directly from Any App

.gitignore

@@ -38,13 +38,14 @@ coderabbit-update-*/
 # mastermind (local knowledge base)
 .knowledge/
 
+# OpenWolf local tooling state
+.wolf/
+
 # MSI test harness artifacts
 scripts/msi-test/logs/
 scripts/msi-test/.known_hosts
 
 # dylib artifacts
 *.dylib
 
-# legacy agent docs (consolidated into CLAUDE.md)
-AGENTS.md
-src/outlookCalendar/AGENTS.md
+.gitnexus

AGENTS.md

@@ -0,0 +1,125 @@
+# Agent Instructions
+
+These instructions apply to the repository root. More specific `AGENTS.md`
+files in subdirectories override or extend this file.
+
+`CLAUDE.md` is the historical project guide. When it changes, review it and
+carry forward only durable repo guidance here; do not blindly copy
+Claude-specific, stale, or unavailable-tool instructions.
+
+## Project Basics
+
+- TypeScript codebase. Use TypeScript for new code unless explicitly told
+  otherwise.
+- Run root commands from the repository root. Do not run `yarn build` inside
+  workspace directories; it creates incorrect output structures.
+- Common commands:
+
+```sh
+yarn install && yarn start
+yarn build
+yarn lint && yarn test
+yarn workspaces:build
+```
+
+- After building `desktop-release-action`, remove
+  `workspaces/desktop-release-action/dist/dist`; the action only needs
+  `workspaces/desktop-release-action/dist/index.js`.
+
+## Patches And Builds
+
+- Do not confuse the two patch systems:
+  - Yarn patch protocol: `.yarn/patches/`, currently for `@ewsjs/xhr`.
+  - `patch-package`: `patches/`, currently for `@kayahr/jest-electron-runner`.
+- Never add `@ewsjs/xhr` patches to `patches/`; that creates CI conflicts.
+- Windows builds must include all architectures: `x64`, `ia32`, and `arm64`.
+- Code signing uses Google Cloud KMS in two phases: build packages without
+  signing, then sign built packages with `jsign`.
+
+## UI Work
+
+- Use Fuselage components from `@rocket.chat/fuselage` for UI work unless the
+  design requires something Fuselage does not provide.
+- Check `Theme.d.ts` for valid color tokens before using Fuselage colors.
+- Verify library props, APIs, and tokens against official docs or local
+  `.d.ts` files instead of assuming.
+
+## Testing
+
+- Renderer specs use `*.spec.ts` / `*.spec.tsx`.
+- Main-process specs use `*.main.spec.ts`.
+- Renderer specs must live in a Jest-matched nested path, for example
+  `src/<module>/<subdir>/*.spec.ts(x)` or
+  `src/<module>/renderer.spec.ts(x)`. Flat `src/<module>/*.spec.ts` files are
+  not discovered by the current `testMatch`.
+- Verify new specs with `yarn test --listTests --runTestsByPath <file>` when
+  discovery is uncertain.
+- Tests run on Windows, macOS, and Linux CI. Keep platform behavior defensive.
+- Prefer optional chaining and fallbacks for platform-specific APIs. Only mock
+  Linux-only APIs like `process.getuid()` when defensive coding is not enough.
+
+## QA Flow Authoring
+
+When creating or updating QA assets under `qa/`, read these first:
+
+- `skills/desktop-qa-flows/SKILL.md` when the task is for a Desktop PR, branch,
+  or release-candidate QA pass. This file is plain Markdown and can be used by
+  any agent, including Codex, Claude, Hermes, Cursor, and GitHub agents, when
+  explicitly pointed to it.
+- `qa/README.md`
+- `qa/AGENTS.md`
+- `qa/flow-template.md`
+
+QA flows must be executable by a QA engineer or visual agent that knows nothing
+about the feature. Do not guess where UI lives. Derive every user-facing step
+from the implementation: changed React components, Fuselage icons, i18n labels,
+menu definitions, modal buttons, platform branches, tests, and helper pages.
+
+For branch-specific QA packs, lock the comparison range before deriving flows:
+record the base branch, head branch or commit, and whether the whole range was
+reviewed. Classify changed Desktop surfaces by user-visible risk, then turn each
+risk into a falsifiable hypothesis the flow proves or disproves. Prefer the
+smallest useful proof: existing tests, targeted tests, local UI repro, OS-level
+repro, or code-path proof when runtime validation is not practical.
+
+Write the visible path directly in the flow step `Action` cell. Include screen
+region, relative position, icon shape, nearby UI, visible labels after
+interaction, and the visual confirmation state. If a label only appears as a
+tooltip or after clicking a menu, describe the visible anchor first.
+
+Do not create separate navigation sections or helper navigation files for basic
+UI discovery. Validate QA packs with:
+
+```sh
+node qa/scripts/validate-flows.mjs qa/<pack>
+node qa/scripts/export-qase-csv.mjs qa/<pack>
+```
+
+## Code Style
+
+- Use React functional components with hooks.
+- Redux actions follow FSA shape.
+- File naming: camelCase for files, PascalCase for components.
+- Prefer clear names over unnecessary comments.
+- Prefer editing existing files over creating new abstractions unless the new
+  abstraction removes real complexity or matches an existing pattern.
+
+## Git And Verification
+
+- Never commit or push without explicit user permission.
+- Never commit directly to `master` or `dev`.
+- Read-only git operations are fine.
+- Show what will be committed before committing.
+- Verify work with the narrowest meaningful checks first, then broader checks
+  when risk or shared behavior justifies it.
+- If GitNexus tooling is available, use the GitNexus section in `CLAUDE.md` for
+  impact analysis and affected-scope checks. If it is unavailable, do not block
+  progress solely on that tool; compensate with local code search, tests, and
+  careful review.
+
+## Writing
+
+- Avoid subjective descriptors like "smart" or "excellent".
+- Do not invent metrics, user counts, or time estimates.
+- PR descriptions should use straightforward language focused on what changed
+  and why.

CLAUDE.md

@@ -50,9 +50,46 @@ This prevents MSI build failures from KMS CNG provider conflicts.
 
 - `*.spec.ts` — Renderer process tests
 - `*.main.spec.ts` — Main process tests
+- Renderer specs must live in a Jest-matched nested path, e.g. `src/<module>/<subdir>/*.spec.ts(x)` or `src/<module>/renderer.spec.ts(x)`. Flat `src/<module>/*.spec.ts` files are not discovered by current `testMatch`; verify new specs with `yarn test --listTests --runTestsByPath <file>`.
 - Uses `@kayahr/jest-electron-runner` for Electron environment simulation
 - Tests run on Windows, macOS, AND Linux CI — always verify cross-platform
 
+## QA Flow Authoring
+
+When creating or updating QA flows under `qa/`, read `qa/README.md`,
+`qa/AGENTS.md`, and `qa/flow-template.md` first. QA steps must be
+self-contained and visually findable for a tester or visual agent that knows
+nothing about the feature.
+
+- For Desktop PR, branch, or release-candidate QA passes, use
+  `skills/desktop-qa-flows/SKILL.md` as the workflow entrypoint. The skill
+  decides whether to update existing flows, add new flows, or create a new
+  `qa/<feature-slug>/` pack based on changed user-visible risk. It is plain
+  Markdown and can be used by any agent, including Codex, Claude, Hermes, Cursor,
+  and GitHub agents, when explicitly pointed to it.
+- Derive tester-facing steps from the implementation, not product intuition.
+  Inspect changed React components, Fuselage icons, i18n labels, menu
+  definitions, modal buttons, platform branches, tests, and helper pages.
+- For branch-specific QA packs, lock the exact comparison range first: base
+  branch, head branch or commit, and whether the whole requested range was
+  reviewed. Do not claim complete QA coverage for a partial review.
+- Convert risky Desktop changes into falsifiable user-visible hypotheses before
+  writing flows. Use Desktop risk surfaces such as Electron main process,
+  protocol handlers, OS default handlers, settings UI, menus, modals,
+  packaging/installers, startup, shortcuts, workspace routing, i18n, and layout.
+- Put the visible path directly in the `Action` cell. Do not create separate
+  navigation sections or ask testers to open another file for basic UI
+  discovery.
+- Describe screen region, relative position, icon shape, nearby UI, visible
+  text after interaction, and the confirmation state. If a tooltip or menu title
+  appears only after hover/click, describe the visible anchor first.
+- Prefer the smallest useful proof for the hypothesis: existing tests, targeted
+  tests, local UI repro, OS-level repro, or code-path proof when runtime
+  validation is not practical.
+- For Qase compatibility, keep the flow table columns aligned with
+  `qa/flow-template.md` and run `node qa/scripts/validate-flows.mjs qa/<pack>`
+  plus `node qa/scripts/export-qase-csv.mjs qa/<pack>` after changes.
+
 ### Cross-Platform Compatibility
 
 Use optional chaining with fallbacks for platform-specific APIs:
@@ -103,3 +140,47 @@ git worktree add ../Rocket.Chat.Electron-worktrees/feature-name -b new-branch ma
 - Use measurable descriptions: "reduced memory usage", "improved by X%"
 - **Never invent metrics** — no estimated time spent, no speculated user counts. Only include numbers from actual logs, error messages, or documented sources.
 - PR descriptions: straightforward language, focus on what changed and why
+
+<!-- gitnexus:start -->
+# GitNexus — Code Intelligence
+
+This project is indexed by GitNexus as **Rocket.Chat.Electron** (4593 symbols, 7029 relationships, 103 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely.
+
+> If any GitNexus tool warns the index is stale, run `npx gitnexus analyze` in terminal first.
+
+## Always Do
+
+- **MUST run impact analysis before editing any symbol.** Before modifying a function, class, or method, run `gitnexus_impact({target: "symbolName", direction: "upstream"})` and report the blast radius (direct callers, affected processes, risk level) to the user.
+- **MUST run `gitnexus_detect_changes()` before committing** to verify your changes only affect expected symbols and execution flows.
+- **MUST warn the user** if impact analysis returns HIGH or CRITICAL risk before proceeding with edits.
+- When exploring unfamiliar code, use `gitnexus_query({query: "concept"})` to find execution flows instead of grepping. It returns process-grouped results ranked by relevance.
+- When you need full context on a specific symbol — callers, callees, which execution flows it participates in — use `gitnexus_context({name: "symbolName"})`.
+
+## Never Do
+
+- NEVER edit a function, class, or method without first running `gitnexus_impact` on it.
+- NEVER ignore HIGH or CRITICAL risk warnings from impact analysis.
+- NEVER rename symbols with find-and-replace — use `gitnexus_rename` which understands the call graph.
+- NEVER commit changes without running `gitnexus_detect_changes()` to check affected scope.
+
+## Resources
+
+| Resource | Use for |
+|----------|---------|
+| `gitnexus://repo/Rocket.Chat.Electron/context` | Codebase overview, check index freshness |
+| `gitnexus://repo/Rocket.Chat.Electron/clusters` | All functional areas |
+| `gitnexus://repo/Rocket.Chat.Electron/processes` | All execution flows |
+| `gitnexus://repo/Rocket.Chat.Electron/process/{name}` | Step-by-step execution trace |
+
+## CLI
+
+| Task | Read this skill file |
+|------|---------------------|
+| Understand architecture / "How does X work?" | `.claude/skills/gitnexus/gitnexus-exploring/SKILL.md` |
+| Blast radius / "What breaks if I change X?" | `.claude/skills/gitnexus/gitnexus-impact-analysis/SKILL.md` |
+| Trace bugs / "Why is X failing?" | `.claude/skills/gitnexus/gitnexus-debugging/SKILL.md` |
+| Rename / extract / split / refactor | `.claude/skills/gitnexus/gitnexus-refactoring/SKILL.md` |
+| Tools, resources, schema reference | `.claude/skills/gitnexus/gitnexus-guide/SKILL.md` |
+| Index, status, clean, wiki CLI commands | `.claude/skills/gitnexus/gitnexus-cli/SKILL.md` |
+
+<!-- gitnexus:end -->

build/RocketChatDefaultAppAssociations.xml

@@ -0,0 +1,22 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+  Default app associations for Rocket.Chat Desktop on Windows 10/11.
+
+  Apply via one of:
+    - Group Policy: Computer Configuration -> Administrative Templates ->
+      Windows Components -> File Explorer -> "Set a default associations
+      configuration file", pointing at this file.
+    - Intune: ApplicationDefaults CSP with the Base64-encoded contents of
+      this file.
+    - DISM (image deployment): dism /Online /Import-DefaultAppAssociations:
+      <path-to-this-file>
+    - MSI public property: install with SET_DEFAULT_ASSOCIATIONS=1 to have
+      the installer wire the policy registry value at this path.
+
+  ProgIds below MUST stay in sync with build/installer.nsh
+  (registerTelephonyCapabilities) and the MSI Capabilities registration.
+-->
+<DefaultAssociations>
+  <Association Identifier="tel"    ProgId="RocketChat.tel"    ApplicationName="Rocket.Chat" />
+  <Association Identifier="callto" ProgId="RocketChat.callto" ApplicationName="Rocket.Chat" />
+</DefaultAssociations>

build/installer.nsh

@@ -29,12 +29,67 @@
   ${EndIf}
   !insertMacro disableAutoUpdates
   Delete "$SMSTARTUP\Rocket.Chat+.lnk"
+  !insertMacro registerTelephonyCapabilities
 !macroend
 
 !macro customUnInstall
   ${IfNot} ${Silent}
     Delete "$SMSTARTUP\Rocket.Chat.lnk"
   ${EndIf}
+  !insertMacro unregisterTelephonyCapabilities
+!macroend
+
+; Register Rocket.Chat in RegisteredApplications + Capabilities\URLAssociations so
+; the Windows 11 Default Apps picker exposes it as a candidate for tel/callto/sip
+; and the `ms-settings:defaultapps?registeredApp{User|Machine}=Rocket.Chat` deep
+; link lands on the app-specific page.
+!macro registerTelephonyCapabilities
+  ${If} $installMode == "all"
+    !insertMacro writeTelephonyCapabilities HKLM
+  ${Else}
+    !insertMacro writeTelephonyCapabilities HKCU
+  ${EndIf}
+!macroend
+
+!macro writeTelephonyCapabilities ROOT
+  ; Per-scheme ProgIDs that the picker references through URLAssociations.
+  WriteRegStr ${ROOT} "Software\Classes\RocketChat.tel" "" "URL:Rocket.Chat Telephony"
+  WriteRegStr ${ROOT} "Software\Classes\RocketChat.tel" "URL Protocol" ""
+  WriteRegStr ${ROOT} "Software\Classes\RocketChat.tel\DefaultIcon" "" "$INSTDIR\Rocket.Chat.exe,0"
+  WriteRegStr ${ROOT} "Software\Classes\RocketChat.tel\shell\open\command" "" '"$INSTDIR\Rocket.Chat.exe" "%1"'
+
+  WriteRegStr ${ROOT} "Software\Classes\RocketChat.callto" "" "URL:Rocket.Chat Telephony"
+  WriteRegStr ${ROOT} "Software\Classes\RocketChat.callto" "URL Protocol" ""
+  WriteRegStr ${ROOT} "Software\Classes\RocketChat.callto\DefaultIcon" "" "$INSTDIR\Rocket.Chat.exe,0"
+  WriteRegStr ${ROOT} "Software\Classes\RocketChat.callto\shell\open\command" "" '"$INSTDIR\Rocket.Chat.exe" "%1"'
+
+  ; Capabilities surface consumed by Windows 11 Default Apps.
+  WriteRegStr ${ROOT} "Software\Rocket.Chat\Capabilities" "ApplicationName" "Rocket.Chat"
+  WriteRegStr ${ROOT} "Software\Rocket.Chat\Capabilities" "ApplicationDescription" "Rocket.Chat Desktop"
+  WriteRegStr ${ROOT} "Software\Rocket.Chat\Capabilities" "ApplicationIcon" "$INSTDIR\Rocket.Chat.exe,0"
+  WriteRegStr ${ROOT} "Software\Rocket.Chat\Capabilities\URLAssociations" "tel" "RocketChat.tel"
+  WriteRegStr ${ROOT} "Software\Rocket.Chat\Capabilities\URLAssociations" "callto" "RocketChat.callto"
+
+  ; Entry point picked up by Default Apps and the ms-settings deep link.
+  WriteRegStr ${ROOT} "Software\RegisteredApplications" "Rocket.Chat" "Software\Rocket.Chat\Capabilities"
+!macroend
+
+!macro unregisterTelephonyCapabilities
+  ${If} $installMode == "all"
+    !insertMacro deleteTelephonyCapabilities HKLM
+  ${Else}
+    !insertMacro deleteTelephonyCapabilities HKCU
+  ${EndIf}
+!macroend
+
+!macro deleteTelephonyCapabilities ROOT
+  DeleteRegValue ${ROOT} "Software\RegisteredApplications" "Rocket.Chat"
+  DeleteRegKey ${ROOT} "Software\Rocket.Chat\Capabilities"
+  DeleteRegKey /ifempty ${ROOT} "Software\Rocket.Chat"
+  DeleteRegKey ${ROOT} "Software\Classes\RocketChat.tel"
+  DeleteRegKey ${ROOT} "Software\Classes\RocketChat.callto"
+  ; Prior versions may have created RocketChat.sip; clean it up just in case.
+  DeleteRegKey ${ROOT} "Software\Classes\RocketChat.sip"
 !macroend
 
 !macro disableAutoUpdates