fix: various docs updates, including hiding intake (#455)

* fix: various docs updates, including hiding intake

Signed-off-by: Matt Kornfield <mkornfield@nvidia.com>

* chore: address cr

Signed-off-by: Matt Kornfield <mkornfield@nvidia.com>

* chore: remove tool workflow ref, update auditor endpoint

Signed-off-by: Matt Kornfield <mkornfield@nvidia.com>

---------

Signed-off-by: Matt Kornfield <mkornfield@nvidia.com>

Author: mckornfield

.github/workflows/fern-docs-preview-comment.yaml

@@ -62,6 +62,7 @@ jobs:
           HEAD_REF: ${{ steps.metadata.outputs.head_ref }}
         working-directory: ./docs/fern
         run: |
+          node scripts/filter-public-openapi.mjs
           OUTPUT=$(npx -y fern-api@latest generate --docs --preview --id "$HEAD_REF" 2>&1)
           echo "$OUTPUT"
           URL=$(echo "$OUTPUT" | grep -oP 'Published docs to \K.*(?= \()')

.gitignore

@@ -143,3 +143,6 @@ docker/logs/*
 # Linting artifact
 python-sdk-lint/
 site/
+
+# Generated Fern-only public API reference spec
+docs/fern/openapi/openapi.public.yaml

docs/AGENTS.md

@@ -39,4 +39,4 @@ These are generated; edit the source and regenerate:
 
 ## API reference
 
-The REST API reference is rendered natively by Fern from the OpenAPI spec — `docs/fern/generators.yml` points at `docs/fern/openapi/openapi.yaml` (a symlink to the generated repo-root `openapi/openapi.yaml`), surfaced by the `- api: API Reference` nav node. No `<swagger-ui>` embed.
+The REST API reference is rendered natively by Fern from a docs-only filtered OpenAPI spec. `docs/fern/openapi/openapi.yaml` is a symlink to the generated repo-root `openapi/openapi.yaml`, and `npm run prepare:openapi` writes `docs/fern/openapi/openapi.public.yaml` for Fern. `docs/fern/generators.yml` must point at the public filtered spec, surfaced by the `- api: API Reference` nav node. No `<swagger-ui>` embed.

docs/agents/plugins.mdx

@@ -4,7 +4,7 @@ description: ""
 ---
 <a id="agents-plugins"></a>
 
-NeMo Platform 0.1.0 is extended through Python plugins and
+NeMo Platform 0.2.0 is extended through Python plugins and
 coding-agent skills. Plugins add runtime capabilities to the local platform.
 Skills teach your coding agent how to operate those capabilities on your behalf.
 
@@ -103,5 +103,5 @@ Plugin authors use the `nemo-platform-plugin` package. A minimal plugin declares
 points in `pyproject.toml`, implements the matching class, and restarts
 `nemo services run` so the local platform discovers it.
 
-Keep plugins local-first for OSS 0.1.0: avoid requiring a cluster,
+Keep plugins local-first for OSS 0.2.0: avoid requiring a cluster,
 container runtime, or external control plane for the documented launch path.

docs/auth/authorization/api-scopes.mdx

@@ -25,7 +25,7 @@ Each API has a read and write scope. A token with an API-specific scope can only
 
 | API | Read Scope | Write Scope | Endpoints |
 |------|-----------|-------------|------|
-| Audit | `audit:read` | `audit:write` | `/apis/audit/` |
+| Audit | `audit:read` | `audit:write` | `/apis/auditor/` |
 | Auth | `auth:read` | `auth:write` | `/apis/auth/` |
 | Data Designer | `data-designer:read` | `data-designer:write` | `/apis/data-designer/` |
 | Entities | `entities:read` | `entities:write` | `/apis/entities/` (internal — see note) |

docs/auth/authorization/managing-access.mdx

@@ -6,7 +6,7 @@ Add users to workspaces, assign roles, and control who can access your resources
 
 <Note>
 
-The SDK examples on this page use `NeMoPlatform()` with no arguments so that the client reads your active CLI context (set by `nemo auth login`). That is the right pattern for authorization workflows: you act as your logged-in identity and pass the workspace explicitly in each API call. For the standard local initialization pattern, see [CLI and SDK initialization](/documentation/get-started#setup-init).
+The SDK examples on this page use `NeMoPlatform()` with no arguments so that the client reads your active CLI context (set by `nemo auth login`). That is the right pattern for authorization workflows: you act as your logged-in identity and pass the workspace explicitly in each API call. For the standard local initialization pattern, see [CLI and SDK initialization](/documentation/get-started#nemo-setup).
 
 </Note>
 ## Creating Workspaces

docs/auth/authorization/permissions-reference.mdx

@@ -58,22 +58,6 @@ PlatformAdmin is omitted — it bypasses permission checks entirely at the polic
 | <code>inference.virtual-models.(read &#124; list)</code> | Read, list inference virtual-models | ✓ | ✓ | ✓ |
 | <code>inference.virtual-models.(create &#124; update &#124; delete)</code> | Create, update, delete inference virtual-models |  | ✓ | ✓ |
 
-## Intake API
-
-| Permission | Description | Viewer | Editor | Admin |
-|------------|-------------|:------:|:------:|:-----:|
-| <code>intake.annotations.(read &#124; list)</code> | Read, list intake annotations | ✓ | ✓ | ✓ |
-| <code>intake.annotations.(create &#124; delete)</code> | Create, delete intake annotations |  | ✓ | ✓ |
-| <code>intake.evaluator-results.(read &#124; list)</code> | Read, list intake evaluator-results | ✓ | ✓ | ✓ |
-| `intake.evaluator-results.create` | Create intake evaluator results |  | ✓ | ✓ |
-| `intake.experiment-groups.read` | Read intake experiment groups | ✓ | ✓ | ✓ |
-| <code>intake.experiment-groups.(create &#124; update &#124; delete)</code> | Create, update, delete intake experiment-groups |  | ✓ | ✓ |
-| `intake.experiments.read` | Read intake experiments | ✓ | ✓ | ✓ |
-| <code>intake.experiments.(create &#124; update &#124; delete)</code> | Create, update, delete intake experiments |  | ✓ | ✓ |
-| `intake.ingest.create` | Ingest traces into intake |  | ✓ | ✓ |
-| <code>intake.spans.(read &#124; list)</code> | Read, list intake spans | ✓ | ✓ | ✓ |
-| `intake.traces.read` | Read intake traces | ✓ | ✓ | ✓ |
-
 ## Jobs API
 
 | Permission | Description | Viewer | Editor | Admin |

docs/contributing/skills-spec.mdx

@@ -2,7 +2,6 @@
 title: "NeMo Platform Skills Spec"
 description: ""
 ---
-**Status:** Draft.
 
 This document defines the conventions for skills shipped with NeMo Platform: how they're structured, what their frontmatter must contain, how they get tested, and where they live in the repo.
 

docs/customizer/tutorials/format-training-dataset.mdx

@@ -236,7 +236,7 @@ For illustrative purposes only, we show an example entry as multi-line JSON.
 </Accordion>
 ##### Shared Tools
 
-When your dataset uses the same set of tools across all examples, include the shared tool definitions in **each training row** (Automodel jobs do not accept a separate `dataset_parameters` block). See the [Tool Calling tutorial](/documentation/example-applications/tool-calling) for a full workflow.
+When your dataset uses the same set of tools across all examples, include the shared tool definitions in **each training row** (Automodel jobs do not accept a separate `dataset_parameters` block).
 
 ```python
 import os

docs/evaluator/tutorials/index.mdx

@@ -32,4 +32,4 @@ Learn how to write a domain-specific Python metric, test it locally, and run it
 
 ## How It Works
 
-For the conceptual overview of how Evaluator separates definition (library) from execution (platform), see [About Evaluating → How It Works](/documentation/evaluate-models#how-it-works-library-platform). For runnable SDK examples, see [SDK Resources](/documentation/evaluate-models/sdk-resources).
+For the conceptual overview of how Evaluator separates definition (library) from execution (platform), see [About Evaluating → How It Works](/documentation/evaluate-models#how-it-works-library--platform). For runnable SDK examples, see [SDK Resources](/documentation/evaluate-models/sdk-resources).