Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.cursor/rules/calls-expert-persona-bill.mdc:
- Around line 7-15: The persona definition for "Expert Persona: Bill" has
inconsistent role titles ("Principal Engineer" and "Staff Engineer"); pick a
single title (e.g., "Staff Engineer" or "Principal Engineer") and make both
occurrences consistent by updating the header line and the role/description line
inside the persona block (search for the "Expert Persona: Bill" block and the
paragraph that begins with "**Name:** Bill" / "**Role:**" and change the role
text so both places match exactly); ensure any other mentions in that persona
block also use the chosen title.

In `@source/administration-guide/configure/calls-deployment-guide.md`:
- Line 72: The headings under "Deployment Prerequisites" skip levels (e.g.,
"Deployment Infrastructure Requirements" and other subheadings currently using
"####") — change those H4 headings to H3 (replace "####" with "###") so the
hierarchy is sequential under the "Deployment Prerequisites" H2; update each
instance noted (the headings at or near the titles "Deployment Infrastructure
Requirements" and the other subheadings referenced) to use H3 to restore
consistent heading levels.
- Around line 23-24: The sentence "no call media or metadata traverses
third-party systems." is too absolute; replace it with scoped wording like "no
call media path traverses third‑party systems" and add a brief qualifier noting
this depends on self‑hosted network configuration and signaling choices (e.g.,
TURN/STUN, federation, or external relays) so readers understand it’s contingent
on their deployment and network choices.
- Around line 660-669: Change the guidance so environment variables
MM_CALLS_RTCD_CLIENT_ID and MM_CALLS_RTCD_AUTH_KEY are the primary, recommended
way to supply RTCD credentials; remove or re-label the
“http://clientID:[email protected]:8045” pattern as temporary/test-only and
explicitly warn that embedding credentials in URLs risks exposure (logs,
history, screenshots) and should only be used for short-lived testing, include a
note to apply least-privilege for the credential, rotate keys, and avoid storing
or logging the authKey.
- Line 88: Broken in-page anchors: update the quoted links that point to
"#infrastructure-decisions" and "#networking-decisions" so they match the actual
heading-generated anchors (the headings are numbered like "### 1.2 ...", "###
1.3 ..."); either change the hrefs to the correct slugified fragments (e.g., the
numeric-prefixed slugs generated from "1.2 Infrastructure Decisions" and "1.3
Networking Decisions") or add explicit HTML anchors (e.g., <a
id="infrastructure-decisions"></a>) immediately before the "1.2" and "1.3"
headings; apply the same fix for the other occurrences noted (the helper links
around the existing fragments at the other locations).

In `@source/administration-guide/configure/calls-logging.md`:
- Around line 30-32: The current documentation callout uses a benign note and
instructs users to "provide the complete set of logs", which can leak secrets;
change the callout token from {note} to {warning} and update the message in the
RTCD/client logs block to instruct users to only share logs via approved support
channels and to sanitize/remove secrets, tokens, internal hostnames, IPs and
user-identifying data before sharing — locate and edit the fenced block that
begins with ```{note} (the RTCD/client logs paragraph) to use ```{warning} and
append the short secure-sharing/sanitization guidance.

In `@source/administration-guide/configure/plugins-configuration-settings.rst`:
- Line 485: Fix the grammar in the participant-limit note by changing "Call
participant limits greatly depends on instance resources." to "Call participant
limits greatly depend on instance resources." so the plural subject "limits"
agrees with the verb "depend"; update the sentence in the same paragraph near
the participant limit recommendation (the line containing "This setting is
optional, but the recommended maximum number of participants is **50**. Call
participant limits greatly depends on instance resources.") to use "depend".
- Line 513: The |rtcd_service| replacement currently points to the general calls
deployment guide; update the replacement so the shortcut links to the dedicated
RTCD guide instead (replace ":doc:`RTCD service
</administration-guide/configure/calls-deployment-guide>`" with a doc reference
that targets the standalone RTCD guide page), editing the |rtcd_service|
replacement line in the file so all notes about the standalone rtcd service
point to the precise RTCD guide.

In
`@source/deployment-guide/reference-architecture/deployment-scenarios/deploy-ddil-operations.rst`:
- Around line 104-107: The section claims Calls operate without
internet/third-party services but omits the offline ICE configuration
requirement; update the Mattermost Calls paragraph (references: "rtcd",
"calls-offloader", and the Calls deployment doc link) to explicitly state admins
must remove or replace the default public STUN/TURN servers, supply reachable
ICE candidates (host/local STUN/TURN or mDNS candidates) for the tactical
network, and specify network requirements (direction: outbound/inbound,
protocol: UDP/TCP/DTLS/SRTP, source/destination scopes, and whether each access
is mandatory or optional) so operators know how to configure ICE for fully
offline operation.

In
`@source/deployment-guide/reference-architecture/deployment-scenarios/deploy-mission-partner.rst`:
- Around line 162-165: Update the paragraph that promises “without reliance on
the internet” to explicitly state ICE/STUN/TURN network requirements: mention
that Mattermost Calls and the rtcd service require valid ICE candidates
(STUN/TURN) for peer connectivity, that the default public STUN server will
require outbound UDP/UDP-TCP egress to those STUN hosts (or TCP/TLS for TURN)
unless replaced, and clarify whether egress to specific STUN/TURN endpoints is
mandatory or optional in a mission network; reference the rtcd and
calls-offloader services and advise either deploying an internal STUN/TURN or
authorizing explicit outbound access to approved STUN/TURN servers, including
direction (outbound), protocol (UDP/TCP/TLS), and scope (hostnames/IPs) to
satisfy coding guidelines.

In `@source/product-overview/unsupported-legacy-releases.md`:
- Line 2349: Replace the hardcoded absolute URL in the Markdown link for "Audio
calling and screen sharing" with a relative repo link using Markdown link
syntax; locate the line containing the link text "Audio calling and screen
sharing" and change the URL from
"https://docs.mattermost.com/configure/calls-deployment-guide.html" to the
appropriate relative path (e.g., ./configure/calls-deployment-guide.md or the
correct relative location in the docs tree) so the link follows repository
conventions and is not brittle.

---

Outside diff comments:
In `@source/administration-guide/configure/plugins-configuration-settings.rst`:
- Around line 761-837: Update the three notes that currently point to the
general Calls deployment guide so they instead reference the dedicated
calls-offloader guide: find the note under the quality/recordings paragraph in
the enable-pluginscalltranscriptions section and replace ":doc:`Calls deployment
guide </administration-guide/configure/calls-deployment-guide>`" with the
calls-offloader doc; do the same in the transcriber-model-size note
(transcriber-model-size) and the call-transcriber-threads note
(call-transcriber-threads) so each refers to ":doc:`calls-offloader guide
</administration-guide/configure/calls-offloader>`" (or the correct offloader
doc path) and keep surrounding phrasing intact.

In `@source/product-overview/plans.md`:
- Around line 181-220: Replace the hardcoded docs URL and the Kubernetes-only
phrasing in the table row with a repo-relative internal link and an accurate
feature description: update the row titled "High availability, horizontally
scalable calls and screen share" to link to the internal calls-rtcd-setup page
(use the repo-relative link pattern used elsewhere) and change the copy to say
the feature is delivered by the dedicated rtcd service with Kubernetes as one
supported deployment option (e.g., "delivered by the dedicated rtcd service;
Kubernetes is a supported deployment option"), keeping the link target to
calls-rtcd-setup.html and preserving the v9.11+ version token.

---

Nitpick comments:
In @.cursor/rules/docs-reader-persona-security-sam.mdc:
- Around line 19-29: Add two items to the "What Security Sam Watches For" list:
include "**Insecure defaults**: callouts for examples that rely on insecure
defaults and guidance to harden them" and "**Update and patch guidance**: notes
about maintaining version currency and procedures for security
updates/patching"; place them alongside the existing bullets (e.g., near "Unsafe
production carryover" or "Compliance and privacy blind spots") so reviewers see
them as part of the standard checklist.
- Around line 40-48: The "How to Use This Persona When Reviewing Docs" section
lacks an illustrative example showing the three-part review format; add a brief
concrete example under that header demonstrating the workflow (quote exact text,
explain the risk, provide a safer replacement) so reviewers see expected output;
update the markdown near the three-part guidance (the line referencing "quote
the exact text, explain the security risk in plain language, and provide a safer
replacement") to include one short example entry showing a problematic sentence,
a one-line risk explanation, and a one-line safer replacement.
- Line 3: The glob in the rule (globs: **/*.md,**/*.rst) is too broad for a
security-focused persona; narrow it to the relevant documentation paths by
replacing that value with targeted patterns such as
source/deploy/**/*.md,source/deploy/**/*.rst and
source/configure/calls-deployment/**/*.md,source/configure/calls-deployment/**/*.rst
(or other repo-specific security-sensitive paths) so Security Sam only applies
to Calls deployment and related config docs; if the broad scope was intentional
keep globs but document the rationale and verify the alwaysApply: false setting
remains correct for opt-in behavior.

In `@source/administration-guide/configure/calls-deployment-guide.md`:
- Line 80: Replace the hardcoded external link
"https://docs.mattermost.com/deploy/server/setup-tls.html" in the "See
[Configure TLS]" markdown line with the repository's internal relative doc link
syntax used elsewhere (e.g., the repo's Configure TLS page path), updating the
link target in source/administration-guide/configure/calls-deployment-guide.md
and the other occurrences referenced (lines 325, 810, 932); ensure the link text
remains "Configure TLS" but points to the internal doc path so moves/redirects
stay maintainable.

In `@source/administration-guide/configure/calls-kubernetes.md`:
- Line 10: Add a brief inline definition of "rtcd" at its first occurrence in
the sentence that currently reads "Using the RTCD service is the only supported
deployment model."; e.g., replace or augment that sentence to read something
like "Using the RTCD (real-time communication daemon) service..." so readers
immediately know what rtcd stands for before later sections reference it, and
ensure the capitalization matches subsequent uses of "RTCD"/"rtcd".

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@source/administration-guide/configure/calls-deployment-guide.md`:
- Line 325: Replace the external docs.mattermost.com URL used in the RTCD
horizontal scaling link with the local internal link format: update the
"horizontal scaling" link in the sentence that reads "The RTCD service supports
[horizontal
scaling](https://docs.mattermost.com/administration-guide/configure/calls-rtcd-setup.html#horizontal-scaling)"
to point to the local page/anchor (calls-rtcd-setup.md#horizontal-scaling) so it
uses the repository's internal docs link style and avoids brittle external HTML
links.
- Line 80: Replace the hardcoded external docs URL in the link text "Configure
TLS" with the repository's internal link syntax used for Mattermost docs (i.e.,
convert the anchor _See [Configure
TLS](https://docs.mattermost.com/deploy/server/setup-tls.html)_ to the
repo-appropriate internal link form), updating the link target for the
"Configure TLS" reference in this file so builds and redirects remain stable.
- Line 807: Replace the hardcoded external URL used in the sentence "You can
learn more about Mattermost Calls in the
[documentation](https://docs.mattermost.com/end-user-guide/collaborate/make-calls.html)."
with the repo's internal markdown link to the corresponding docs page (use the
repo-appropriate relative/internal link syntax to the End User Guide page for
"make-calls"); do the same for the second occurrence referenced in the comment
(line noted as 929) so both template links point to the internal markdown target
instead of the absolute https://docs.mattermost.com/... URL.

---

Duplicate comments:
In `@source/administration-guide/configure/calls-deployment-guide.md`:
- Around line 657-666: Update the RTCD Service URL guidance to make environment
variables the primary, production-safe method (MM_CALLS_RTCD_CLIENT_ID and
MM_CALLS_RTCD_AUTH_KEY) and reframe the inline credential URL example
(http://clientID:[email protected]:8045) as a temporary, test-only approach
with a clear warning about secret leakage risk; remove or de-emphasize
recommending embedded credentials for production and add a short note to follow
least-privilege practices for network policy, service exposure, and credential
handling when using RTCD Service URL.
- Line 72: The "Deployment Infrastructure Requirements" heading and several
others are using level-4 headings (####) while the section is under "Deployment
Prerequisites" (level-2), breaking sequential hierarchy; update "#### Deployment
Infrastructure Requirements" to "### Deployment Infrastructure Requirements" and
similarly change the other mis-leveled headings referenced (the headings at the
comment locations 102, 109, 117, 122) from #### to ### so headings progress
logically under the Deployment Prerequisites section.
- Line 88: The inline links pointing to fragments '#infrastructure-decisions'
and '#networking-decisions' don't match the actual numbered headings
("Infrastructure Decisions (Step 1.2)" and "Networking Decisions (Step 1.3)");
locate the references to these fragments in the document (the lines mentioning
"See Infrastructure Decisions (Step 1.2)" etc.) and update each anchor to the
exact slug generated for those headings in this repo's Markdown renderer (e.g.,
include the numeric prefix used in the heading slug), or replace the fragment
links with full heading text links (e.g., link to "Infrastructure Decisions
(Step 1.2)" and "Networking Decisions (Step 1.3)") so the jump targets resolve
reliably; do the same for the other occurrences flagged (the other mentions of
the same fragments).
- Around line 23-24: The statement “no call media or metadata traverses
third-party systems.” is too absolute; update the sentence to conditionally
scope the sovereignty claim by clarifying it applies only when admins configure
Calls to use fully self-hosted media services (no external TURN/STUN/relay or
analytics integrations) and network architecture prevents third-party relays.
Replace the quoted sentence in the paragraph with a scoped version such as “When
configured for fully self-hosted media and without external relays or
third-party analytics, call media and metadata remain within your
infrastructure,” and add a short note referencing configuration choices that can
cause media/metadata to traverse external systems.