---
title: Getting help
description: What to gather before asking, where the answer probably already is, and how to report a security issue.
label: Getting help
---

## Try these first, in this order

**1. `veefore doctor`.** It audits the whole posture — authentication, MFA, TLS,
local file permissions, identity and passport validity, gateway health,
dangerous tools, network restrictions, policy coverage, audit chain integrity,
credential age, SDK version drift. A surprising share of problems are already in
its output.

```bash
veefore doctor --strict --verbose
```

**2. The action record.** If a specific decision is wrong, the record says why:
which policy, which version, which rule, which conditions, which risk signals.

```bash
veefore logs --limit 50
veefore audit show evt_01ABC
```

**3. [Troubleshooting](/operate/troubleshooting).** The failures people actually
hit, with their causes.

**4. [FAQ](/faq).** The recurring questions, including several that look like
bugs and are not.

## What to gather before asking

Having these makes the difference between one exchange and five.

:::params

:::param request_id | string | required
From the `x-request-id` header or the `error.request_id` field. This is the
fastest possible way to find the action, its full lineage, the audit event and
every log line the request produced.
:::

:::param Error code | string | required
The `error.code` value, not the message. Messages are written for humans and are
refined over time; codes are a contract. [All of them](/reference/errors).
:::

:::param Enforcement mode | OBSERVE / SIMULATE / ENFORCE | required
`veefore status`. A surprising number of "Veefore is not blocking this"
reports are an environment in `OBSERVE`.
:::

:::param Decision and shadow decision | string | optional
If the decision looks wrong, both `decision` and `shadow.decision`. In `OBSERVE`
they can legitimately disagree.
:::

:::param Doctor output | text | optional
`veefore doctor --strict`. Redact anything you consider sensitive; it does
not print secrets, but it does print hostnames.
:::

:::param Versions | string | optional
`veefore --version`, your SDK version, and `GET /v1/meta/info` for the
server. Version drift between SDK and server is a real cause of confusing
behaviour, and `doctor` checks for it.
:::

:::

:::danger Never include a private key, a credential, or a session token
Not in an issue, not in a chat message, not in a redacted screenshot. If you
have already sent one anywhere, treat it as compromised and rotate:

```bash
veefore agents rotate-key agt_01ABC
curl -X POST .../v1/credentials/cred_01ABC/rotate …
```
:::

## Reporting a security issue

Do not open a public issue. Follow
[responsible disclosure](/secure/disclosure), which covers what is in scope,
what to include, and the response commitment.

## Reading the system directly

Three endpoints need no authentication and answer a lot of questions about a
deployment you are talking to but did not configure:

```bash
# Version, environment, both public URLs, capability and exclusion lists
curl -s https://veefore.example.com/v1/meta/info

# Every error code with its status and message
curl -s https://veefore.example.com/v1/meta/error-codes

# Every audit event type, and which are webhook-subscribable
curl -s https://veefore.example.com/v1/meta/event-types
```

And one on the gateway, which is the answer to most onboarding failures:

```bash
# The platform verification key and the exact audience string to use
curl -s https://gateway.veefore.example.com/.well-known/veefore-platform-key
```

## These docs as a source for an agent

Every page is available as plain Markdown at `/_llms/<slug>.md`, and the whole
site is indexed at [llms.txt](/llms.txt) with a description per page.

If you are pointing a coding agent at Veefore, point it at `llms.txt` rather
than at the rendered HTML. It gets the structure and the prose without the
layout.

## Contributing a documentation fix

The docs live in `docs/content/` in the repository as plain Markdown, and the
navigation is `docs/docs.json`.

```bash
npm run docs:dev      # http://localhost:4800, rebuilds on save
npm run docs:check    # the same validation CI runs
```

`docs:check` fails on a broken internal link, an anchor pointing at a heading
that does not exist, a page missing from the navigation, a page in the
navigation with no file, an API group added to the catalogue without an
explanation, or an error code with no documented status group. If it passes, the
links work.

Pages under [Reference](/reference) marked as generated are built from the
product's registries — editing them by hand is pointless, because the next build
overwrites them. Change the source instead; the page follows.