Docs: make AGENTS.md the release source of truth, and fix the chatbot's route docs

AGENTS.md

@@ -495,6 +495,36 @@ Docker/`gh` invocations beyond the one-time registry login in step 3.
    make docker-multiarch-dry           # sanity-check the plan first
    make docker-multiarch-push          # builds amd64+arm64, pushes :X.Y.Z and :latest
    ```
+   Bare `make docker-multiarch-push` auto-detects the version from the Git tag
+   and leaves the `latest` decision to auto-detection. To be fully explicit and
+   non-interactive - e.g. in a script, or when `HEAD` isn't the tagged commit -
+   pass the flags through `ARGS` (the Makefile forwards `$(ARGS)` to
+   `scripts/lrops.py build --docker --multiarch --push`):
+   ```
+   make docker-multiarch-push ARGS="--latest --version v1.0.4"
+   ```
+   `--no-latest` is the counterpart when publishing an older/backport tag that
+   must not move the `:latest` pointer.
+
+   There is also an **interactive** variant - `make docker-interactive-multiarch`
+   / `make docker-interactive-multiarch-push` (single-arch:
+   `make docker-interactive` / `-push` / `-dry`). It prompts for three things:
+   which existing tag to build, whether to also tag it `latest`, and whether to
+   go multi-arch. Both paths end in the same `build_docker_image()` call with
+   the same arguments, so the build and push themselves are identical - the
+   only difference is where those values come from.
+
+   Two behavioral gotchas worth knowing:
+   - Interactive runs `lrops.py docker` (flag: `--tag`), non-interactive runs
+     `lrops.py build --docker` (flag: `--version`).
+   - `lrops.py docker` **validates that the tag already exists** in the repo and
+     refuses otherwise; `build --docker` does not, so a typo'd `--version` will
+     happily build and push a tag that matches no commit.
+
+   **Rule for agents: do not pick between these two on your own.** Before
+   running any multi-arch build/push, ask the user which they want -
+   interactive or non-interactive with explicit `ARGS` - and run their choice.
+
    This uses the `gitlab-multiarch` buildx builder (a local `docker-container`
    driver builder - `scripts/lrops.py` creates it automatically on first use
    if missing; despite the name it has nothing to do with GitLab or a remote
@@ -510,6 +540,12 @@ Docker/`gh` invocations beyond the one-time registry login in step 3.
    `docs/releases/v1.0.4.md` as the notes body (`scripts/release_gh.py`).
    SBOM generation/attachment runs separately, from CI, off the pushed tag.
 
+**Gotcha - multi-arch builds are disk-hungry.** Building amd64+arm64 in one
+run materializes two full image trees plus the buildx cache. If the build dies
+with a confusing write/extract error, check free space on the build machine
+first (`df -h`, `docker system df`) and reclaim with `docker buildx prune` /
+`docker system prune` before assuming the Dockerfile is at fault.
+
 **Gotcha - the Docker build context is the raw repo directory (`.`), not a
 git archive.** `docker buildx build .` needs to traverse every directory
 under the repo root, even ones excluded by `.dockerignore` (that filtering

internal/docindex/docs/routes_guide/README.md

@@ -13,12 +13,31 @@ not implementation detail.
   (`reviews/`, `explore/`, `git/`, `ai/`, `settings/`, `licenses/`,
   `reports/`, `chatbot/`, `auth/`). Top-level pages that don't belong to a
   group (dashboard, home) live directly in `ui/docs/training_data/lr_routes/`.
+- A small number of top-level files are **reference pages, not routes**
+  (e.g. `contact.md`), for cross-cutting questions the chatbot must answer
+  that no single page owns. Keep these rare and clearly marked as non-routes
+  at the top of the file.
 - Each file follows this shape:
   - **Route(s)** — path(s) and the component that renders them
   - **Purpose** — what the page is for, in plain language
   - **Who can access it** — role/permission gating, if any
   - **Key actions** — what a user can do on this page
   - **Related pages** — where this page links to / is linked from
+  - **Learn more (public docs)** — optional; links to the matching page(s)
+    on the public docs site, when one exists
+
+## Linking to the public docs
+
+Where a page is also covered by the public documentation site, end the file
+with a **Learn more (public docs)** section linking to it. Base URL is
+`https://hexmos.com/livereview/docs/<path>`, where `<path>` mirrors the file
+layout under `../hexmos_docs/` (e.g. `livereview/integrations/slack.mdx` →
+`https://hexmos.com/livereview/docs/livereview/integrations/slack`, and an
+`index.mdx` drops the `/index`).
+
+Only link to pages that actually exist in `../hexmos_docs/` — that folder is
+synced from the live docs site, so it is the authority on what is publishable.
+Never guess a URL: a 404 in the chatbot's answer is worse than no link.
 
 ## Keeping this in sync
 

internal/docindex/docs/routes_guide/ai/ai-providers.md

@@ -31,3 +31,7 @@ typically an owner/admin action (enforced server-side).
 
 - [New Review](../reviews/new-review.md)
 - [Settings](../settings/settings-overview.md)
+
+## Learn more (public docs)
+
+- [Integrations — AI connector management (BYOK): Gemini, OpenAI, Claude, DeepSeek, OpenRouter](https://hexmos.com/livereview/docs/git-lrc/configure/integrations)

internal/docindex/docs/routes_guide/contact.md

@@ -0,0 +1,40 @@
+# Contacting the LiveReview / Hexmos Team
+
+> Not a UI route - this is a reference page so questions like "how do I
+> contact support?", "how do I reach the Hexmos team?", "who do I talk to
+> about my license?" can be answered directly.
+
+## Reach us any time
+
+Every channel reaches the same engineers who set your instance up.
+
+- **Email:** info@hexmos.com
+- **Founder:** shrijith@hexmos.com - Shrijith, founder of Hexmos. Fine to
+  reach out to directly for licensing, pricing, or anything needing a
+  decision.
+- **Discord:** join the LiveReview community at
+  <https://discord.gg/sGdnKwB3qq>
+- **Slack:** invite us into a shared channel in your workspace, so answers
+  arrive where your team already works.
+- **Microsoft Teams:** supported the same way as Slack - invite us into a
+  shared channel.
+
+## When to use which
+
+- **General questions, sales enquiries, anything else** - email
+  info@hexmos.com.
+- **Self-hosted license keys** (getting one, renewing, activating) - there is
+  no self-serve purchase flow; contact info@hexmos.com or shrijith@hexmos.com.
+  See [Settings -> License](settings/license.md).
+- **Quick back-and-forth or community help** - Discord.
+- **Ongoing support alongside your team's own workflow** - a shared Slack or
+  Teams channel.
+
+## Related pages
+
+[Settings -> License](settings/license.md),
+[Settings -> Integrations](settings/integrations.md)
+
+## Learn more (public docs)
+
+- [LiveReview documentation home](https://hexmos.com/livereview/docs)