USACE-RMC · AdamGohs · May 19, 2026 · May 19, 2026 · May 19, 2026 · May 19, 2026
diff --git a/CLAUDE.md b/CLAUDE.md
@@ -5,42 +5,66 @@ This is the official documentation site for the **RMC (Risk Management Center) s
 ## Quick Commands
 
 ```bash
-npm start          # Start dev server (runs all generation scripts first)
-npm run build      # Build static site for production
-npm run counters   # Generate figure/table/equation counters
-npm run sidebars   # Generate sidebar navigation from MDX files
-npm run versions   # Extract version metadata
-npm run report-map # Create reportIdMap.js for document routing
+npm start            # Start dev server (runs all generation scripts first)
+npm run build        # Build static site for production
+npm run sidebars     # Generate sidebars.js from MDX folder structure
+npm run counters     # Generate figure/table/equation counters
+npm run versions     # Extract version metadata
+npm run report-map   # Generate reportIdMap.js for document routing
+npm run image-dims   # Generate image dimension metadata
+npm run generate-toc # Generate Event Tree Database TOC data
 ```
 
+Build scripts respect `DOCS_MODE`: `dev` (default) builds all docs including those flagged `active: false`; `prod` excludes inactive docs. `npm start` sets `dev`; `npm run build` sets `prod`.
+
 ## Project Structure
 
 ```
 docs/                          # Documentation content (MDX files)
 ├── desktop-applications/      # LifeSim, RMC-TotalRisk, RMC-RFA, RMC-BestFit
 ├── toolbox-technical-manuals/ # Internal Erosion, Overtopping, Risk Calcs, Seismic
 ├── web-applications/          # RRFT, LST, DST
-└── 00-documentation-guide/    # Contributor guide and style reference
+└── dev/                       # Developer-facing docs
+    ├── documentation-guide/   # Contributor guide and style reference
+    ├── github-workflows/      # GitHub workflow SOP
+    ├── architecture/          # Web app architecture references
+    ├── ai-development/        # AI-assisted development guidance
+    ├── python-quickstart-guide/
+    └── dst/                   # DST developer + UI style guides
 
 src/
 ├── components/                # 40+ custom React components (Figure, Table*, Citation, etc.)
-├── contexts/                  # ReportIdContext for version/document tracking
+├── contexts/                  # ReportIdContext, TourContext
 ├── css/                       # Tailwind & component styles
-└── theme/                     # Docusaurus theme customizations
+├── theme/                     # Docusaurus theme customizations (DocItem watermark, Layout, etc.)
+├── docConfig.js               # Central source of truth for active/draft flags
+└── draftDocs.js               # Thin shim around docConfig.js (consumed by DocItem)
 
-scripts/                       # Build automation (sidebar, counter, version generation)
+scripts/                       # Build automation (sidebars, counters, versions, etc.)
 static/                        # Static assets and auto-generated metadata
+.github/                       # CODEOWNERS, PR template, workflows, AI review prompt
+planning/                      # Implementation specs for cross-cutting changes
 ```
 
 ## Auto-Generated Files (DO NOT EDIT)
 
 These files are regenerated by build scripts:
 - `sidebars.js` - Generated from docs/ structure
 - `src/reportIdMap.js` - Generated from MDX frontmatter
+- `src/imageDimensions.js` - Generated from images in static/figures/
 - `static/counters/` - Figure/table/equation numbering
 - `static/versions/` - Version metadata
 - `src/data/` - Event tree TOC data
 
+## Document Active/Draft Flags
+
+`src/docConfig.js` is the central registry for every published document tile. Each entry has two orthogonal flags:
+
+- `active`: `true` means the doc is built, served, sidebar-registered, and indexed by Algolia. `false` means the doc is excluded from the prod build and renders as a "Coming Soon" tile on the landing page; in dev (`DOCS_MODE=dev`) it still builds so contributors can work on it.
+- `draft`: `true` renders a diagonal "DRAFT" watermark on the **latest version only** of the doc (older versions stay unwatermarked). `false` means no watermark.
+
+The two flags are orthogonal — a doc can be `active: true, draft: true` (published with watermark) or `active: false, draft: true` (unpublished but flagged for future watermarking).
+
 ## Key Patterns
 
 ### MDX Document Structure
@@ -78,6 +102,26 @@ Content with <Figure figKey="fig1" src="path" alt="text" caption="..." />
 - Version paths: `docs/{category}/{app}/{type}/v{major}.{minor}/`
 - Special files: `00-document-info.mdx`, `00-version-history.mdx`
 
+## Branching and Review Workflow
+
+The `main` branch is protected. All changes go through a pull request. Branch prefixes auto-assign the PR to one of five review lanes via the `stage-progression.yml` GitHub workflow:
+
+| Prefix | Lane | Reviews required |
+|---|---|---|
+| `docs/new/` | New document | Peer → Lead Civil → Technical edit → Director |
+| `docs/major/` | Major revision (new major version) | Peer → Lead Civil |
+| `docs/minor/` | Minor revision (new minor version) | Peer |
+| `docs/fix/` | Editorial fix | None (admin self-merge) |
+| `docs/dev/` | Dev docs (anything under `docs/dev/`) | None (admin self-merge) |
+
+Dev-docs detection is also content-based: any PR whose changed files under `docs/` are all under `docs/dev/` is auto-routed to `lane:dev` regardless of branch name.
+
+Branch protection on `main` requires two status checks:
+- `CI Build` — runs `npm run build` on every PR
+- `review-workflow` — set by `stage-progression.yml`; flips to success when the PR reaches `stage:ready-to-merge` (or immediately for `lane:editorial-fix` and `lane:dev`)
+
+Full details: [docs/dev/documentation-guide/](docs/dev/documentation-guide/) chapters 09–15.
+
 ## Code Style
 
 - Prettier: 150 char line width, single quotes, trailing commas
@@ -89,39 +133,24 @@ Content with <Figure figKey="fig1" src="path" alt="text" caption="..." />
 - Do NOT include "Co-Authored-By: Claude", "Claude Code", or any AI/assistant attribution in commit messages
 - Keep commit messages concise and focused on the changes made
 
-## Claude Code Skills
-
-This repository includes Claude Code skills (slash commands) in `.claude/skills/`. Reference files for skills are in `.claude/skills/*.md` (e.g., `git-conventions.md`).
-
-### Available Skills
-
-**Git**: `/commit`, `/push`, `/commit-push`, `/pr`, `/review-pr`
-**Page verification**: `/smoke-test`, `/review-responsive`, `/review-page`
-**Quality**: `/check-accessibility`, `/check-performance`, `/lint-fix`
-**Documentation**: `/qc-review`, `/build`, `/check-links`, `/check-components`
-**Scaffolding**: `/new-doc`
-
-See `.claude/skills/{name}/SKILL.md` for full documentation of each skill.
+## QC Reviews
 
-## QC Reviews & Technical Edits
-
-Use `/qc-review` skill or the QC prompt template at [qc/qc-prompt.md](qc/qc-prompt.md) for AI-assisted document reviews.
-
-### Review Levels
+The QC prompt template at [qc/qc-prompt.md](qc/qc-prompt.md) is a manually-usable template for AI-assisted document reviews. It supports three levels:
 
 | Level | Name | When to Use |
 |-------|------|-------------|
 | 1 | Syntax & Grammar | No source PDF available; check MDX syntax, components, grammar only |
 | 2 | Source Comparison | Source PDF available; Level 1 + verify MDX matches source exactly |
 | 3 | Technical Edit | Source PDF available; Levels 1 & 2 + suggest content improvements |
 
-### Key Rules
-
+Key rules:
 - **Level 1**: Do NOT suggest rewording or technical changes—syntax and grammar only
 - **Level 2**: Do NOT suggest improvements beyond matching the source document
 - **Level 3**: Full editorial suggestions allowed; mark these as "Editorial" category with "Suggestion" severity
 - All levels: Do NOT edit MDX files directly—output findings to `qc/` only
 
+The standardized prompt for the formal in-PR technical edit is at [.github/ai-review/technical-editor-prompt.md](.github/ai-review/technical-editor-prompt.md) — see Documentation Guide chapter 13 for how it's invoked.
+
 ## Requirements
 
 - Node.js >= 18.0

diff --git a/README.md b/README.md
@@ -12,7 +12,7 @@ The project includes:
 
 The project is organized to support easy contribution, internal consistency, and extensibility across future RMC documentation needs.
 
-For development standards, file structure, custom components, and styling conventions, please refer to the internal [Documentation Guide](https://usace-rmc.github.io/RMC-Software-Documentation/docs/documentation-guide/introduction/)
+For development standards, file structure, custom components, and styling conventions, please refer to the internal [Documentation Guide](https://usace-rmc.github.io/RMC-Software-Documentation/docs/documentation-guide/introduction/).
 
 The guide includes:
 
@@ -21,51 +21,25 @@ The guide includes:
 - Tailwind utility conventions and shared styles
 - Table formatting and counter file integration
 - Versioning strategy and linking guidelines
+- The full review and approval workflow for all documentation changes
 
-## Claude Code Skills
+## Review and Approval Workflow
 
-This repository includes Claude Code skills (slash commands) in `.claude/skills/` for common development workflows. Skills are invoked with `/{name}` in a Claude Code session.
+All changes to documentation go through a pull request against the protected `main` branch. The branch prefix determines which of five review lanes the PR is routed to:
 
-### Git & Repository
+| Branch prefix | Lane | Reviews required |
+|---|---|---|
+| `docs/new/` | New document | Peer → Lead Civil → Technical edit → Director |
+| `docs/major/` | Major revision (new major version) | Peer → Lead Civil → Technical edit |
+| `docs/minor/` | Minor revision (new minor version) | Peer → Technical edit |
+| `docs/fix/` | Editorial fix | None (admin self-merge) |
+| `docs/dev/` | Dev docs (anything under `docs/dev/`) | None (admin self-merge) |
 
-| Skill | Description |
-|-------|-------------|
-| `/commit` | Stage changes and create a git commit following project conventions |
-| `/push` | Push current branch to remote with safety checks |
-| `/commit-push` | Commit and push in a single operation |
-| `/pr` | Create a GitHub pull request with auto-generated title and description |
-| `/review-pr` | Review a pull request for code quality, MDX patterns, and documentation standards |
+Each PR receives an automatic preview build at an unadvertised URL where reviewers read the rendered document. Branch protection on `main` requires both the `CI Build` and `review-workflow` status checks to pass before merge, so the merge button reflects the workflow's judgment automatically.
 
-### Page Verification & Quality
+For details on each lane, who reviews what, and step-by-step instructions for authors, reviewers, the Director, and site administrators, see chapters 9 through 15 of the [Documentation Guide](https://usace-rmc.github.io/RMC-Software-Documentation/docs/documentation-guide/introduction/).
 
-| Skill | Description |
-|-------|-------------|
-| `/smoke-test` | Quick health check — page loads, no console errors, no broken images |
-| `/review-responsive` | Screenshot and analyze a page at 7 device viewports (desktop through phone) |
-| `/review-page` | Full page audit combining Lighthouse scores with responsive design review |
-| `/check-accessibility` | Section 508 / WCAG AA compliance audit using Lighthouse + Playwright |
-| `/check-performance` | Lighthouse performance audit with Core Web Vitals and resource analysis |
-| `/lint-fix` | Run ESLint, auto-fix issues, and provide guidance for remaining problems |
-
-### Documentation & QC
-
-| Skill | Description |
-|-------|-------------|
-| `/qc-review` | Run a QC review at Level 1, 2, or 3 on an MDX document (wraps `qc/qc-prompt.md`) |
-| `/build` | Run the Docusaurus production build and analyze errors/warnings |
-| `/check-links` | Scan MDX files for broken references, missing images, and orphaned keys |
-| `/check-components` | Validate custom component usage (props, imports, key uniqueness) in MDX files |
-
-### MCP Servers
-
-The following MCP servers enhance skill capabilities:
-
-- **Playwright** — Browser automation for screenshots, responsive testing, and smoke tests
-- **Lighthouse** — Performance, accessibility, SEO, and best practices auditing
-- **ESLint** — JavaScript linting via MCP
-- **Context7** — Library documentation lookup
-- **Sequential Thinking** — Multi-step reasoning for complex analysis
-- **GitHub** — GitHub API integration for PR and issue workflows
+## Contact
 
 For questions or support, contact the RMC documentation team:
 

diff --git a/docs/dev/documentation-guide/00-introduction.mdx b/docs/dev/documentation-guide/00-introduction.mdx
@@ -137,11 +137,21 @@ The documentation guide is structured to take you from setup through advanced us
 
 8. **[Troubleshooting & FAQ](./08-troubleshooting-faq.mdx)** - Solutions to common problems
 
+### Review and Approval Process
+
+9. **[Review and Approval Process Overview](./09-review-and-approval-overview.mdx)** - Roles, lanes, the merge gate, and the draft watermark
+10. **[Review Lanes](./10-review-lanes.mdx)** - Branch prefixes and which review stages apply to each lane
+11. **[Author Workflow](./11-author-workflow.mdx)** - From branch creation to publication
+12. **[Reviewer Workflow](./12-reviewer-workflow.mdx)** - For peer reviewers and RMC Lead Civils
+13. **[Technical Edit](./13-technical-edit.mdx)** - AI-assisted editorial review (includes the full prompt)
+14. **[Director Workflow](./14-director-workflow.mdx)** - Final approval for new documents
+15. **[Site Admin Workflow](./15-site-admin-workflow.mdx)** - Reviewer assignment, checkpoint deploys, merge prep
+
 ### Appendices (Advanced Topics)
 
-- **[Appendix A: Source Code Structure](./09-appendix-a-source-code-structure.mdx)** - Deep dive into project architecture
-- **[Appendix B: Build Process Overview](./10-appendix-b-build-process-overview.mdx)** - How automation scripts work behind the scenes
-- **[Appendix C: Search Configuration](./11-appendix-c-search-configuration.mdx)** - Algolia search setup (admin-level)
+- **[Appendix A: Source Code Structure](./16-appendix-a-source-code-structure.mdx)** - Deep dive into project architecture
+- **[Appendix B: Build Process Overview](./17-appendix-b-build-process-overview.mdx)** - How automation scripts work behind the scenes
+- **[Appendix C: Search Configuration](./18-appendix-c-search-configuration.mdx)** - Algolia search setup (admin-level)
 
 ---
 
@@ -258,20 +268,24 @@ This is regular text with **bold** and _italic_ formatting.
 
 ## Common Contribution Workflows
 
+The `main` branch is protected. Every change goes through a feature branch and a pull request. The branch prefix routes the PR to one of five review lanes — see [Review Lanes](./10-review-lanes.mdx) for the full mapping.
+
 ### Workflow 1: Convert Existing Word Document
 
 **Use case:** You have an existing RMC document in Word format that needs to be converted to MDX.
 
 **Steps:**
 
-1. Place Word document in `static/source-documents/`
-2. Run DOCX converter script to generate MDX files
-3. Review and refine generated MDX files
-4. Add generated files to appropriate `docs/` folder
-5. Test locally with `npm start`
-6. Commit changes to Git
+1. Create a `docs/new/<slug>` branch off `main`.
+2. Place the Word document in `static/source-documents/`.
+3. Run the DOCX converter script to generate MDX files.
+4. Review and refine generated MDX files.
+5. Add generated files to the appropriate `docs/` folder.
+6. Register the document in `src/docConfig.js` with `active: false, draft: true`.
+7. Test locally with `npm start`.
+8. Commit, push the branch, and open a pull request. The review workflow auto-assigns Lane 1 (peer → Lead Civil → technical edit → Director).
 
-**Typical time:** 1-3 hours depending on document complexity
+**Typical time:** 1-3 hours depending on document complexity.
 
 ---
 
@@ -283,19 +297,20 @@ This is regular text with **bold** and _italic_ formatting.
 
 For a detailed, step-by-step guide to creating a new document from scratch, see [Chapter 04: Creating a New Document - Complete Walkthrough](./04-creating-new-document-walkthrough.mdx).
 
-The walkthrough includes folder setup, asset organization, administrator coordination, testing procedures, and complete examples.
+The walkthrough includes folder setup, asset organization, testing procedures, and complete examples.
 
 :::
 
 **High-Level Steps:**
 
-1. Determine folder location based on hierarchy (see [Complete Walkthrough](./04-creating-new-document-walkthrough.mdx))
-2. Create all folder structures (docs/, static/figures/, static/videos/, static/bibliographies/)
-3. Add supporting assets (figures, videos, bibliography)
-4. Create MDX files (using DOCX converter or manually)
-5. Test locally with `npm start`
-6. Contact site administrator for deployment coordination
-7. Commit changes to repository after approval
+1. Create a `docs/new/<slug>` branch off `main`.
+2. Determine folder location based on hierarchy (see [Complete Walkthrough](./04-creating-new-document-walkthrough.mdx)).
+3. Create all folder structures (`docs/`, `static/figures/`, `static/videos/`, `static/bibliographies/`).
+4. Add supporting assets (figures, videos, bibliography).
+5. Create MDX files (using the DOCX converter or manually).
+6. Register the document in `src/docConfig.js` with `active: false, draft: true`.
+7. Test locally with `npm start`.
+8. Commit, push, and open a PR. The review workflow auto-assigns Lane 1 and guides you through peer → Lead Civil → technical edit → Director review (see [Author Workflow](./11-author-workflow.mdx)).
 
 **For detailed instructions, templates, real-world examples, and troubleshooting, use the [comprehensive walkthrough](./04-creating-new-document-walkthrough.mdx).**
 
@@ -305,23 +320,27 @@ The walkthrough includes folder setup, asset organization, administrator coordin
 
 **Use case:** You need to update an existing document for a new software version or to correct errors.
 
-**For minor edits (typos, small clarifications):**
+**For typos and editorial fixes (Lane 4):**
+
+1. Create a `docs/fix/<slug>` branch off `main`.
+2. Edit the existing version's MDX files directly.
+3. Test locally.
+4. Commit, push, and open a PR. The site admin will review and merge — no formal peer review required.
+
+**For minor revisions / new minor version (Lane 3):**
 
-1. Edit the existing version's MDX files directly
-2. Test locally
-3. Commit changes
+1. Create a `docs/minor/<slug>-v<version>` branch off `main`.
+2. Create the new version folder (e.g., `v1.1/`) by copying the previous version.
+3. Mirror the version structure for figures, bibliography, and source documents.
+4. Make your updates and flip `draft: true` on the document's entry in `src/docConfig.js`.
+5. Test locally.
+6. Commit, push, and open a PR. The workflow assigns Lane 3 (peer review → technical edit).
 
-**For major updates (new features, substantial changes):**
+**For major revisions / new major version (Lane 2):**
 
-1. Create new version folders (e.g., `v1.1/`)
-2. Copy all files from previous version
-3. Make updates to the new version
-4. Add new images to corresponding `static/figures/` version folder
-5. Update `bib.json` if needed
-6. Test locally
-7. Commit changes
+Same as Lane 3 but on a `docs/major/<slug>-v<version>` branch. The workflow adds an RMC Lead Civil review stage between peer review and the technical edit.
 
-**Typical time:** 30 minutes to 2 hours depending on scope
+**Typical time:** 30 minutes to a few hours depending on scope. Review turnaround adds days; plan accordingly.
 
 ---