resolve mintlify parsing errors and restore rules table rendering

ai-evals/node.mdx

@@ -13,15 +13,13 @@ import WrapOpenAI from '/snippets/ai-sdks/node/wrapOpenAI.mdx'
 import LogEvalResult from '/snippets/ai-sdks/node/logEvalResult.mdx'
 import GetPrompt from '/snippets/ai-sdks/node/getPrompt.mdx'
 import Otel from '/snippets/ai-sdks/node/otel.mdx'
-import AiOptions from '/snippets/ai-sdks/node/aiOptions.mdx'
 import ProgrammaticEval from '/snippets/ai-sdks/node/programmatic-eval.mdx'
 
 import InitializationPreamble from '/snippets/ai-sdks/initialization.mdx'
 import InitializationManagedPreamble from '/snippets/ai-sdks/initializationManaged.mdx'
 import WrapOpenAIPreamble from '/snippets/ai-sdks/wrapOpenAI.mdx'
 import LogEvalResultPreamble from '/snippets/ai-sdks/logEvalResult.mdx'
 import GetPromptPreamble from '/snippets/ai-sdks/getPrompt.mdx'
-import AiOptionsPreamble from '/snippets/ai-sdks/aiOptions.mdx'
 import OtelPreamble from '/snippets/ai-sdks/otel.mdx'
 import ProgrammaticEvalPreamble from '/snippets/ai-sdks/programmatic-eval.mdx'
 
@@ -80,9 +78,6 @@ If you already have a Statsig instance, you can pass it into the SDK. Otherwise,
 <WrapOpenAIPreamble/>
 <WrapOpenAI/>
 
-<AiOptionsPreamble/>
-<AiOptions/>
-
 ## Using other SDK methods
 Whether you passed in a Statsig instance or not, you can access the Statsig instance from the statsigAI instance, and use its many methods: 
 ```javascript

docs.json

@@ -388,7 +388,6 @@
                   "metrics/pulse",
                   "metrics/local-metrics",
                   "metrics/console",
-                  "metrics/health-checks",
                   {
                     "group": "Metrics 201 - Creating Metrics",
                     "pages": [

docs/server-core/node/migration-guide/_api_changes.mdx

@@ -1,5 +1,3 @@
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
 
 ### Key Package and Class Changes
 

docs/server-core/node/migration-guide/index.mdx

@@ -3,46 +3,24 @@ title: Node Core SDK Migration Guide
 displayed_sidebar: api
 ---
 
-import CodeBlock from '@theme/CodeBlock';
-import {
-  SDKDocsBuilder,
-} from "../../../sdks/_SDKDocsBuilder.mdx";
-
-import {
-    APIChanges,
-    GlobalChanges,
-    Installation,
-    MigrationHelp,
-    StatsigOptions,
-    UserCreation,
-    NeedHelp,
-    Troubleshooting,
-    Intro,
-} from "../../MigrationGuideTemplates/index.mdx";
 import NodeAPIChanges from "./_api_changes.mdx";
-import NodeUserCreation from "./_user_creation.mdx";
 import NodeStatsigOptions from "./_statsig_options.mdx";
 
-export const Builder = SDKDocsBuilder({
-  sections: [
-    [
-      Intro,
-      {
-        sdkType: "Node JS",
-      },
-    ],
-
-    [
-      Installation,
-      {
-        legacyInstall: <CodeBlock>npm install statsig-node</CodeBlock>,
-        install: <CodeBlock>npm install @statsig/statsig-node-core</CodeBlock>,
-      },
-    ],
-    [
-      UserCreation,
-      {
-        newUserCreation: <CodeBlock language="nodejs">
+This guide walks through migrating from the legacy `statsig-node` SDK to the
+Node Core SDK (`@statsig/statsig-node-core`).
+
+## Installation
+
+**Node Core SDK**
+<CodeBlock>npm install @statsig/statsig-node-core</CodeBlock>
+
+**Legacy Node SDK**
+<CodeBlock>npm install statsig-node</CodeBlock>
+
+## User creation
+
+**Node Core SDK**
+<CodeBlock language="nodejs">
 {`import {StatsigUser} from "@statsig/statsig-node-core"
 const user = new StatsigUser({
     userID: "user_123",
@@ -54,8 +32,10 @@ const user = new StatsigUser({
     "subscription_level": "premium"
     }
 })
-`}</CodeBlock>,
-        legacyUserCreation: <CodeBlock language="python">
+`}</CodeBlock>
+
+**Legacy Node SDK**
+<CodeBlock language="python">
 {`import type {StatsigUser} from "statsig-node"
 user = {
     userID: "user_123",
@@ -67,38 +47,26 @@ user = {
     "subscription_level": "premium"
     }
 }
-`}</CodeBlock>,
-}
-],
-[
-APIChanges,
-{
-apiChanges: <NodeAPIChanges />
-}
-],
-[
-GlobalChanges,
-{
-waitForUserAgentInit: "wait_for_user_agent_init",
-waitForCountryLookupInit: "wait_for_country_lookup_init",
-disableUserAgentParsing: "disable_user_agent_parsing",
-disableCountryLookup: "disable_country_lookup",
-enableIdLists: "enable_id_lists"
-},
-],
-[
-StatsigOptions,
-{
-optionsMapping: <NodeStatsigOptions />
-}
-],
-[
-NeedHelp,
-{}
-],
-]
-})
+`}</CodeBlock>
+
+## API changes
+
+<NodeAPIChanges />
+
+## Global option name changes
+
+| Legacy option | Node Core option |
+| --- | --- |
+| `waitForUserAgentInit` | `wait_for_user_agent_init` |
+| `waitForCountryLookupInit` | `wait_for_country_lookup_init` |
+| `disableUserAgentParsing` | `disable_user_agent_parsing` |
+| `disableCountryLookup` | `disable_country_lookup` |
+| `enableIdLists` | `enable_id_lists` |
+
+## Statsig options
+
+<NodeStatsigOptions />
 
-export const toc = Builder.toc;
+## Need help?
 
-<>{Builder.result}</>
+If you run into issues while migrating, reach out to your Statsig contact.

experiments/implementation/getting-group.mdx

@@ -68,17 +68,14 @@ As you can see, using parameters directly when you are coding is much simpler an
 
 The diagnostics stream is meant to be used for debugging your integration, and understanding which groups a user is being bucketed into.  The following defines the different Rules you will see, and what they mean.
 
-
-+-------------------------------+---------------------------------------------------------------------------------------------------------+
-| Rule                          | Meaning                                                                                                 |
-+-------------------------------+---------------------------------------------------------------------------------------------------------+
-| Not started                   | The experiment has not been started, so the allocation groups are not determined yet                    |
-| Holdout                       | The user is in a holdout that this experiment references, so they are not in the experiment             |
-| Layer Assignment              | The user is not allocated to this experiment because they are bucketed to a different part of the Layer |
-| Targeting Gate/Inline Targeting | The user does not meet the requirements for the targeting gate or inline targeting                     |
-| Not Allocated                 | The user is not allocated to this experiment because they do not meet the rollout %                     |
-| {group name}{override name}   | The user was forcefully bucketed into a given group by an experiment override                           |
-| {group name}                  | The user was bucketed into this experiment group                                                        |
-| Abandoned                     | "Make Decision" selected the control group. This experiment has been abandoned.                        |
-| {group name} (Launched)       | "Make Decision" selected this group as the launch group, so the user is seeing the launched experience. |
-+-------------------------------+---------------------------------------------------------------------------------------------------------+
+| Rule | Meaning |
+| --- | --- |
+| Not started | The experiment has not been started, so the allocation groups are not determined yet |
+| Holdout | The user is in a holdout that this experiment references, so they are not in the experiment |
+| Layer Assignment | The user is not allocated to this experiment because they are bucketed to a different part of the Layer |
+| Targeting Gate/Inline Targeting | The user does not meet the requirements for the targeting gate or inline targeting |
+| Not Allocated | The user is not allocated to this experiment because they do not meet the rollout % |
+| `{group name}{override name}` | The user was forcefully bucketed into a given group by an experiment override |
+| `{group name}` | The user was bucketed into this experiment group |
+| Abandoned | "Make Decision" selected the control group. This experiment has been abandoned. |
+| `{group name}` (Launched) | "Make Decision" selected this group as the launch group, so the user is seeing the launched experience. |

integrations/data-imports/bigquery.mdx

@@ -110,7 +110,8 @@ or `statsig_events_signal` for events. For example, once all of your metrics dat
 Statsig expects you to load data in order. For example, if you have loaded up to `2022-04-01` and signal that `2022-04-03` has landed,
 we will wait for you to signal that `2022-04-02` has landed, and load that data before we ingest data from `2022-04-03`
 
-<Note> This ingestion pipeline is in beta, and does not currently support automatic backfills or updates to data once it's been ingested. Only signal these tables
+<Note>
+This ingestion pipeline is in beta, and does not currently support automatic backfills or updates to data once it's been ingested. Only signal these tables
 are loaded after you've run data quality checks!
 </Note>
 

integrations/data-imports/snowflake.mdx

@@ -206,7 +206,8 @@ or `statsig_events_signal` for events. For example, once all of your metrics dat
 Statsig expects you to load data in order. For example, if you have loaded up to `2022-04-01` and signal that `2022-04-03` has landed,
 we will wait for you to signal that `2022-04-02` has landed, and load that data before we ingest data from `2022-04-03`
 
-<Note> This ingestion pipeline is in beta, and does not currently support automatic backfills or updates to data once it's been ingested. Only signal these tables
+<Note>
+This ingestion pipeline is in beta, and does not currently support automatic backfills or updates to data once it's been ingested. Only signal these tables
 are loaded after you've run data quality checks!
 </Note>
 

snippets/ai-sdks/programmatic-eval.mdx

@@ -14,7 +14,8 @@ With programmatic evaluation, you can:
 
 The evaluation automatically sends results to Statsig, where you can view them in the console alongside your other eval data.
 
-<Note> Tasks and scorers can be async functions. Data can also be provided as async functions, promises, or async iterators. 
-The `expected` field in data records is optional - scorers can evaluate outputs without expected values. 
+<Note>
+Tasks and scorers can be async functions. Data can also be provided as async functions, promises, or async iterators.
+The `expected` field in data records is optional - scorers can evaluate outputs without expected values.
 Task and scorer errors are automatically caught and reported in the results.
 </Note>