|
| 1 | +# Netwrix Product Documentation — Claude Code Guide |
| 2 | + |
| 3 | +A Docusaurus v3.8.1 site serving documentation for 27+ Netwrix security products across 6 categories, with multi-version support and a centralized configuration system. |
| 4 | + |
| 5 | +## Development Commands |
| 6 | + |
| 7 | +```bash |
| 8 | +npm run start # Dev server on port 4500 |
| 9 | +npm run build # Production build (16 GB heap pre-configured) |
| 10 | +npm run clear # Clear Docusaurus cache |
| 11 | +npm run serve # Serve production build after build |
| 12 | + |
| 13 | +# Build/run a single product for faster iteration: |
| 14 | +export DOCS_PRODUCT="pingcastle" |
| 15 | +npm run start |
| 16 | +``` |
| 17 | + |
| 18 | +Available product IDs are defined in `src/config/products.js`. |
| 19 | + |
| 20 | +## Architecture |
| 21 | + |
| 22 | +### Single Source of Truth: `src/config/products.js` |
| 23 | + |
| 24 | +All product and version configuration lives here. Never manually edit `docusaurus.config.js` to add products, routes, or plugins — `products.js` auto-generates all of that. Changing a product means changing this file. |
| 25 | + |
| 26 | +### Versioned Documentation |
| 27 | + |
| 28 | +Docs live at `docs/<product>/<version>/` (for example, `docs/accessanalyzer/12.0/`). Edits to one version do not propagate to others — update each version that needs the change explicitly. |
| 29 | + |
| 30 | +Single-version (SaaS) products use `docs/<product>/` without a version subfolder. |
| 31 | + |
| 32 | +### Sidebars |
| 33 | + |
| 34 | +Each product version has a sidebar config in `sidebars/<product>/<version>.js` (or `sidebars/<product>.js` for single-version). These are separate from the doc content. Most use `autogenerated` and don't need manual editing unless custom ordering is required. |
| 35 | + |
| 36 | +### KB (Knowledge Base) System |
| 37 | + |
| 38 | +`docs/kb/` is the canonical source for KB articles. The script `scripts/copy-kb-to-versions.mjs` distributes articles into versioned product folders at build time (runs automatically as a pre-build step). |
| 39 | + |
| 40 | +**Never manually copy KB articles into versioned product folders.** Edit the source in `docs/kb/` and control distribution via `kb_allowlist.json`. |
| 41 | + |
| 42 | +## Adding Content |
| 43 | + |
| 44 | +### New product |
| 45 | + |
| 46 | +1. Add an entry to the `PRODUCTS` array in `src/config/products.js` |
| 47 | +2. Create `docs/<id>/` |
| 48 | +3. Create `sidebars/<id>.js` |
| 49 | + |
| 50 | +### New version of an existing product |
| 51 | + |
| 52 | +1. Update the `versions` array for that product in `src/config/products.js` — set `isLatest: true` on the new version and `isLatest: false` on the previous one |
| 53 | +2. Create `docs/<product>/<version>/` |
| 54 | +3. Create `sidebars/<product>/<version>.js` |
| 55 | + |
| 56 | +### New product category |
| 57 | + |
| 58 | +Add to the `PRODUCT_CATEGORIES` array in `src/config/products.js`. |
| 59 | + |
| 60 | +## Writing Style |
| 61 | + |
| 62 | +The full standards are in `netwrix_style_guide.md` at the project root. Read it when in doubt. |
| 63 | + |
| 64 | +**Always run Vale before finishing any documentation edit. Run it iteratively — fix all reported issues, then run again until Vale reports zero errors.** Fixes can occasionally introduce new violations. |
| 65 | + |
| 66 | +```bash |
| 67 | +vale <file> |
| 68 | +``` |
| 69 | + |
| 70 | +Vale enforces 26 Netwrix-specific rules in CI. Rules are in `.vale/styles/Netwrix/`. |
| 71 | + |
| 72 | +If Vale isn't installed, install it first: |
| 73 | + |
| 74 | +```bash |
| 75 | +# macOS |
| 76 | +brew install vale |
| 77 | + |
| 78 | +# Windows |
| 79 | +choco install vale |
| 80 | +# or download from https://github.com/errata-ai/vale/releases |
| 81 | + |
| 82 | +# Linux |
| 83 | +snap install vale --edge |
| 84 | +``` |
| 85 | + |
| 86 | +### Fixing Vale errors |
| 87 | + |
| 88 | +Most errors are simple substitutions — Vale reports the exact file, line, and column. Three rules require extra care: |
| 89 | + |
| 90 | +- **`NoteThat`** — Replace inline "Note that..." or "Please note..." with a Docusaurus admonition block: |
| 91 | + ```md |
| 92 | + :::note |
| 93 | + Content here. |
| 94 | + ::: |
| 95 | + ``` |
| 96 | + Use `:::warning` for warnings and `:::tip` for tips. |
| 97 | +
|
| 98 | +- **`BoilerplateCrossRef`** and **`WeakLinkText`** — Read the surrounding context and the link destination before rewriting. The fix must reflect what the reader will actually find at the destination. |
| 99 | +
|
| 100 | +- **`ImpersonalConstructions`** — Read the full sentence before rewriting. Restructure with an active subject rather than simply removing the flagged phrase. |
| 101 | +
|
| 102 | +### Rules Vale doesn't catch |
| 103 | +
|
| 104 | +Vale handles pattern-based violations automatically — run it and fix everything it reports. The following rules require judgment that Vale can't apply: |
| 105 | +
|
| 106 | +**Voice and structure** |
| 107 | +- Active voice and present tense throughout |
| 108 | +- Second person ("you") — address the reader directly |
| 109 | +- Contractions are encouraged: don't, can't, you'll |
| 110 | +- Keep sentences to one idea per sentence |
| 111 | +- Write for a global audience — avoid metaphors, idioms, and culturally specific references that don't translate |
| 112 | +- Omit "currently", "presently", and "as of this writing" — documentation should read as permanently accurate |
| 113 | +
|
| 114 | +**Document structure** |
| 115 | +- Order: overview → prerequisites → procedures |
| 116 | +- Task headings use imperative verbs: "Configure the monitoring plan" |
| 117 | +- Concept/overview headings use gerunds: "Configuring the monitoring plan" |
| 118 | +- Examples immediately follow the concept they illustrate |
| 119 | +- Images: store in `static/img/product_docs/<product>/`, use `.webp`, reference with absolute paths (`/img/product_docs/...`) |
| 120 | +
|
| 121 | +**Terminology** |
| 122 | +- Spell out acronyms on first use: "group Managed Service Account (gMSA)" |
| 123 | +- Use angle brackets for placeholders: `<report-name>` not `[report-name]` |
| 124 | +- Sentence case for feature names; capitalize Netwrix product names correctly |
| 125 | +- Oxford comma required in lists |
| 126 | +
|
| 127 | +## CI/CD Context |
| 128 | +
|
| 129 | +**Vale linter** — runs on every PR touching `.md` files, posts inline review comments. Does not block merges but issues are visible. |
| 130 | +
|
| 131 | +**Doc reviewer** (Claude Opus 4.6) — runs on every PR, reads full files, categorizes issues as "in PR changes" vs "preexisting", and posts inline suggestions reviewers can apply with one click. |
| 132 | +
|
| 133 | +**Doc fixer** — triggered by an `@claude` comment on a PR. Claude applies fixes and pushes. Fork PRs cannot be pushed to and receive a notice instead. |
| 134 | +
|
| 135 | +**Branch workflow** — PRs target `dev`. Merges to `main` trigger production deployment. |
| 136 | +
|
| 137 | +## Common Mistakes to Avoid |
| 138 | +
|
| 139 | +- Don't add products or routes by editing `docusaurus.config.js` — use `src/config/products.js` |
| 140 | +- Don't copy KB content manually into versioned product folders — it's managed by the KB script |
| 141 | +- Don't skip Vale before submitting — it will catch issues in CI anyway |
| 142 | +- Don't target `main` in PRs — use `dev` |
0 commit comments