docs: release navigation and integration reorganization - #212

)
* docs: reorder header navigation tabs
* docs: reorganize TrustGuard coverage and Claude integrations
* docs: preserve retired integration routes and Claude anchors

The console product is "Agent Runtime", but 18 pages sent readers to a
"Runtime" entry that does not exist in the sidebar under that name.
The `transform` action had two names depending on the page: the console and
the policy pages call it Transform, while the coverage matrices and two
integration guides called it Redact. Readers jumping between them could not
tell it was the same action. Transform wins: it is both the console label and
the API value. Prose describing what it does still says "redaction".
Also settles the collector category label: "AI gateways", matching
integrations/overview and the other four "AI ..." categories.

The page was accurate but written for someone who already knew TrustGuard.
Six changes, each closing a gap found while auditing it against the service
code and the console strings:
- Open with what TrustGuard stops. Three scenarios before the first catalog
 table, so the reader learns why to care before what to configure.
- Add the verdict table mapping console label to API status, and say who can
 produce each. The page introduced rule actions as Monitor/Block/Transform
 and then used `report` twice without ever connecting the two, and it listed
 Ask beside Block and Transform as if a detector rule could produce it. Only
 a gate can, and only on input.
- Show one real request and its response, so `status`, `findings` and
 `transformed_payload` stop being abstract.
- Give gates a row in Building blocks, including the part that matters: a gate
 can settle a request without reaching any detector.
- Link the URL and document analyzers instead of naming them raw. They live
 in Content security, the same page the first row already linked.
- Add `config-test` to the Claude source.application values, and repeat the
 unguarded-collector warning at the step where that mistake happens.

... stored
Three things an integrator or a security reviewer asked for and could not find.
Base URL: no page on the critical path said which host to call. Ten pages use
`{TRUSTGUARD_URL}` and none defined it, four hardcoded a host instead, and the
REST guide ran a curl against an undefined placeholder. Now defined once, with
a warning against the in-cluster admin address that is not reachable from
gateways, SDKs, or edge workers.
Limits: the status-code table was missing `429` and `503`, both of which the
service returns. Adds them plus the limits that already exist and were
undocumented: the 10 MiB body cap, the plan burst and monthly quota with their
`Retry-After` and `X-RateLimit-*` headers, and the url_analyzer fetch timeout.
Latency figures are deliberately absent — there are none to publish yet, and
the note says so rather than implying there is no cost.
Data handling: a new page for the first question any security review asks of a
product that reads every prompt. States plainly that the request body is
persisted for findings evidence, which credential headers and body keys are
redacted before storage, that attachments are never stored, and that retention
is plan-based with a per-record expiry. Region and contractual windows point at
the NeuralTrust contact rather than inventing a number.
Also adds a Mermaid diagram of the evaluation pipeline. There was not a single
diagram anywhere in the TrustGuard section, for a product that is a pipeline.

...rd-overview-audit-fixes
docs(trustguard): fix the accuracy and onboarding gaps found auditing the overview

The guides used `{TRUSTGUARD_URL}` as their placeholder for the host a
collector calls. That is the exact name of the deployment environment variable
which, per resolveTrustGuardEvaluateEndpoint.ts, is the in-cluster admin
control-plane address and "must not appear in WAF/SDK instructions". An
operator reading both the docs and the deployment env would wire up the one
host that cannot serve the traffic.
Renames the placeholder to `{TRUSTGUARD_BASE_URL}` across 20 pages, and adds a
note on the Evaluate API spelling out the distinction: the customer-facing
origin comes from TRUSTGUARD_PUBLIC_URL on SaaS, or the guard data-plane
endpoint on hybrid. Real environment variables — TRUSTGUARD_API_BASE and the
gateway's TRUSTGUARD_* — are untouched; only the braced placeholder changed.
Also links the seventeen "the console shows the URL for your workspace" notes
to the section that now defines it, instead of leaving each one to be taken on
faith.

Data handling said retention was plan-based and told the reader to ask their
NeuralTrust contact, which is not an answer a security review can act on.
The window is an entitlement (`logRetentionDays`, stamped onto the data plane
as `retention_days`, which is the RetentionWindow TrustGuard reads to compute
each record's absolute expiry). For teams entitled to TrustGuard the template
value is 365 days, so the page now says so, while pointing at the team's
stamped value as authoritative — a shorter window can be provisioned.
Regions and the training question stay open in RUN-1302: no region list exists
in code, and whether evaluated content is used for training is a policy answer,
not one to infer from a hostname.

...rd-base-url-and-retention
docs(trustguard): fix the base URL placeholder collision, and give retention a number

The navigation reorganization deleted integrations/{cloudflare,aws-cloudfront,
fastly,akamai}.mdx, but the console catalog still offers all four under its WAF
group. Anyone clicking WAF → Cloudflare had no documentation at all.
Recovered from main and brought up to current conventions, which they predate:
the {TRUSTGUARD_BASE_URL} placeholder, "Agent Runtime" breadcrumbs, Transform
instead of Redact, and catalog paths using the console's real group and entry
names — the group is "WAF", not "Edge / WAF", and the entries are AWS
CloudFront, Fastly Compute and Akamai EdgeWorkers.
Re-registered in docs.json and relinked from the integrations index.

The docs listed collector types the catalog does not have, and named catalog
groups and entries that do not exist, so readers were sent to console paths
they could never find.
Every catalog breadcrumb now uses the console's own names, verified against
COLLECTOR_PROVIDER_GROUPS:
- the group is "AI assistants & coding agents", not "IDE & coding agents"
- Claude Enterprise is listed as "Inference Hooks", its actual entry name
- Application holds "Python", not "Python SDK"
- GitHub Copilot has no entry at all, so the page no longer sends anyone to one
The overview table and the Collectors concept page now mirror the catalog:
four groups, nineteen types, console naming, one doc page each.
Integrations that are not collector types say so and name the collector you
actually create — LangChain and n8n use an Application collector (Python and
REST API respectively), Copilot Studio goes through TrustGate MCP, and GitHub
Copilot needs a collector NeuralTrust enables for the workspace.

...r-catalog-drift
docs(trustguard): make the collector list match the console catalog 1:1

Correction. The previous PR claimed there was no GitHub Copilot entry in the
catalog and told readers to ask NeuralTrust to enable one. That is wrong: the
entry exists and ships in the console today.
The mistake was auditing the app repo against origin/develop while the deployed
console runs main, and `fix(collectors): add GitHub Copilot to the collectors
catalog (#3496)` landed on main without a back-merge to develop. It is the only
difference between the two in that file.
The catalog therefore holds twenty collector types, not nineteen, with five in
the AI assistants & coding agents group. Restores the real console path on the
Copilot page, adds it to the overview table and the group count, and drops it
from the list of integrations that are not collector types.
Also aligns the Inference Hooks description with the console card, which says
Claude chat and Cowork — Claude Code has its own catalog entry.

...collector-exists
docs(trustguard): GitHub Copilot is a real collector type

WAF support is being dropped, so the four edge collectors go with it:
Cloudflare, AWS CloudFront, Fastly Compute and Akamai EdgeWorkers.
Deletes the four guides, the WAF navigation group, the WAF row from the
catalog table and from the Collectors group table, and the Edge and WAF
section of the integrations index. The catalog is now sixteen collector
types in three groups.
The redirects from those paths to the integrations index already exist from
the earlier navigation reorganization and are kept, so old links still land
somewhere useful.
Cloudflare references in the SSO, generic-OIDC and deployment-troubleshooting
pages are untouched: those are DNS-provider examples and the Turnstile
endpoint, unrelated to collectors.

...af-collectors
docs(trustguard): remove the WAF collectors

... groups
Three merges to the app catalog made statements on these pages false:
- n8n and LangChain are collector types now, under a new Agent frameworks
 group, so the paragraph telling readers to create an Application collector
 instead no longer applies
- Copilot Studio is a collector type under Agent platforms, so saying it
 reaches NeuralTrust only through TrustGate MCP is wrong
- GitHub Copilot was restored on develop, so the group holds five again
Verified 1:1 against COLLECTOR_PROVIDER_GROUPS on app develop: nineteen types,
five groups, console naming, no entry on either side without a counterpart.
Replaces the "not a collector type" note with the caveat that actually matters
now: Portkey and LiteLLM have collector types, but TrustGuard is not yet a
named guardrail inside either product, so both still need a piece the customer
builds — a BYOG webhook adapter for Portkey, a custom guardrail class beside
config.yaml for LiteLLM. Both work today; both are more setup than the rest.
The n8n page keeps its 0.2.0 references. They are the version floor for ask
handling, not a claim about the current release, so bumping them to the npm
latest would have misstated when that landed.

...ch-catalog-19
docs(trustguard): match the catalog again, now nineteen types in five groups

The SEO titles double as sidebar labels, so the navigation reads
"TrustGuard: AI Guardrails for LLM and Agent Traffic" where it should read
"Overview". TrustGate and TrustTest have the same shape.
Adds sidebarTitle, which splits the two: the sidebar gets the short label
while title stays the SEO string for the H1 and the page metadata. Verified on
the local preview — the nav link renders "Overview" and the H1 still renders
the full title.
The breadcrumb keeps the long title, since Mintlify builds it from title
rather than sidebarTitle. It truncates, so it clips rather than wrapping.

docs: show "Overview" in the sidebar for the three product landing pages

#222 shortened the sidebar with sidebarTitle but left title as the SEO string,
so the sidebar said "Overview" while the H1 and the breadcrumb still said
"TrustGuard: AI Guardrails for LLM and Agent Traffic". Making them match means
title itself has to be the short one.
Moves the SEO string to per-page og:title and twitter:title, which override
the workspace defaults in docs.json, so search and social previews keep it.
description already carried the keywords and is unchanged.
Verified on the local preview for all three pages: og:title and twitter:title
render the product string, while the H1, the sidebar and the breadcrumb all
render "Overview".
The one real cost is that the H1 no longer carries the keywords. Keeping both
was not possible — in Mintlify a single title field drives the H1, the sidebar
and the breadcrumb.

...les-match
docs: title the three product landing pages "Overview" everywhere