Initial Documentation Refactor

.cursor/rules/docs-assist-merge-conflict-resolution.mdc

@@ -0,0 +1,71 @@
+---
+description: Resolve the merge conflicts using a "manual rebase" approach
+globs: 
+alwaysApply: false
+---
+# LLM-Assisted Merge Conflict Resolution
+
+When documentation branches fall behind main, use this "smart rebase" approach with LLM assistance to resolve conflicts safely and accurately.
+
+## Prerequisites
+- Identify the current branch name (`user/example-branch`) that contains your changes
+- Ensure you have no uncommitted changes in your working directory
+
+## Resolution Steps
+
+1. Create a backup of your current branch:
+   ```bash
+   git branch backup/user-branch-$(date +%Y-%m-%d) user/example-branch
+   ```
+
+2. Get the latest main branch:
+   ```bash
+   git checkout main
+   git pull origin main
+   ```
+
+3. Create a new resolution branch:
+   ```bash
+   git checkout -b conflict-resolution/example-branch
+   ```
+
+4. Bring in changes from your original branch:
+   ```bash
+   git merge --squash user/example-branch
+   ```
+
+5. LLM-Assisted Conflict Resolution:
+   a. For each conflict marker (`<<<<<<<`), the LLM will:
+      - Analyze and explain the conflict context
+      - Show the semantic differences between versions
+      - Provide a recommended resolution with rationale
+      - Wait for user approval before proceeding
+
+   b. After each resolution:
+      - LLM verifies the resolved content maintains technical accuracy
+      - LLM checks for documentation consistency
+      - LLM ensures cross-references remain valid
+
+6. Final Validation:
+   - LLM performs comprehensive review of all resolved files
+   - Verifies all conflict markers are removed
+   - Checks documentation structure remains intact
+   - Ensures all technical content is accurate
+   - Validates all internal references and links
+
+7. Commit the resolved changes:
+   ```bash
+   git add .
+   git commit -m "Resolve conflicts from user/example-branch
+
+   - List major conflicts resolved
+   - Note any significant decisions made
+   - Reference relevant documentation updates"
+   ```
+
+## Post-Resolution
+You now have a clean branch based on latest main with your changes properly integrated. The backup branch can be deleted once you've verified everything is correct:
+```bash
+git branch -D backup/user-branch-YYYY-MM-DD
+```
+

.cursor/rules/docs-bump-version.mdc

@@ -0,0 +1,13 @@
+---
+description: Version Bump Instructions for Docs Publishing
+globs: 
+alwaysApply: false
+---
+
+1. Update the [versions1.json](mdc:docs/versions1.json) file with the user's provided version by adding a new entry at the top and updating preferred to false for the previous entry.
+2. Update the [repo.toml](mdc:repo.toml) `version` to the latest version provided by the user.
+2. Create a tag for the latest commit on the `main` branch in the format of "git tag docs-v{}.{}.{}`.
+3. Push the tag.
+4. Recap everything you did to prepare for the release.
+
+If a user asks you to bump the version but hasn't provided a full version number, ask for clarification on the version number.

.cursor/rules/docs-check-source.mdc

@@ -0,0 +1,8 @@
+---
+description: Where to find source code for drafting details.
+globs: 
+alwaysApply: false
+---
+- You can find the source code used to draft docs in the project's main source directory.
+
+- Make sure the main branch is up to date when verifying this information, as that represents the current development state.

.cursor/rules/docs-os.mdc

@@ -0,0 +1,13 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+When a user provides one of the following commands, perform its associated task.
+
+- **Commands**:
+  - "::a": check the article against the source code in the project's main source directory using the [docs-info-verification.mdc](mdc:.cursor/rules/docs-info-verification.mdc)
+  - "::r": revise the article using the [docs-style-guide.mdc](mdc:.cursor/rules/docs-style-guide.mdc)
+  - "::f": format the article using the [docs-tooling.mdc](mdc:.cursor/rules/docs-tooling.mdc)
+  - "::bv": bump project version using [docs-bump-version.mdc](mdc:.cursor/rules/docs-bump-version.mdc)
+  - "::h-mr": help resolve a merge conflict using [docs-assist-merge-conflict-resolution.mdc](mdc:.cursor/rules/docs-assist-merge-conflict-resolution.mdc)

.cursor/rules/docs-personas.mdc

@@ -0,0 +1,57 @@
+---
+description: Documentation guidelines for addressing specific audience personas including data scientists, MLEs, cluster administrators, and DevOps professionals.
+globs: 
+alwaysApply: false
+---
+# Documentation Personas
+
+Our documentation is for enterprise AI products and features consumed by personas like data scientists, machine learning engineers, cluster administrators, and devops professionals. Common tools include: Kubernetes, notebooks, python, AI models.
+
+## Persona-Specific Guidelines
+
+### For Data Scientists
+- Include details on data formats and schemas
+- Document model validation methodologies clearly
+- Specify computational requirements for processing
+- Provide notebook examples with clear annotations
+- Include metrics for model performance evaluation
+- Document data preprocessing and feature engineering steps
+- Explain hyperparameter tuning approaches
+
+### For Machine Learning Engineers
+- Document model training pipelines completely
+- Include details on environment setup and dependencies
+- Provide testing and validation methodologies
+- Explain model deployment workflows
+- Document CI/CD integration for ML pipelines
+- Include performance optimization techniques
+- Provide examples of model serving configurations
+
+### For Cluster Administrators
+- Include complete deployment architectures
+- Document security considerations thoroughly
+- Provide detailed monitoring and maintenance procedures
+- Include troubleshooting guides for common issues
+- Document resource allocation recommendations
+- Provide scaling guidelines for different workloads
+- Include backup and disaster recovery procedures
+
+### For DevOps Professionals
+- Document infrastructure-as-code implementations
+- Include automation workflows and templates
+- Provide observability and monitoring setup
+- Document CI/CD pipeline integrations
+- Include security best practices for deployments
+- Explain high availability configurations
+- Document canary deployment and rollback procedures
+
+## Writing Style by Persona
+
+When writing for different personas, adjust your style:
+
+- **Data Scientists**: Focus on analytical concepts and model behavior
+- **ML Engineers**: Emphasize implementation details and pipeline architecture
+- **Cluster Admins**: Prioritize operational stability and system interactions
+- **DevOps**: Focus on automation, reliability, and maintainability
+
+Keep these personas in mind when drafting and evaluating documentation.

.cursor/rules/docs-style-guide.mdc

@@ -0,0 +1,17 @@
+---
+description: The documentation style guide.
+globs: 
+alwaysApply: false
+---
+Adhere to the NVIDIA Style Guide when drafting or editing content. Ensure the following:
+
+1. Brand Name: Ensure "NVIDIA" is always in all caps.
+2. Voice & Tone: Use PACE (Professional, Active, Conversational, Engaging). Maintain a consistent, natural voice. Use active voice and contractions.
+Abbreviations & Acronyms: Spell out on first use, then use abbreviations. Common acronyms like PC don't need to be spelled out.
+4. Capitalization: Use title case for headings and proper nouns. Avoid capitalizing conjunctions and prepositions of three letters or less.
+Punctuation: Use Oxford commas. Avoid ampersands unless in titles. Use em dashes for emphasis, en dashes for ranges.
+Dates & Times: Use the 12-hour format with periods (e.g., 12:45 p.m.). Abbreviate months in tables.
+Units of Measurement: Be consistent. Use a space between the number and unit (e.g., 40 GB).
+Inclusivity: Avoid gender-specific pronouns and Latinisms. Use plain English.
+10. Formatting: Use italics for publication titles and games. Use bold for UI elements.
+Please review the text for these guidelines and suggest any necessary edits to ensure compliance with the NVIDIA Style Guide.

.cursor/rules/docs-tooling.mdc

@@ -0,0 +1,132 @@
+---
+description: Specialized MyST/Sphinx markdown directives for documentation files. Apply when drafting or editing documentation that uses directives, grids, tabs, admonitions, or other Sphinx extensions.
+globs: 
+alwaysApply: false
+---
+# Sphinx/MyST Documentation Tooling Rule
+
+Our documentation uses Sphinx with MyST markdown and sphinx-design. Follow these rules for all files in `docs/`:
+
+- **Headers:**  
+  - Every header (including subheaders) must have a unique relref label above it in the format `(section-article-header)=`.  
+  - Example: `(evaluate-jobs-create)=`  
+  - Use lowercase, hyphens, and abbreviate as needed.  
+  - Avoid duplicate labels across the project.
+  - **Example:**
+    ```markdown
+    (evaluate-jobs-create)=
+    # Create Evaluation Job
+
+    (evaluate-jobs-create-prereqs)=
+    ## Prerequisites
+    ```
+
+- **Code Samples:**  
+  - Use dropdowns for code blocks longer than 10 lines or for any code that may distract from the main flow.  
+  - Title dropdowns meaningfully (e.g., “Python Example”, “Full YAML Config”).
+  - **Example:**
+    ```markdown
+    :::{dropdown} Python Example
+    :icon: code-square
+
+    ```python
+    def hello():
+        print("Hello, world!")
+    # ...more code...
+    ```
+    :::
+    ```
+
+- **Tabs:**  
+  - Use tab-sets for alternative options (e.g., curl vs. python, CLI vs. UI).  
+  - Each tab should have a clear, descriptive title.
+  - Use the `:sync:` attribute for tab-sets to synchronize tab selection across the page.
+  - **Example:**
+    ```markdown
+    :::: {tab-set}
+
+    ::: {tab-item} Python
+    :sync: sync-pyth
+    `requests.get("https://api.example.com")`
+    :::
+    ::: {tab-item} curl
+    :sync: sync-cli
+    `curl https://api.example.com`
+    :::
+    ::::
+    ```
+
+- **Cards:**  
+  - Use grid card links for parent/overview pages with multiple links to subtopics or guides.  
+  - Each card should have a short title and a 1–2 sentence description.
+  - **Example:**
+    ```markdown
+    :::: {grid} 1 2 2 2
+    :gutter: 1 1 1 2
+
+    ::: {grid-item-card} Getting Started
+    :link: get-started-index
+    :link-type: ref
+
+
+
+    Learn how to get started with the platform.
+    :::
+    ::::
+    ```
+
+- **Lists/Tables:**  
+  - Use lists or tables for short, related items, steps, or comparisons.  
+  - Prefer tables for side-by-side feature or parameter comparisons.
+  - **Example (Table):**
+    ```markdown
+    | Feature | Supported |
+    |---------|-----------|
+    | Tabs    | Yes       |
+    | Cards   | Yes       |
+    ```
+  - **Example (List):**
+    ```markdown
+    - Step 1: Do this
+    - Step 2: Do that
+    ```
+  - Prefer myst list tables for advanced tables over markdown tables
+
+- **Admonitions:**  
+  - Use admonitions sparingly because they interrupt the flow of information.
+    - Use a note to identify surprising or unexpected behavior.
+    - Use a warning to identify risk of physical injury or data loss.
+    - Use a tip to reveal a positive behavior in the software that someone might not discover on their own.
+  - Example:  
+    - `note` for general info  
+    - `warning` for risks  
+    - `tip` for best practices  
+  - **Example:**
+    ```markdown
+    :::{note}
+    You must have an API key before proceeding.
+    :::
+    ```
+
+- **References:**  
+  - Use `{ref}` for internal links, referencing the relref label.  
+  - Check for existing relref labels before creating new ones.
+  - **Example:**
+    ```markdown
+    Refer to the {ref}`customization job <ft-create-customization-job>` guide.
+    ```
+
+- **Accessibility:**  
+  - Add alt text to images.  
+  - Use descriptive tab and dropdown titles.  
+  - Ensure tables and lists are readable by screen readers.
+  - Avoid abelist language like "see", "above", "below".
+
+- **Style & Consistency:**  
+  - Follow the style guide for tone, terminology, and formatting.  
+  - Use consistent abbreviations and naming conventions.
+
+- **If Unsure:**  
+  - Check existing docs for examples.  
+  - Ask for clarification if a rule or pattern is unclear.
+

.vscode/settings.json

@@ -20,5 +20,6 @@
         "test"
     ],
     "python.testing.unittestEnabled": false,
-    "python.testing.pytestEnabled": true
+    "python.testing.pytestEnabled": true,
+    "iis.configDir": ""
 }

CONTRIBUTING.md

@@ -30,10 +30,10 @@ Not all steps are necessary for some contributions, so read the linked sections
 We use [uv](https://docs.astral.sh/uv/) to develop NeMo Run. The following steps should get you started with the dev environment:
 
 1. Install [uv](https://docs.astral.sh/uv/getting-started/installation/)
-2. Clone NeMo-Run
+2. Clone NeMo Run
 3. Sanity check with `uv sync --extra skypilot && uv run -- pytest test/` (This will create a venv and run all unit tests)
 
-If all tests passed, then you should be good to get started with the development of NeMo-Run.
+If all tests passed, then you should be good to get started with the development of NeMo Run.
 
 ## Code Structure