From c7b4090a6cb0989393e8fdba62e37ee248ad5622 Mon Sep 17 00:00:00 2001
From: jonaslagoni <jonas-lt@live.dk>
Date: Fri, 31 Jul 2026 10:00:52 +0000
Subject: [PATCH] chore(release): v0.81.1

---
 docs/README.md                           |   1 +
 docs/contributing.md                     |   1 +
 docs/migrations/v0.md                    |   1 +
 docs/usage.md                            |   8 +-
 mcp-server/lib/resources/bundled-docs.ts |  22 +-
 package-lock.json                        |   4 +-
 package.json                             |   2 +-
 website/static/codegen.browser.mjs       | 317 ++++++++++++++++++-----
 8 files changed, 280 insertions(+), 76 deletions(-)

diff --git a/docs/README.md b/docs/README.md
index 3098bde7..e33093d8 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -104,5 +104,6 @@ Connect AI assistants like Claude Code, Cursor, and Windsurf to The Codegen Proj
 
 
 
+
 
 
diff --git a/docs/contributing.md b/docs/contributing.md
index d4cecf96..781352fd 100644
--- a/docs/contributing.md
+++ b/docs/contributing.md
@@ -222,5 +222,6 @@ Prefix that follows specification is not enough though. Remember that the title
 
 
 
+
 
 
diff --git a/docs/migrations/v0.md b/docs/migrations/v0.md
index 8f0ec5c8..35bc87ac 100644
--- a/docs/migrations/v0.md
+++ b/docs/migrations/v0.md
@@ -250,5 +250,6 @@ import * as NodeFetch from 'node-fetch';
 
 
 
+
 
 
diff --git a/docs/usage.md b/docs/usage.md
index 64ba874c..48cda2a0 100644
--- a/docs/usage.md
+++ b/docs/usage.md
@@ -8,7 +8,7 @@ $ npm install -g @the-codegen-project/cli
 $ codegen COMMAND
 running command...
 $ codegen (--version)
-@the-codegen-project/cli/0.81.0 linux-x64 node-v22.23.1
+@the-codegen-project/cli/0.81.1 linux-x64 node-v22.23.1
 $ codegen --help [COMMAND]
 USAGE
   $ codegen COMMAND
@@ -92,7 +92,7 @@ DESCRIPTION
   configuration.
 ```
 
-_See code: [src/commands/generate.ts](https://github.com/the-codegen-project/cli/blob/v0.81.0/src/commands/generate.ts)_
+_See code: [src/commands/generate.ts](https://github.com/the-codegen-project/cli/blob/v0.81.1/src/commands/generate.ts)_
 
 ## `codegen help [COMMAND]`
 
@@ -166,7 +166,7 @@ DESCRIPTION
   Initialize The Codegen Project in your project
 ```
 
-_See code: [src/commands/init.ts](https://github.com/the-codegen-project/cli/blob/v0.81.0/src/commands/init.ts)_
+_See code: [src/commands/init.ts](https://github.com/the-codegen-project/cli/blob/v0.81.1/src/commands/init.ts)_
 
 ## `codegen telemetry ACTION`
 
@@ -199,7 +199,7 @@ EXAMPLES
   $ codegen telemetry disable
 ```
 
-_See code: [src/commands/telemetry.ts](https://github.com/the-codegen-project/cli/blob/v0.81.0/src/commands/telemetry.ts)_
+_See code: [src/commands/telemetry.ts](https://github.com/the-codegen-project/cli/blob/v0.81.1/src/commands/telemetry.ts)_
 
 ## `codegen version`
 
diff --git a/mcp-server/lib/resources/bundled-docs.ts b/mcp-server/lib/resources/bundled-docs.ts
index 994ed0bc..79cba8f7 100644
--- a/mcp-server/lib/resources/bundled-docs.ts
+++ b/mcp-server/lib/resources/bundled-docs.ts
@@ -1,7 +1,7 @@
 /**
  * Auto-generated documentation bundle.
  * DO NOT EDIT - regenerate with: npm run bundle-docs
- * Generated at: 2026-07-30T10:23:00.585Z
+ * Generated at: 2026-07-31T10:00:51.580Z
  */
 
 export interface DocEntry {
@@ -32,11 +32,11 @@ export const docs: Record<string, DocEntry> = {
   },
   "contributing": {
     title: "Contributing to The Codegen Project",
-    content: "# Contributing to The Codegen Project\n\n<!-- toc is generated with GitHub Actions do not remove toc markers -->\n\n<!-- toc -->\n\n- [Acceptance criteria and process](#acceptance-criteria-and-process)\n  * [Fixing bugs](#fixing-bugs)\n  * [New features](#new-features)\n- [Repository Architecture](#repository-architecture)\n- [Getting started](#getting-started)\n- [Contribution recogniton](#contribution-recogniton)\n- [Summary of the contribution flow](#summary-of-the-contribution-flow)\n- [Code of Conduct](#code-of-conduct)\n- [Our Development Process](#our-development-process)\n- [Pull Requests](#pull-requests)\n- [Conventional commits](#conventional-commits)\n\n<!-- tocstop -->\n\nFirst of all, thank you 🙇🏾‍♀️ for considering contributing to The Codegen Project\n\nIf you have any questions, are unsure how your use-case fits in, or want something clarified, don't hesitate to reach out, we are always happy to help out!\n\n## Acceptance criteria and process\n\nEven though we love contributions, we need to maintain a certain standard of what can be merged into the codebase. \n\nThe below sections provide information about our acceptance criteria, based on the type of contribution you make.\n\n### Fixing bugs \n\nThe Acceptance Criteria for _fixing any bug_ means that you should be able to reproduce the error using tests that will fail, unless a fix is implemented.\n\n### New features\n\nThe Acceptance Criteria for _adding new features_ requires a few things in order to be accepted. This ensures all features are well described and implemented before being released.\n\n1. **Not all feature requests from the community (or maintainers!) are accepted:** Even though you are welcome to create a new feature without an issue, it might be rejected and turn out to be a waste of your time. We don't want that to happen, so make sure to create an issue first and wait to see if it's accepted after community discussion of the proposal.\n1. **When creating tests for your new feature, aim for as high coverage numbers as possible:** When you run the tests (`npm run test`), you should see a `./coverage/lcov-report/index.html` file being generated. Use this to see in depth where your tests are not covering your implementation.\n1. **No documentation, no feature:** If a user cannot understand a new feature, that feature basically doesn't exist! Remember to make sure that any and all relevant [documentation](./) is consistently updated.\n    - New features such as new generators or inputs, etc, need associated use case documentation along side [examples](../examples).\n\n## Repository Architecture\n\nThe repository is setup with multiple functions to keep it simple.\n- `src`; includes the CLI and library code both exposed through the same package.\n- `website`; is... Well the website.\n- `scripts`; includes helpfull scripts for the release flow such as for building JSON Schema files from the code for configuration validation and CLI release configurations\n- `test`; include all the testing done for the repository\n    - `blackbox`; is a quick and dirt syntax testing of different configurations against different inputs to quickly detect problems\n    - `runtime`; is sematic testing of the generated code in the corresponding languages they generate for, ensuring correct behaviour at runtime\n    - The rest normal unit and integration testing of the actual CLI and library\n- `examples`; is the showcase of actual projects using the CLI to simplify the implementation phase of software development.\n- `schemas`; is the autogenerated JSON schemas for validating configurations.\n\n## Getting started\n\nHere is a quick litle get started quick tutorial;\n\n1. Fork the repository\n2. Create a branch from the upstream repository\n3. Install the dependencies `npm install`\n4. Make sure test pass `npm run test`\n5. Adapt the source code as well as test and documentation\n6. Push the changes\n7. Create a PR with the proposed change\n8. Get the change reviewed and merged :tada:\n\nHappy contributing :heart:\n\n## Contribution recogniton\n\nWe use [All Contributors](https://allcontributors.org/docs/en/specification) specification to handle recognitions.\n\n## Summary of the contribution flow\n\nThe following is a summary of the ideal contribution flow. Please, note that Pull Requests can also be rejected by the maintainers when appropriate.\n\n```\n    ┌───────────────────────┐\n    │                       │\n    │    Open an issue      │\n    │  (a bug report or a   │\n    │   feature request)    │\n    │                       │\n    └───────────────────────┘\n               ⇩\n    ┌───────────────────────┐\n    │                       │\n    │  Open a Pull Request  │\n    │   (only after issue   │\n    │     is approved)      │\n    │                       │\n    └───────────────────────┘\n               ⇩\n    ┌───────────────────────┐\n    │                       │\n    │   Your changes will   │\n    │     be merged and     │\n    │ published on the next │\n    │        release        │\n    │                       │\n    └───────────────────────┘\n```\n\n## Code of Conduct\nWe have adopted a Code of Conduct that we expect project participants to adhere to. Please [read the full text](https://github.com/the-codegen-project/cli/blob/main/CODE_OF_CONDUCT.md) so that you can understand what sort of behaviour is expected.\n\n## Our Development Process\nWe use Github to host code, to track issues and feature requests, as well as accept pull requests.\n\n## Pull Requests\n\n**Please, make sure you open an issue before starting with a Pull Request, unless it's a typo or a really obvious error.** Pull requests are the best way to propose changes to the specification. \n\n## Conventional commits\n\nOur repositories follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) specification. Releasing to GitHub and NPM is done with the support of [semantic-release](https://semantic-release.gitbook.io/semantic-release/).\n\nPull requests should have a title that follows the specification, otherwise, merging is blocked. If you are not familiar with the specification simply ask maintainers to modify. You can also use this cheatsheet if you want:\n\n- `fix: ` prefix in the title indicates that PR is a bug fix and PATCH release must be triggered.\n- `feat: ` prefix in the title indicates that PR is a feature and MINOR release must be triggered.\n- `docs: ` prefix in the title indicates that PR is only related to the documentation and there is no need to trigger release.\n- `chore: ` prefix in the title indicates that PR is only related to cleanup in the project and there is no need to trigger release.\n- `test: ` prefix in the title indicates that PR is only related to tests and there is no need to trigger release.\n- `refactor: ` prefix in the title indicates that PR is only related to refactoring and there is no need to trigger release.\n\nWhat about MAJOR release? just add `!` to the prefix, like `fix!: ` or `refactor!: `\n\nPrefix that follows specification is not enough though. Remember that the title must be clear and descriptive with usage of [imperative mood](https://chris.beams.io/posts/git-commit/#imperative).",
+    content: "# Contributing to The Codegen Project\n\n<!-- toc is generated with GitHub Actions do not remove toc markers -->\n\n<!-- toc -->\n\n- [Acceptance criteria and process](#acceptance-criteria-and-process)\n  * [Fixing bugs](#fixing-bugs)\n  * [New features](#new-features)\n- [Repository Architecture](#repository-architecture)\n- [Getting started](#getting-started)\n- [Contribution recogniton](#contribution-recogniton)\n- [Summary of the contribution flow](#summary-of-the-contribution-flow)\n- [Code of Conduct](#code-of-conduct)\n- [Our Development Process](#our-development-process)\n- [Pull Requests](#pull-requests)\n- [Conventional commits](#conventional-commits)\n\n<!-- tocstop -->\n\nFirst of all, thank you 🙇🏾‍♀️ for considering contributing to The Codegen Project\n\nIf you have any questions, are unsure how your use-case fits in, or want something clarified, don't hesitate to reach out, we are always happy to help out!\n\n## Acceptance criteria and process\n\nEven though we love contributions, we need to maintain a certain standard of what can be merged into the codebase. \n\nThe below sections provide information about our acceptance criteria, based on the type of contribution you make.\n\n### Fixing bugs \n\nThe Acceptance Criteria for _fixing any bug_ means that you should be able to reproduce the error using tests that will fail, unless a fix is implemented.\n\n### New features\n\nThe Acceptance Criteria for _adding new features_ requires a few things in order to be accepted. This ensures all features are well described and implemented before being released.\n\n1. **Not all feature requests from the community (or maintainers!) are accepted:** Even though you are welcome to create a new feature without an issue, it might be rejected and turn out to be a waste of your time. We don't want that to happen, so make sure to create an issue first and wait to see if it's accepted after community discussion of the proposal.\n1. **When creating tests for your new feature, aim for as high coverage numbers as possible:** When you run the tests (`npm run test`), you should see a `./coverage/lcov-report/index.html` file being generated. Use this to see in depth where your tests are not covering your implementation.\n1. **No documentation, no feature:** If a user cannot understand a new feature, that feature basically doesn't exist! Remember to make sure that any and all relevant [documentation](./) is consistently updated.\n    - New features such as new generators or inputs, etc, need associated use case documentation along side [examples](https://github.com/the-codegen-project/cli/tree/main/examples).\n\n## Repository Architecture\n\nThe repository is setup with multiple functions to keep it simple.\n- `src`; includes the CLI and library code both exposed through the same package.\n- `website`; is... Well the website.\n- `scripts`; includes helpfull scripts for the release flow such as for building JSON Schema files from the code for configuration validation and CLI release configurations\n- `test`; include all the testing done for the repository\n    - `blackbox`; is a quick and dirt syntax testing of different configurations against different inputs to quickly detect problems\n    - `runtime`; is sematic testing of the generated code in the corresponding languages they generate for, ensuring correct behaviour at runtime\n    - The rest normal unit and integration testing of the actual CLI and library\n- `examples`; is the showcase of actual projects using the CLI to simplify the implementation phase of software development.\n- `schemas`; is the autogenerated JSON schemas for validating configurations.\n\n## Getting started\n\nHere is a quick litle get started quick tutorial;\n\n1. Fork the repository\n2. Create a branch from the upstream repository\n3. Install the dependencies `npm install`\n4. Make sure test pass `npm run test`\n5. Adapt the source code as well as test and documentation\n6. Push the changes\n7. Create a PR with the proposed change\n8. Get the change reviewed and merged :tada:\n\nHappy contributing :heart:\n\n## Contribution recogniton\n\nWe use [All Contributors](https://allcontributors.org/docs/en/specification) specification to handle recognitions.\n\n## Summary of the contribution flow\n\nThe following is a summary of the ideal contribution flow. Please, note that Pull Requests can also be rejected by the maintainers when appropriate.\n\n```\n    ┌───────────────────────┐\n    │                       │\n    │    Open an issue      │\n    │  (a bug report or a   │\n    │   feature request)    │\n    │                       │\n    └───────────────────────┘\n               ⇩\n    ┌───────────────────────┐\n    │                       │\n    │  Open a Pull Request  │\n    │   (only after issue   │\n    │     is approved)      │\n    │                       │\n    └───────────────────────┘\n               ⇩\n    ┌───────────────────────┐\n    │                       │\n    │   Your changes will   │\n    │     be merged and     │\n    │ published on the next │\n    │        release        │\n    │                       │\n    └───────────────────────┘\n```\n\n## Code of Conduct\nWe have adopted a Code of Conduct that we expect project participants to adhere to. Please [read the full text](https://github.com/the-codegen-project/cli/blob/main/CODE_OF_CONDUCT.md) so that you can understand what sort of behaviour is expected.\n\n## Our Development Process\nWe use Github to host code, to track issues and feature requests, as well as accept pull requests.\n\n## Pull Requests\n\n**Please, make sure you open an issue before starting with a Pull Request, unless it's a typo or a really obvious error.** Pull requests are the best way to propose changes to the specification. \n\n## Conventional commits\n\nOur repositories follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) specification. Releasing to GitHub and NPM is done with the support of [semantic-release](https://semantic-release.gitbook.io/semantic-release/).\n\nPull requests should have a title that follows the specification, otherwise, merging is blocked. If you are not familiar with the specification simply ask maintainers to modify. You can also use this cheatsheet if you want:\n\n- `fix: ` prefix in the title indicates that PR is a bug fix and PATCH release must be triggered.\n- `feat: ` prefix in the title indicates that PR is a feature and MINOR release must be triggered.\n- `docs: ` prefix in the title indicates that PR is only related to the documentation and there is no need to trigger release.\n- `chore: ` prefix in the title indicates that PR is only related to cleanup in the project and there is no need to trigger release.\n- `test: ` prefix in the title indicates that PR is only related to tests and there is no need to trigger release.\n- `refactor: ` prefix in the title indicates that PR is only related to refactoring and there is no need to trigger release.\n\nWhat about MAJOR release? just add `!` to the prefix, like `fix!: ` or `refactor!: `\n\nPrefix that follows specification is not enough though. Remember that the title must be clear and descriptive with usage of [imperative mood](https://chris.beams.io/posts/git-commit/#imperative).",
   },
   "generators": {
     title: "Generators",
-    content: "# Generators\nGenerators, or preset's are the core of **The Codegen Project**, that determines what is generated for your project.\n\nEach language and inputs have specific generators;\n\nAll available generators, across languages and inputs:\n- [`payloads`](./payloads.md)\n- [`parameters`](./parameters.md)\n- [`headers`](./headers.md)\n- [`types`](./types.md)\n- [`channels`](./channels.md)\n- [`client`](./client.md)\n- [`models`](./models.md)\n- [`custom`](./custom.md)\n\n| **Inputs** | [`payloads`](./payloads.md) | [`parameters`](./parameters.md) | [`headers`](./headers.md) | [`types`](./types.md) | [`channels`](./channels.md) | [`client`](./client.md) | [`models`](./models.md) | [`custom`](./custom.md) |\n|---|---|---|---|---|---|---|---|---|\n| AsyncAPI | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |\n| OpenAPI | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |\n| JSON Schema | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ |\n\n> OpenAPI `channels` and `client` generate an HTTP client — see the [`openapi-http-client` example](../../examples/openapi-http-client/).\n\n| **Languages** | [`payloads`](./payloads.md) | [`parameters`](./parameters.md) | [`headers`](./headers.md) | [`types`](./types.md) | [`channels`](./channels.md) | [`client`](./client.md) | [`models`](./models.md) | [`custom`](./custom.md) |\n|---|---|---|---|---|---|---|---|---|\n| TypeScript | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |",
+    content: "# Generators\nGenerators, or preset's are the core of **The Codegen Project**, that determines what is generated for your project.\n\nEach language and inputs have specific generators;\n\nAll available generators, across languages and inputs:\n- [`payloads`](./payloads.md)\n- [`parameters`](./parameters.md)\n- [`headers`](./headers.md)\n- [`types`](./types.md)\n- [`channels`](./channels.md)\n- [`client`](./client.md)\n- [`models`](./models.md)\n- [`custom`](./custom.md)\n\n| **Inputs** | [`payloads`](./payloads.md) | [`parameters`](./parameters.md) | [`headers`](./headers.md) | [`types`](./types.md) | [`channels`](./channels.md) | [`client`](./client.md) | [`models`](./models.md) | [`custom`](./custom.md) |\n|---|---|---|---|---|---|---|---|---|\n| AsyncAPI | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |\n| OpenAPI | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |\n| JSON Schema | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ |\n\n> OpenAPI `channels` and `client` generate an HTTP client — see the [`openapi-http-client` example](https://github.com/the-codegen-project/cli/tree/main/examples/openapi-http-client).\n\n| **Languages** | [`payloads`](./payloads.md) | [`parameters`](./parameters.md) | [`headers`](./headers.md) | [`types`](./types.md) | [`channels`](./channels.md) | [`client`](./client.md) | [`models`](./models.md) | [`custom`](./custom.md) |\n|---|---|---|---|---|---|---|---|---|\n| TypeScript | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |",
   },
   "generators/channels": {
     title: "Channels",
@@ -48,7 +48,7 @@ export const docs: Record<string, DocEntry> = {
   },
   "generators/custom": {
     title: "Custom generator",
-    content: "# Custom generator\n\nThis generator is simple, it's a callback that enable you to write any file or do any operation in the code generation process. This preset is available for all languages.\n\n## Imports\n\nThe dependencies you have access to is any native `node` dependency and all dependencies listed in [The Codegen Project](https://github.com/the-codegen-project/cli/blob/8b8fa6f0c5b0c0c63515a8ca439f72872815f491/package.json#L9). Here is an example:\n\n```ts\nimport { JavaFileGenerator } from \"@asyncapi/modelina\";\nexport default {\n  ...\n  generators: [\n    {\n      preset: 'custom',\n      ...\n      renderFunction: ({generator, inputType, asyncapiDocument, openapiDocument, jsonSchemaDocument, dependencyOutputs}) => {\n        const modelinaGenerator = new JavaFileGenerator({});\n        modelinaGenerator.generateCompleteModels(...)\n      }\n    }\n  ]\n};\n```\n\n# Dependencies\n\nIn each generator (don't manually use it unless you use `preset: custom`), you can add `dependencies` property, which takes an array of `id`'s that the rendering engine ensures are rendered before the dependant one. \n\nEach generator has a specific output (except `custom` which is dynamic and under your control), they are documented under each [./generators](./README.md). These outputs can be accessed under `dependencyOutputs`.\n\nThere are two rules though;\n\n1. You are not allowed to have circular dependencies, i.e. two generators both depending on each other.\n2. You are not allowed to have self-dependant generators\n\n## How does it work?\n\nFor example, take two generators, you can chain them together and use one's output in the other, as for example below, to have the console print out `Hello World!`.\n```js\nexport default {\n  ...\n  generators: [\n    {\n      preset: 'custom',\n      renderFunction: ({dependencyOutputs}) => {\n        console.log(dependencyOutputs['bar'])\n      },\n      dependencies: ['bar']\n    },\n    {\n      preset: 'custom',\n      id: 'bar',\n      renderFunction: () => {\n        return 'Hello World!'\n      }\n    }\n  ]\n};\n```\n\n## Arguments\nIn the `renderFunction` you have access to a bunch of arguments to help you create the callback;\n\n- `generator` - is the generator configuration, where you have access to the `options` and all other information.\n- `inputType` - is the root `inputType` for the input document\n- `asyncapiDocument` - is the parsed AsyncAPI document input (according to the [AsyncAPI parser](https://github.com/asyncapi/parser-js/)), undefined if the `inputType` is not `asyncapi`\n- `openapiDocument` - is the parsed OpenAPI document input (according to the [readme/openapi-parser](https://github.com/readmeio/oas)), undefined if the `inputType` is not `openapi`\n- `jsonSchemaDocument` - is the parsed JSON Schema document input, undefined if the `inputType` is not `jsonschema`\n- `dependencyOutputs` - if you have defined any `dependencies`, this is where you can access the output. Checkout the [dependency documentation](#dependencies) for more information.",
+    content: "# Custom generator\n\nThis generator is simple, it's a callback that enable you to write any file or do any operation in the code generation process. This preset is available for all languages.\n\n## Imports\n\nThe dependencies you have access to is any native `node` dependency and all dependencies listed in [The Codegen Project](https://github.com/the-codegen-project/cli/blob/8b8fa6f0c5b0c0c63515a8ca439f72872815f491/package.json#L9). Here is an example:\n\n```ts\nimport { JavaFileGenerator } from \"@asyncapi/modelina\";\nexport default {\n  ...\n  generators: [\n    {\n      preset: 'custom',\n      ...\n      renderFunction: ({generator, inputType, asyncapiDocument, openapiDocument, jsonSchemaDocument, dependencyOutputs}) => {\n        const modelinaGenerator = new JavaFileGenerator({});\n        modelinaGenerator.generateCompleteModels(...)\n      }\n    }\n  ]\n};\n```\n\n## Dependencies\n\nIn each generator (don't manually use it unless you use `preset: custom`), you can add `dependencies` property, which takes an array of `id`'s that the rendering engine ensures are rendered before the dependant one. \n\nEach generator has a specific output (except `custom` which is dynamic and under your control), they are documented under each [./generators](./README.md). These outputs can be accessed under `dependencyOutputs`.\n\nThere are two rules though;\n\n1. You are not allowed to have circular dependencies, i.e. two generators both depending on each other.\n2. You are not allowed to have self-dependant generators\n\n## How does it work?\n\nFor example, take two generators, you can chain them together and use one's output in the other, as for example below, to have the console print out `Hello World!`.\n```js\nexport default {\n  ...\n  generators: [\n    {\n      preset: 'custom',\n      renderFunction: ({dependencyOutputs}) => {\n        console.log(dependencyOutputs['bar'])\n      },\n      dependencies: ['bar']\n    },\n    {\n      preset: 'custom',\n      id: 'bar',\n      renderFunction: () => {\n        return 'Hello World!'\n      }\n    }\n  ]\n};\n```\n\n## Arguments\nIn the `renderFunction` you have access to a bunch of arguments to help you create the callback;\n\n- `generator` - is the generator configuration, where you have access to the `options` and all other information.\n- `inputType` - is the root `inputType` for the input document\n- `asyncapiDocument` - is the parsed AsyncAPI document input (according to the [AsyncAPI parser](https://github.com/asyncapi/parser-js/)), undefined if the `inputType` is not `asyncapi`\n- `openapiDocument` - is the parsed OpenAPI document input (according to the [readme/openapi-parser](https://github.com/readmeio/oas)), undefined if the `inputType` is not `openapi`\n- `jsonSchemaDocument` - is the parsed JSON Schema document input, undefined if the `inputType` is not `jsonschema`\n- `dependencyOutputs` - if you have defined any `dependencies`, this is where you can access the output. Checkout the [dependency documentation](#dependencies) for more information.",
   },
   "generators/headers": {
     title: "Headers",
@@ -72,15 +72,15 @@ export const docs: Record<string, DocEntry> = {
   },
   "getting-started": {
     title: "Getting Started",
-    content: "# Getting Started\n\nIts simple, [install the CLI](#install) into your project or machine, [setup the Codegen configuration file](#initialize) to include all the code your heart desire, customize it, and generate it at build time or whenever you feel like it.\n\n## Install\nInstalling the CLI can be done inside a project or within your system.\n\n<table>\n  <tr>\n    <th>Package manager</th>\n    <th>MacOS x64</th>\n    <th>MacOS arm64</th>\n    <th>Windows x64</th>\n    <th>Windows x32</th>\n    <th>Linux (Debian)</th>\n    <th>Linux (Others)</th>\n  </tr>\n  <tr>\n    <td>\n      <div>\n\n#### NPM\n\n```sh\nnpm install --save-dev @the-codegen-project/cli\n\nnpm install -g @the-codegen-project/cli\n```\n\n#### Yarn\n\n```sh\nyarn add @the-codegen-project/cli\n```\n\n#### Pnpm\n\n```sh\npnpm add @the-codegen-project/cli\n```\n\n#### Bun\n\n```sh\nbun add @the-codegen-project/cli\n```\n\n</div>\n    </td>\n    <td>\n      <div>\n\n#### Download\n```sh\ncurl -OL https://github.com/the-codegen-project/cli/releases/latest/download/codegen.x64.pkg\n```\n\n#### Install\n```sh\nsudo installer -pkg codegen.x64.pkg -target /\n```\n\n</div>\n    </td>\n    <td>\n      <div>\n\n#### Download\n```sh\ncurl -OL https://github.com/the-codegen-project/cli/releases/latest/download/codegen.arm64.pkg\n```\n#### Install\n\n```sh\nsudo installer -pkg codegen.arm64.pkg -target /\n```\n</div>\n    </td>\n    <td>\n      <div>\n<a href=\"https://github.com/the-codegen-project/cli/releases/latest/download/codegen.x64.exe\">Download and run codegen.x64.exe</a>\n</div>\n    </td>\n    <td>\n      <div>\n<a href=\"https://github.com/the-codegen-project/cli/releases/latest/download/codegen.x86.exe\">Download and run codegen.x86.exe</a>\n</div>\n    </td>\n    <td>\n      <div>\n\n#### Download\n```sh\ncurl -OL https://github.com/the-codegen-project/cli/releases/latest/download/codegen.deb\n```\n\n#### Install\n```sh\nsudo apt install ./codegen.deb\n```\n</div>\n    </td>\n    <td>\n      <div>\n\n#### Download\n```sh\ncurl -OL https://github.com/the-codegen-project/cli/releases/latest/download/codegen.tar.gz\n```\n\n#### Install\n\n```sh\ntar -xzf codegen.tar.gz\n```\n\n#### Symlink\n```sh\nln -s <absolute-path>/bin/codegen /usr/local/bin/codegen\n```\n\n</div>\n    </td>\n  </tr>\n</table>\n\nYou can find all the possible commands in [the usage documentation](../usage.md).\n\n## Initialize\nAdd a configuration file, either manually or through the CLI;\n```sh\ncodegen init\n```\n\nFor non-interactive/CI use, pass the generators explicitly (the `languages` flag defaults to `typescript`), for example:\n```sh\ncodegen init --no-tty --input-type asyncapi --input-file ./asyncapi.yml \\\n  --include-payloads --include-channels --channels-protocols nats\n```\nAt least one generator must be selected — `codegen init` exits with an error rather than writing a configuration that would generate nothing. For AsyncAPI `channels`/`client`, choose the messaging protocols with `--channels-protocols` (repeatable). See [the usage documentation](../usage.md#codegen-init) for the full flag list.\n\n<div align=\"center\">\n\n\n![Initialize The Codegen Project](../../static/assets/videos/initialize.gif)\n\nCustomize it to your heart's desire! [Each generator has unique set of options](../generators/README.md)\n\n</div>\n\n## Integrate\nWith your configuration file in hand, time to integrate it into your project and generate some code!  Checkout [all the integrations](../../examples/) for inspiration how to do it.\n\n### Generate Code\n\n#### One-time Generation\n```sh\n# Generate code once\ncodegen generate\n\n# Generate with specific config file\ncodegen generate ./my-config.js\n```\n\n#### Development with Watch Mode\nFor active development, use watch mode to automatically regenerate code when your input files change:\n\n```sh\n# Watch for changes in the input file specified in your config\ncodegen generate --watch\n\n# Watch for changes in a specific file or directory\ncodegen generate --watch --watchPath ./my-asyncapi.yaml\n\n# Short form\ncodegen generate -w -p ./schemas/\n```\n\n**Pro tip:** Use watch mode during development to keep your generated code in sync with your API specifications. Press `Ctrl+C` to stop watching.\n\n## What's Next?\n\nNow that you've installed the CLI and generated your first code, here's where to go next:\n\n### Understanding Generators\nLearn how generators work and what they can do for your project. Generators are the core of The Codegen Project - they determine what code gets generated from your API specifications.\n\n👉 **[Learn about Generators →](./generators.md)**\n\n### Protocol Support\nDiscover how The Codegen Project supports various messaging protocols like NATS, Kafka, MQTT, and more. Understand how protocol-specific code generation works and which protocols are available.\n\n👉 **[Learn about Protocol Support →](./protocols.md)**\n\n### Explore Further\n- **[Generator Documentation](../generators/README.md)** - Detailed documentation for each generator type\n- **[Protocol Documentation](../protocols/)** - Complete protocol reference and implementation details\n- **[Input Types](../inputs/)** - Learn about AsyncAPI, OpenAPI, and JSON Schema support\n- **[Examples](../../examples/)** - Real-world examples and integration patterns",
+    content: "# Getting Started\n\nIts simple, [install the CLI](#install) into your project or machine, [setup the Codegen configuration file](#initialize) to include all the code your heart desire, customize it, and generate it at build time or whenever you feel like it.\n\n## Install\nInstalling the CLI can be done inside a project or within your system.\n\n<table>\n  <tr>\n    <th>Package manager</th>\n    <th>MacOS x64</th>\n    <th>MacOS arm64</th>\n    <th>Windows x64</th>\n    <th>Windows x32</th>\n    <th>Linux (Debian)</th>\n    <th>Linux (Others)</th>\n  </tr>\n  <tr>\n    <td>\n      <div>\n\n#### NPM\n\n```sh\nnpm install --save-dev @the-codegen-project/cli\n\nnpm install -g @the-codegen-project/cli\n```\n\n#### Yarn\n\n```sh\nyarn add @the-codegen-project/cli\n```\n\n#### Pnpm\n\n```sh\npnpm add @the-codegen-project/cli\n```\n\n#### Bun\n\n```sh\nbun add @the-codegen-project/cli\n```\n\n</div>\n    </td>\n    <td>\n      <div>\n\n#### Download\n```sh\ncurl -OL https://github.com/the-codegen-project/cli/releases/latest/download/codegen.x64.pkg\n```\n\n#### Install\n```sh\nsudo installer -pkg codegen.x64.pkg -target /\n```\n\n</div>\n    </td>\n    <td>\n      <div>\n\n#### Download\n```sh\ncurl -OL https://github.com/the-codegen-project/cli/releases/latest/download/codegen.arm64.pkg\n```\n#### Install\n\n```sh\nsudo installer -pkg codegen.arm64.pkg -target /\n```\n</div>\n    </td>\n    <td>\n      <div>\n<a href=\"https://github.com/the-codegen-project/cli/releases/latest/download/codegen.x64.exe\">Download and run codegen.x64.exe</a>\n</div>\n    </td>\n    <td>\n      <div>\n<a href=\"https://github.com/the-codegen-project/cli/releases/latest/download/codegen.x86.exe\">Download and run codegen.x86.exe</a>\n</div>\n    </td>\n    <td>\n      <div>\n\n#### Download\n```sh\ncurl -OL https://github.com/the-codegen-project/cli/releases/latest/download/codegen.deb\n```\n\n#### Install\n```sh\nsudo apt install ./codegen.deb\n```\n</div>\n    </td>\n    <td>\n      <div>\n\n#### Download\n```sh\ncurl -OL https://github.com/the-codegen-project/cli/releases/latest/download/codegen.tar.gz\n```\n\n#### Install\n\n```sh\ntar -xzf codegen.tar.gz\n```\n\n#### Symlink\n```sh\nln -s <absolute-path>/bin/codegen /usr/local/bin/codegen\n```\n\n</div>\n    </td>\n  </tr>\n</table>\n\nYou can find all the possible commands in [the usage documentation](../usage.md).\n\n## Initialize\nAdd a configuration file, either manually or through the CLI;\n```sh\ncodegen init\n```\n\nFor non-interactive/CI use, pass the generators explicitly (the `languages` flag defaults to `typescript`), for example:\n```sh\ncodegen init --no-tty --input-type asyncapi --input-file ./asyncapi.yml \\\n  --include-payloads --include-channels --channels-protocols nats\n```\nAt least one generator must be selected — `codegen init` exits with an error rather than writing a configuration that would generate nothing. For AsyncAPI `channels`/`client`, choose the messaging protocols with `--channels-protocols` (repeatable). See [the usage documentation](../usage.md#codegen-init) for the full flag list.\n\n<div align=\"center\">\n\n\n![Initialize The Codegen Project](../../static/assets/videos/initialize.gif)\n\nCustomize it to your heart's desire! [Each generator has unique set of options](../generators/README.md)\n\n</div>\n\n## Integrate\nWith your configuration file in hand, time to integrate it into your project and generate some code!  Checkout [all the integrations](https://github.com/the-codegen-project/cli/tree/main/examples) for inspiration how to do it.\n\n### Generate Code\n\n#### One-time Generation\n```sh\n# Generate code once\ncodegen generate\n\n# Generate with specific config file\ncodegen generate ./my-config.js\n```\n\n#### Development with Watch Mode\nFor active development, use watch mode to automatically regenerate code when your input files change:\n\n```sh\n# Watch for changes in the input file specified in your config\ncodegen generate --watch\n\n# Watch for changes in a specific file or directory\ncodegen generate --watch --watchPath ./my-asyncapi.yaml\n\n# Short form\ncodegen generate -w -p ./schemas/\n```\n\n**Pro tip:** Use watch mode during development to keep your generated code in sync with your API specifications. Press `Ctrl+C` to stop watching.\n\n## What's Next?\n\nNow that you've installed the CLI and generated your first code, here's where to go next:\n\n### Understanding Generators\nLearn how generators work and what they can do for your project. Generators are the core of The Codegen Project - they determine what code gets generated from your API specifications.\n\n👉 **[Learn about Generators →](./generators.md)**\n\n### Protocol Support\nDiscover how The Codegen Project supports various messaging protocols like NATS, Kafka, MQTT, and more. Understand how protocol-specific code generation works and which protocols are available.\n\n👉 **[Learn about Protocol Support →](./protocols.md)**\n\n### Explore Further\n- **[Generator Documentation](../generators/README.md)** - Detailed documentation for each generator type\n- **[Protocol Documentation](../protocols/)** - Complete protocol reference and implementation details\n- **[Input Types](../inputs/)** - Learn about AsyncAPI, OpenAPI, and JSON Schema support\n- **[Examples](https://github.com/the-codegen-project/cli/tree/main/examples)** - Real-world examples and integration patterns",
   },
   "getting-started/generators": {
     title: "Understanding Generators",
-    content: "# Understanding Generators\n\nGenerators (also called \"presets\") are the core of **The Codegen Project**. They determine what code gets generated from your inputs. Think of generators as specialized code factories - each one produces a specific type of code that helps you build your application faster.\n\n## What Generators do you have?\n\nEach generator focuses on a specific aspect of your application:\n\n### Model Generators\nThese generators create data models and type definitions:\n\n- [`payloads` preset](../generators/payloads.md) - Type-safe message/payload classes with serialization and validation support\n- [`parameters` preset](../generators/parameters.md) - Type-safe parameter classes for API endpoints that make it easier to work with topics/paths/channels\n- [`headers` preset](../generators/headers.md) - Type-safe header classes for message protocols, with serialization and validation support\n- [`types` preset](../generators/types.md) - Shared type definitions and interfaces, which simplify your code in various ways\n- [`models` preset](../generators/models.md) - General-purpose models from JSON Schema\n\n### Communication Generators\nThese generators create code for interacting with APIs and message brokers:\n\n- [`channels` preset](../generators/channels.md) - Communication functions for message brokers, ensure the right message, headers, and topics/paths/channels are used\n- [`client` preset](../generators/client.md) - Wraps channels into a reusable wrappers, cant get more code then this.\n\n### Custom Generators\n- [`custom` preset](../generators/custom.md) - Your own custom code generation logic\n\n## How Generators Work\n\n### 1. Input Processing\nGenerators take your specifications (AsyncAPI, OpenAPI, or JSON Schema) and extract the relevant information:\n\n```js\nexport default {\n  inputType: 'asyncapi',\n  inputPath: './my-api.yaml',\n  generators: [\n    { preset: 'payloads', outputPath: './src/__gen__/payloads' }\n  ]\n};\n```\n\n### 2. Code Generation\nBased on the generator configuration, The Codegen Project:\n- Parses your API specification\n- Extracts schemas, operations, channels, and other relevant data\n- Use whatever generators you added and outputs files to your specified directory\n\n```js\nexport default {\n  inputType: 'asyncapi',\n  inputPath: './my-api.yaml',\n  generators: [\n    {\n      preset: 'payloads',\n      outputPath: './src/payloads',\n      language: 'typescript'\n    }\n  ]\n};\n```\n\n### 3. Generated Output\nEach generator produces different code, so have a look at each generator to get a full picture, but here is a few examples:\n\n**Payload Generator** produces:\n```typescript\n// A companion interface is exported alongside the class, so you can construct\n// a payload from a plain object.\nexport interface UserSignupInterface { /* ... */ }\nexport class UserSignup {\n  constructor(input: UserSignupInterface) { /* ... */ }\n  marshal(): string { /* ... */ }\n  static unmarshal(json: string | object): UserSignup { /* ... */ }\n}\n```\n\n**Channels Generator** produces:\n```typescript\n// One module per protocol, re-exported from the generated barrel file\nimport * as nats from './nats';\nimport * as kafka from './kafka';\n\nexport { nats, kafka };\n\n// nats.publishToUserSignup({ message, nc })\n// nats.subscribeToUserSignup({ onDataCallback, nc })\n// nats.jetStreamPublishToUserSignup({ message, js })\n// kafka.produceToUserSignup({ message, kafka })\n// kafka.consumeFromUserSignup({ onDataCallback, kafka, options })\n```\n\n## Input Type Support\n\nDifferent generators work with different input types:\n\n| Generator | AsyncAPI | OpenAPI | JSON Schema |\n|-----------|----------|---------|-------------|\n| `payloads` | ✅ | ✅ | ❌ |\n| `parameters` | ✅ | ✅ | ❌ |\n| `headers` | ✅ | ✅ | ❌ |\n| `types` | ✅ | ✅ | ❌ |\n| `channels` | ✅ | ✅ | ❌ |\n| `client` | ✅ | ✅ | ❌ |\n| `models` | ✅ | ✅ | ✅ |\n| `custom` | ✅ | ✅ | ✅ |\n\n## Language Support\n\nCurrently, The Codegen Project supports:\n\n- **TypeScript** - Full support for all generators\n\nEach language has specific capabilities and constraints. Check the [generator documentation](../generators/README.md) for details.\n\n## Generator Dependencies\n\nSome generators automatically include dependencies on others:\n\n- **`channels`** generator automatically uses `payloads`, `headers`, and `parameters` generators if they're not already configured\n- This ensures you have all the necessary models and types for your channel functions\n\n## Configuration Options\n\nEach generator has its own set of configuration options, for example here is payloads:\n\n```js\nexport default {\n  inputType: 'asyncapi',\n  inputPath: './my-api.yaml',\n  generators: [\n    {\n      preset: 'payloads',\n      outputPath: './src/payloads',\n      language: 'typescript',\n      includeValidation: true,\n      serializationType: 'json'\n    }\n  ]\n};\n```\n\n## Next Steps\n\n- **[Explore Generator Documentation](../generators/README.md)** - Detailed docs for each generator\n- **[Learn about Protocol Support](./protocols.md)** - How generators work with messaging protocols\n- **[Check Out Examples](../../examples/)** - See generators in action",
+    content: "# Understanding Generators\n\nGenerators (also called \"presets\") are the core of **The Codegen Project**. They determine what code gets generated from your inputs. Think of generators as specialized code factories - each one produces a specific type of code that helps you build your application faster.\n\n## What Generators do you have?\n\nEach generator focuses on a specific aspect of your application:\n\n### Model Generators\nThese generators create data models and type definitions:\n\n- [`payloads` preset](../generators/payloads.md) - Type-safe message/payload classes with serialization and validation support\n- [`parameters` preset](../generators/parameters.md) - Type-safe parameter classes for API endpoints that make it easier to work with topics/paths/channels\n- [`headers` preset](../generators/headers.md) - Type-safe header classes for message protocols, with serialization and validation support\n- [`types` preset](../generators/types.md) - Shared type definitions and interfaces, which simplify your code in various ways\n- [`models` preset](../generators/models.md) - General-purpose models from JSON Schema\n\n### Communication Generators\nThese generators create code for interacting with APIs and message brokers:\n\n- [`channels` preset](../generators/channels.md) - Communication functions for message brokers, ensure the right message, headers, and topics/paths/channels are used\n- [`client` preset](../generators/client.md) - Wraps channels into a reusable wrappers, cant get more code then this.\n\n### Custom Generators\n- [`custom` preset](../generators/custom.md) - Your own custom code generation logic\n\n## How Generators Work\n\n### 1. Input Processing\nGenerators take your specifications (AsyncAPI, OpenAPI, or JSON Schema) and extract the relevant information:\n\n```js\nexport default {\n  inputType: 'asyncapi',\n  inputPath: './my-api.yaml',\n  generators: [\n    { preset: 'payloads', outputPath: './src/__gen__/payloads' }\n  ]\n};\n```\n\n### 2. Code Generation\nBased on the generator configuration, The Codegen Project:\n- Parses your API specification\n- Extracts schemas, operations, channels, and other relevant data\n- Use whatever generators you added and outputs files to your specified directory\n\n```js\nexport default {\n  inputType: 'asyncapi',\n  inputPath: './my-api.yaml',\n  generators: [\n    {\n      preset: 'payloads',\n      outputPath: './src/payloads',\n      language: 'typescript'\n    }\n  ]\n};\n```\n\n### 3. Generated Output\nEach generator produces different code, so have a look at each generator to get a full picture, but here is a few examples:\n\n**Payload Generator** produces:\n```typescript\n// A companion interface is exported alongside the class, so you can construct\n// a payload from a plain object.\nexport interface UserSignupInterface { /* ... */ }\nexport class UserSignup {\n  constructor(input: UserSignupInterface) { /* ... */ }\n  marshal(): string { /* ... */ }\n  static unmarshal(json: string | object): UserSignup { /* ... */ }\n}\n```\n\n**Channels Generator** produces:\n```typescript\n// One module per protocol, re-exported from the generated barrel file\nimport * as nats from './nats';\nimport * as kafka from './kafka';\n\nexport { nats, kafka };\n\n// nats.publishToUserSignup({ message, nc })\n// nats.subscribeToUserSignup({ onDataCallback, nc })\n// nats.jetStreamPublishToUserSignup({ message, js })\n// kafka.produceToUserSignup({ message, kafka })\n// kafka.consumeFromUserSignup({ onDataCallback, kafka, options })\n```\n\n## Input Type Support\n\nDifferent generators work with different input types:\n\n| Generator | AsyncAPI | OpenAPI | JSON Schema |\n|-----------|----------|---------|-------------|\n| `payloads` | ✅ | ✅ | ❌ |\n| `parameters` | ✅ | ✅ | ❌ |\n| `headers` | ✅ | ✅ | ❌ |\n| `types` | ✅ | ✅ | ❌ |\n| `channels` | ✅ | ✅ | ❌ |\n| `client` | ✅ | ✅ | ❌ |\n| `models` | ✅ | ✅ | ✅ |\n| `custom` | ✅ | ✅ | ✅ |\n\n## Language Support\n\nCurrently, The Codegen Project supports:\n\n- **TypeScript** - Full support for all generators\n\nEach language has specific capabilities and constraints. Check the [generator documentation](../generators/README.md) for details.\n\n## Generator Dependencies\n\nSome generators automatically include dependencies on others:\n\n- **`channels`** generator automatically uses `payloads`, `headers`, and `parameters` generators if they're not already configured\n- This ensures you have all the necessary models and types for your channel functions\n\n## Configuration Options\n\nEach generator has its own set of configuration options, for example here is payloads:\n\n```js\nexport default {\n  inputType: 'asyncapi',\n  inputPath: './my-api.yaml',\n  generators: [\n    {\n      preset: 'payloads',\n      outputPath: './src/payloads',\n      language: 'typescript',\n      includeValidation: true,\n      serializationType: 'json'\n    }\n  ]\n};\n```\n\n## Next Steps\n\n- **[Explore Generator Documentation](../generators/README.md)** - Detailed docs for each generator\n- **[Learn about Protocol Support](./protocols.md)** - How generators work with messaging protocols\n- **[Check Out Examples](https://github.com/the-codegen-project/cli/tree/main/examples)** - See generators in action",
   },
   "getting-started/protocols": {
     title: "Understanding Protocols",
-    content: "# Understanding Protocols\n\nThe Codegen Project supports multiple messaging protocols, allowing you to generate protocol-specific code for your message-driven applications. This enables type-safe, production-ready communication code for various messaging systems.\n\n## What Are Protocols?\n\nProtocols define how messages are sent and received in distributed systems. The Codegen Project generates protocol-specific functions that handle the low-level details of message communication, so you can focus on your business logic.\n\n## Supported Protocols\n\nThe Codegen Project currently supports these messaging protocols:\n\n| Protocol | Description | Use Cases |\n|----------|-------------|-----------|\n| **[NATS](../protocols/nats.md)** | High-performance, cloud-native messaging system | Microservices, real-time systems, IoT |\n| **[Kafka](../protocols/kafka.md)** | Distributed event streaming platform | Event streaming, log aggregation, real-time analytics |\n| **[MQTT](../protocols/mqtt.md)** | Lightweight messaging protocol for IoT | IoT devices, mobile apps, low-bandwidth scenarios |\n| **[AMQP](../protocols/amqp.md)** | Advanced Message Queuing Protocol | Enterprise messaging, reliable message delivery |\n| **[EventSource](../protocols/eventsource.md)** | Server-Sent Events (SSE) protocol | Real-time web updates, streaming data to browsers |\n| **[HTTP Client](../protocols/http_client.md)** | RESTful API communication | HTTP APIs, REST services |\n| **[WebSocket](../protocols/websocket.md)** | Full-duplex communication protocol | Real-time web applications, bidirectional communication |\n\n## How Protocol Support Works\nEach protocol usually requires specific dependencies and should be installed in your project (if its noy already are). Make sure to check the documentation for each protocol to figure out which one you need!\n\n### 1. Protocol Configuration\n\nProtocols are configured through the [`channels`](../generators/channels.md) generator:\n\n```js\nexport default {\n  inputType: 'asyncapi',\n  inputPath: './my-api.yaml',\n  generators: [\n    {\n      preset: 'channels',\n      outputPath: './src/__gen__/',\n      language: 'typescript',\n      protocols: ['nats', 'kafka'] // Specify which protocols to generate\n    }\n  ]\n};\n```\n\n### 2. Generated Protocol Functions\n\nThe `channels` generator creates protocol-specific functions for each channel in your AsyncAPI specification:\n\nEach protocol is exported as its own namespace from the generated barrel file,\nand every generated function takes a single object argument:\n\n```typescript\nimport { nats, kafka } from './src/__gen__/channels';\n\n// NATS functions\nawait nats.publishToUserSignup({ message, nc: connection });\nawait nats.subscribeToUserSignup({ onDataCallback: callback, nc: connection });\n\n// Kafka functions — note Kafka uses produceTo/consumeFrom\nawait kafka.produceToUserSignup({ message, kafka: kafkaClient });\nawait kafka.consumeFromUserSignup({\n  onDataCallback: callback,\n  kafka: kafkaClient,\n  options: { fromBeginning: true, groupId: 'my-group' }\n});\n```\n\nThe exact parameters depend on the channel — channels with parameters also take\n`parameters`, and channels with headers accept `headers`. See each protocol's\npage for the full generated signatures.\n\nEach protocol has unique features that are reflected in the generated code:\n\n**NATS** supports:\n- Core publish/subscribe\n- JetStream (persistent messaging)\n- Request/reply patterns\n\n**Kafka** supports:\n- Producer/consumer patterns\n- Consumer groups\n- Topic partitioning\n\n**MQTT** supports:\n- QoS levels (0, 1, 2)\n- Retained messages\n- User properties (headers)\n\n**AMQP** supports:\n- Exchanges and queues\n- Routing patterns\n- Message acknowledgments\n\n## Protocol Selection\n\n### Single Protocol\nGenerate code for one protocol:\n\n```js\n{\n  preset: 'channels',\n  protocols: ['nats']\n}\n```\nor generate for multiple protocols at once:\n\n```js\n{\n  preset: 'channels',\n  protocols: ['nats', 'kafka', 'mqtt']\n}\n```\n\n\n## Protocol-Specific Options\n\nSome generators support protocol-specific configuration options:\n\n```js\n{\n  preset: 'channels',\n  protocols: ['kafka'],\n  kafkaTopicSeparator: '.', // Customize topic separator\n  eventSourceDependency: '@microsoft/fetch-event-source' // Custom EventSource dependency\n}\n```\n\n## Generated Code Structure\n\nProtocol functions are organized by protocol:\n\n```typescript\nexport const Protocols = {\n  nats: {\n    publishToUserSignup: ...,\n    subscribeToUserSignup: ...,\n    jetStreamPublishToUserSignup: ...\n  },\n  kafka: {\n    publishToUserSignup: ...,\n    subscribeToUserSignup: ...\n  },\n  // ... other protocols\n};\n```\n\n## Next Steps\n\n- **[Explore Protocol Documentation](../protocols/)** - Detailed docs for each protocol\n- **[Learn about Channels Generator](../generators/channels.md)** - How to configure protocol generation\n- **[Check Out Examples](../../examples/)** - See the code generation in action\n- **[Understanding Generators](./generators.md)** - Learn how generators work",
+    content: "# Understanding Protocols\n\nThe Codegen Project supports multiple messaging protocols, allowing you to generate protocol-specific code for your message-driven applications. This enables type-safe, production-ready communication code for various messaging systems.\n\n## What Are Protocols?\n\nProtocols define how messages are sent and received in distributed systems. The Codegen Project generates protocol-specific functions that handle the low-level details of message communication, so you can focus on your business logic.\n\n## Supported Protocols\n\nThe Codegen Project currently supports these messaging protocols:\n\n| Protocol | Description | Use Cases |\n|----------|-------------|-----------|\n| **[NATS](../protocols/nats.md)** | High-performance, cloud-native messaging system | Microservices, real-time systems, IoT |\n| **[Kafka](../protocols/kafka.md)** | Distributed event streaming platform | Event streaming, log aggregation, real-time analytics |\n| **[MQTT](../protocols/mqtt.md)** | Lightweight messaging protocol for IoT | IoT devices, mobile apps, low-bandwidth scenarios |\n| **[AMQP](../protocols/amqp.md)** | Advanced Message Queuing Protocol | Enterprise messaging, reliable message delivery |\n| **[EventSource](../protocols/eventsource.md)** | Server-Sent Events (SSE) protocol | Real-time web updates, streaming data to browsers |\n| **[HTTP Client](../protocols/http_client.md)** | RESTful API communication | HTTP APIs, REST services |\n| **[WebSocket](../protocols/websocket.md)** | Full-duplex communication protocol | Real-time web applications, bidirectional communication |\n\n## How Protocol Support Works\nEach protocol usually requires specific dependencies and should be installed in your project (if its noy already are). Make sure to check the documentation for each protocol to figure out which one you need!\n\n### 1. Protocol Configuration\n\nProtocols are configured through the [`channels`](../generators/channels.md) generator:\n\n```js\nexport default {\n  inputType: 'asyncapi',\n  inputPath: './my-api.yaml',\n  generators: [\n    {\n      preset: 'channels',\n      outputPath: './src/__gen__/',\n      language: 'typescript',\n      protocols: ['nats', 'kafka'] // Specify which protocols to generate\n    }\n  ]\n};\n```\n\n### 2. Generated Protocol Functions\n\nThe `channels` generator creates protocol-specific functions for each channel in your AsyncAPI specification:\n\nEach protocol is exported as its own namespace from the generated barrel file,\nand every generated function takes a single object argument:\n\n```typescript\nimport { nats, kafka } from './src/__gen__/channels';\n\n// NATS functions\nawait nats.publishToUserSignup({ message, nc: connection });\nawait nats.subscribeToUserSignup({ onDataCallback: callback, nc: connection });\n\n// Kafka functions — note Kafka uses produceTo/consumeFrom\nawait kafka.produceToUserSignup({ message, kafka: kafkaClient });\nawait kafka.consumeFromUserSignup({\n  onDataCallback: callback,\n  kafka: kafkaClient,\n  options: { fromBeginning: true, groupId: 'my-group' }\n});\n```\n\nThe exact parameters depend on the channel — channels with parameters also take\n`parameters`, and channels with headers accept `headers`. See each protocol's\npage for the full generated signatures.\n\nEach protocol has unique features that are reflected in the generated code:\n\n**NATS** supports:\n- Core publish/subscribe\n- JetStream (persistent messaging)\n- Request/reply patterns\n\n**Kafka** supports:\n- Producer/consumer patterns\n- Consumer groups\n- Topic partitioning\n\n**MQTT** supports:\n- QoS levels (0, 1, 2)\n- Retained messages\n- User properties (headers)\n\n**AMQP** supports:\n- Exchanges and queues\n- Routing patterns\n- Message acknowledgments\n\n## Protocol Selection\n\n### Single Protocol\nGenerate code for one protocol:\n\n```js\n{\n  preset: 'channels',\n  protocols: ['nats']\n}\n```\nor generate for multiple protocols at once:\n\n```js\n{\n  preset: 'channels',\n  protocols: ['nats', 'kafka', 'mqtt']\n}\n```\n\n\n## Protocol-Specific Options\n\nSome generators support protocol-specific configuration options:\n\n```js\n{\n  preset: 'channels',\n  protocols: ['kafka'],\n  kafkaTopicSeparator: '.', // Customize topic separator\n  eventSourceDependency: '@microsoft/fetch-event-source' // Custom EventSource dependency\n}\n```\n\n## Generated Code Structure\n\nProtocol functions are organized by protocol:\n\n```typescript\nexport const Protocols = {\n  nats: {\n    publishToUserSignup: ...,\n    subscribeToUserSignup: ...,\n    jetStreamPublishToUserSignup: ...\n  },\n  kafka: {\n    publishToUserSignup: ...,\n    subscribeToUserSignup: ...\n  },\n  // ... other protocols\n};\n```\n\n## Next Steps\n\n- **[Explore Protocol Documentation](../protocols/)** - Detailed docs for each protocol\n- **[Learn about Channels Generator](../generators/channels.md)** - How to configure protocol generation\n- **[Check Out Examples](https://github.com/the-codegen-project/cli/tree/main/examples)** - See the code generation in action\n- **[Understanding Generators](./generators.md)** - Learn how generators work",
   },
   "inputs/asyncapi": {
     title: "AsyncAPI",
@@ -107,8 +107,8 @@ export const docs: Record<string, DocEntry> = {
     content: "# Migrations\nThese are the migration documents\n- [v0, migrating between v0 versions](v0.md) can be found here.",
   },
   "migrations/v0": {
-    title: "Migrating between v0",
-    content: "<!-- toc is generated with GitHub Actions do not remove toc markers -->\n\n<!-- toc -->\n\n- [Migrating between v0](#migrating-between-v0)\n  * [Breaking Changes 0.39.0](#breaking-changes-0390)\n    + [Functions Parameters](#functions-parameters)\n  * [Breaking Changes 0.55.1](#breaking-changes-0551)\n  * [Breaking Changes 0.61.0](#breaking-changes-0610)\n    + [Channels Multi-File Output](#channels-multi-file-output)\n  * [Breaking Changes 0.64.2](#breaking-changes-0642)\n  * [Breaking Changes 0.71.0](#breaking-changes-0710)\n    + [Library API Type Changes](#library-api-type-changes)\n  * [Breaking Changes 0.72.3](#breaking-changes-0723)\n    + [OpenAPI Operation Names](#openapi-operation-names)\n  * [Breaking Changes 0.72.6](#breaking-changes-0726)\n    + [Generated HTTP Client Uses Native fetch](#generated-http-client-uses-native-fetch)\n\n<!-- tocstop -->\n\n# Migrating between v0\nThese are all the breaking changes in v0 and how to migrate between them\n\n## Breaking Changes 0.39.0\n\n### Functions Parameters\n\nAll TypeScript functions now [use object parameters](../architectural-decisions/typescript.md#28042025) instead of regular parameters. This change affects `channels` and `client` generators across all protocols.\n\nBefore:\n```typescript\n// Publishing\nawait jetStreamPublishToSendUserSignedup(message, parameters, js);\nawait publishToSendUserSignedup(message, parameters, connection);\n\n// Subscribing\nconst subscriber = await jetStreamPullSubscribeToReceiveUserSignedup(\n  onDataCallback,\n  parameters,\n  js,\n  config\n);\n```\n\nAfter:\n```typescript\n// Publishing\nawait jetStreamPublishToSendUserSignedup({\n  message,\n  parameters,\n  js\n});\nawait publishToSendUserSignedup({\n  message,\n  parameters,\n  nc\n});\n\n// Subscribing\nconst subscriber = await jetStreamPullSubscribeToReceiveUserSignedup({\n  onDataCallback,\n  parameters,\n  js,\n  config\n});\n```\n\n## Breaking Changes 0.55.1\n\nWe upgraded the AsyncAPI Modelina dependency to the `next` version so for the next few versions it will contain breaking changes as we continue to improve the tool.\n\n## Breaking Changes 0.61.0\n\n### Channels Multi-File Output\n\nThe `channels` generator now outputs one file per protocol instead of a single file with a `Protocols` object. This change improves tree-shaking, reduces bundle size, and provides better code organization.\n\n**Before (v0.60.x and earlier):**\n```typescript\n// Single file with Protocols object containing all protocols\nimport { Protocols } from './channels/index';\nconst { nats } = Protocols;\nconst { publishToSendUserSignedup, subscribeToReceiveUserSignedup } = nats;\n\n// Or destructure directly\nconst { nats: { publishToSendUserSignedup } } = Protocols;\n```\n\n**After (v0.61.0+):**\n```typescript\n// Option 1: Import specific functions directly from protocol file\nimport {\n  publishToSendUserSignedup,\n  subscribeToReceiveUserSignedup\n} from './channels/nats';\n\n// Option 2: Import the entire protocol as a namespace\nimport * as nats from './channels/nats';\nnats.publishToSendUserSignedup({ ... });\n\n// Option 3: Import from index (protocols are re-exported as namespaces)\nimport { nats, kafka, mqtt } from './channels/index';\nnats.publishToSendUserSignedup({ ... });\n```\n\n**New file structure:**\n```\noutputPath/\n├── index.ts       # Re-exports all protocol namespaces\n├── nats.ts        # NATS-specific functions\n├── kafka.ts       # Kafka-specific functions\n├── mqtt.ts        # MQTT-specific functions\n├── amqp.ts        # AMQP-specific functions\n├── event_source.ts # EventSource-specific functions\n├── http_client.ts  # HTTP client-specific functions\n└── websocket.ts   # WebSocket-specific functions\n```\n\n**Migration steps:**\n1. Replace `import { Protocols } from './channels'` with direct imports from protocol files\n2. Remove destructuring of the `Protocols` object\n3. Update function calls - functions are now standalone exports, not object properties\n4. Optionally use namespace imports (`import * as nats from './channels/nats'`) to keep similar syntax\n\n## Breaking Changes 0.64.2\n\nUpgraded node to minimum v22.\n\n## Breaking Changes 0.71.0\n\n### Library API Type Changes\n\nThe `GenerationResult` and `GeneratorResult` types have changed to support browser-based generation (playground). This only affects users consuming the library programmatically - CLI users are not affected.\n\n**Before (v0.70.x and earlier):**\n```typescript\nimport { runGenerators } from '@the-codegen-project/cli';\n\nconst result = await runGenerators(context);\n\n// Accessing results\nconsole.log(result.totalFiles);                    // number\nconsole.log(result.allFiles);                      // string[] (absolute paths)\nconsole.log(result.generators[0].filesWritten);    // string[] (absolute paths)\n```\n\n**After (v0.71.0+):**\n```typescript\nimport { runGenerators } from '@the-codegen-project/cli';\n\nconst result = await runGenerators(context);\n\n// Accessing results - now includes file content\nconsole.log(result.files.length);                  // number (replaces totalFiles)\nconsole.log(result.files);                         // GeneratedFile[]\nconsole.log(result.generators[0].files);           // GeneratedFile[]\n\n// GeneratedFile shape:\ninterface GeneratedFile {\n  path: string;    // Relative path (e.g., 'src/payloads/User.ts')\n  content: string; // Full file content\n}\n```\n\n**Migration steps:**\n1. Replace `result.totalFiles` with `result.files.length`\n2. Replace `result.allFiles` with `result.files.map(f => f.path)`\n3. Replace `generator.filesWritten` with `generator.files.map(f => f.path)`\n4. Optionally leverage the new `content` property for in-memory processing\n\n## Breaking Changes 0.72.3\n\n### OpenAPI Operation Names\n\nThe OpenAPI `channels` and `client` (`http_client`) generators previously prepended the HTTP method to the operation name, even when the spec already provided an `operationId`. This produced a duplicated verb (e.g. an `addPet` operation with method `POST` generated `postAddPet`). The `operationId` is now used verbatim as the function name, and the method is only used to synthesize a name when no `operationId` is present.\n\nThis renames the generated functions (and their `*Context` interfaces) for any OpenAPI operation that declares an `operationId`.\n\n**Before (v0.72.2 and earlier):**\n```typescript\nimport { postAddPet, putUpdatePet, getFindPetsByStatusAndCategory } from './channels/http_client';\n\nawait postAddPet({ /* ... */ });\n```\n\n**After (v0.72.3+):**\n```typescript\nimport { addPet, updatePet, findPetsByStatusAndCategory } from './channels/http_client';\n\nawait addPet({ /* ... */ });\n```\n\n**Migration steps:**\n1. Regenerate your code.\n2. Update call sites to drop the leading HTTP verb from function names that came from an `operationId` (e.g. `postAddPet` → `addPet`).\n3. Update any references to the renamed `*Context` interfaces (e.g. `PostAddPetContext` → `AddPetContext`).\n\n## Breaking Changes 0.72.6\n\n### Generated HTTP Client Uses Native fetch\n\nThe generated HTTP client (OpenAPI `http_client` channels and the `http` client) no longer imports `node-fetch`. It now uses the global `fetch`/`Headers` built into the runtime. The `node-fetch` (and `@types/node-fetch`) dependency is no longer needed. This project already requires Node.js 22, which ships a global `fetch`.\n\n**Before (v0.72.5 and earlier):**\n```typescript\n// Generated client imported node-fetch\nimport * as NodeFetch from 'node-fetch';\n// package.json needed:\n//   \"node-fetch\": \"^2.6.7\", \"@types/node-fetch\": \"^2.6.11\"\n```\n\n**After (v0.72.6+):**\n```typescript\n// Generated client uses the runtime's global fetch — no import, no dependency.\n// To use a different HTTP implementation (node-fetch, axios, ...), provide it\n// via the makeRequest hook on the client context.\n```\n\n**Migration steps:**\n1. Regenerate your code.\n2. Remove `node-fetch` and `@types/node-fetch` from your project's dependencies if they were only used by the generated client.\n3. Ensure your runtime provides a global `fetch` (Node.js 18+). If you need a custom HTTP implementation, supply it through the `makeRequest` hook instead of relying on the default.",
+    title: "Untitled",
+    content: "<!-- toc is generated with GitHub Actions do not remove toc markers -->\n\n<!-- toc -->\n\n- [Breaking Changes 0.39.0](#breaking-changes-0390)\n  * [Functions Parameters](#functions-parameters)\n- [Breaking Changes 0.55.1](#breaking-changes-0551)\n- [Breaking Changes 0.61.0](#breaking-changes-0610)\n  * [Channels Multi-File Output](#channels-multi-file-output)\n- [Breaking Changes 0.64.2](#breaking-changes-0642)\n- [Breaking Changes 0.71.0](#breaking-changes-0710)\n  * [Library API Type Changes](#library-api-type-changes)\n- [Breaking Changes 0.72.3](#breaking-changes-0723)\n  * [OpenAPI Operation Names](#openapi-operation-names)\n- [Breaking Changes 0.72.6](#breaking-changes-0726)\n  * [Generated HTTP Client Uses Native fetch](#generated-http-client-uses-native-fetch)\n\n<!-- tocstop -->\n\nThese are all the breaking changes in v0 and how to migrate between them\n\n## Breaking Changes 0.39.0\n\n### Functions Parameters\n\nAll TypeScript functions now [use object parameters](../architectural-decisions/typescript.md#28042025) instead of regular parameters. This change affects `channels` and `client` generators across all protocols.\n\nBefore:\n```typescript\n// Publishing\nawait jetStreamPublishToSendUserSignedup(message, parameters, js);\nawait publishToSendUserSignedup(message, parameters, connection);\n\n// Subscribing\nconst subscriber = await jetStreamPullSubscribeToReceiveUserSignedup(\n  onDataCallback,\n  parameters,\n  js,\n  config\n);\n```\n\nAfter:\n```typescript\n// Publishing\nawait jetStreamPublishToSendUserSignedup({\n  message,\n  parameters,\n  js\n});\nawait publishToSendUserSignedup({\n  message,\n  parameters,\n  nc\n});\n\n// Subscribing\nconst subscriber = await jetStreamPullSubscribeToReceiveUserSignedup({\n  onDataCallback,\n  parameters,\n  js,\n  config\n});\n```\n\n## Breaking Changes 0.55.1\n\nWe upgraded the AsyncAPI Modelina dependency to the `next` version so for the next few versions it will contain breaking changes as we continue to improve the tool.\n\n## Breaking Changes 0.61.0\n\n### Channels Multi-File Output\n\nThe `channels` generator now outputs one file per protocol instead of a single file with a `Protocols` object. This change improves tree-shaking, reduces bundle size, and provides better code organization.\n\n**Before (v0.60.x and earlier):**\n```typescript\n// Single file with Protocols object containing all protocols\nimport { Protocols } from './channels/index';\nconst { nats } = Protocols;\nconst { publishToSendUserSignedup, subscribeToReceiveUserSignedup } = nats;\n\n// Or destructure directly\nconst { nats: { publishToSendUserSignedup } } = Protocols;\n```\n\n**After (v0.61.0+):**\n```typescript\n// Option 1: Import specific functions directly from protocol file\nimport {\n  publishToSendUserSignedup,\n  subscribeToReceiveUserSignedup\n} from './channels/nats';\n\n// Option 2: Import the entire protocol as a namespace\nimport * as nats from './channels/nats';\nnats.publishToSendUserSignedup({ ... });\n\n// Option 3: Import from index (protocols are re-exported as namespaces)\nimport { nats, kafka, mqtt } from './channels/index';\nnats.publishToSendUserSignedup({ ... });\n```\n\n**New file structure:**\n```\noutputPath/\n├── index.ts       # Re-exports all protocol namespaces\n├── nats.ts        # NATS-specific functions\n├── kafka.ts       # Kafka-specific functions\n├── mqtt.ts        # MQTT-specific functions\n├── amqp.ts        # AMQP-specific functions\n├── event_source.ts # EventSource-specific functions\n├── http_client.ts  # HTTP client-specific functions\n└── websocket.ts   # WebSocket-specific functions\n```\n\n**Migration steps:**\n1. Replace `import { Protocols } from './channels'` with direct imports from protocol files\n2. Remove destructuring of the `Protocols` object\n3. Update function calls - functions are now standalone exports, not object properties\n4. Optionally use namespace imports (`import * as nats from './channels/nats'`) to keep similar syntax\n\n## Breaking Changes 0.64.2\n\nUpgraded node to minimum v22.\n\n## Breaking Changes 0.71.0\n\n### Library API Type Changes\n\nThe `GenerationResult` and `GeneratorResult` types have changed to support browser-based generation (playground). This only affects users consuming the library programmatically - CLI users are not affected.\n\n**Before (v0.70.x and earlier):**\n```typescript\nimport { runGenerators } from '@the-codegen-project/cli';\n\nconst result = await runGenerators(context);\n\n// Accessing results\nconsole.log(result.totalFiles);                    // number\nconsole.log(result.allFiles);                      // string[] (absolute paths)\nconsole.log(result.generators[0].filesWritten);    // string[] (absolute paths)\n```\n\n**After (v0.71.0+):**\n```typescript\nimport { runGenerators } from '@the-codegen-project/cli';\n\nconst result = await runGenerators(context);\n\n// Accessing results - now includes file content\nconsole.log(result.files.length);                  // number (replaces totalFiles)\nconsole.log(result.files);                         // GeneratedFile[]\nconsole.log(result.generators[0].files);           // GeneratedFile[]\n\n// GeneratedFile shape:\ninterface GeneratedFile {\n  path: string;    // Relative path (e.g., 'src/payloads/User.ts')\n  content: string; // Full file content\n}\n```\n\n**Migration steps:**\n1. Replace `result.totalFiles` with `result.files.length`\n2. Replace `result.allFiles` with `result.files.map(f => f.path)`\n3. Replace `generator.filesWritten` with `generator.files.map(f => f.path)`\n4. Optionally leverage the new `content` property for in-memory processing\n\n## Breaking Changes 0.72.3\n\n### OpenAPI Operation Names\n\nThe OpenAPI `channels` and `client` (`http_client`) generators previously prepended the HTTP method to the operation name, even when the spec already provided an `operationId`. This produced a duplicated verb (e.g. an `addPet` operation with method `POST` generated `postAddPet`). The `operationId` is now used verbatim as the function name, and the method is only used to synthesize a name when no `operationId` is present.\n\nThis renames the generated functions (and their `*Context` interfaces) for any OpenAPI operation that declares an `operationId`.\n\n**Before (v0.72.2 and earlier):**\n```typescript\nimport { postAddPet, putUpdatePet, getFindPetsByStatusAndCategory } from './channels/http_client';\n\nawait postAddPet({ /* ... */ });\n```\n\n**After (v0.72.3+):**\n```typescript\nimport { addPet, updatePet, findPetsByStatusAndCategory } from './channels/http_client';\n\nawait addPet({ /* ... */ });\n```\n\n**Migration steps:**\n1. Regenerate your code.\n2. Update call sites to drop the leading HTTP verb from function names that came from an `operationId` (e.g. `postAddPet` → `addPet`).\n3. Update any references to the renamed `*Context` interfaces (e.g. `PostAddPetContext` → `AddPetContext`).\n\n## Breaking Changes 0.72.6\n\n### Generated HTTP Client Uses Native fetch\n\nThe generated HTTP client (OpenAPI `http_client` channels and the `http` client) no longer imports `node-fetch`. It now uses the global `fetch`/`Headers` built into the runtime. The `node-fetch` (and `@types/node-fetch`) dependency is no longer needed. This project already requires Node.js 22, which ships a global `fetch`.\n\n**Before (v0.72.5 and earlier):**\n```typescript\n// Generated client imported node-fetch\nimport * as NodeFetch from 'node-fetch';\n// package.json needed:\n//   \"node-fetch\": \"^2.6.7\", \"@types/node-fetch\": \"^2.6.11\"\n```\n\n**After (v0.72.6+):**\n```typescript\n// Generated client uses the runtime's global fetch — no import, no dependency.\n// To use a different HTTP implementation (node-fetch, axios, ...), provide it\n// via the makeRequest hook on the client context.\n```\n\n**Migration steps:**\n1. Regenerate your code.\n2. Remove `node-fetch` and `@types/node-fetch` from your project's dependencies if they were only used by the generated client.\n3. Ensure your runtime provides a global `fetch` (Node.js 18+). If you need a custom HTTP implementation, supply it through the `makeRequest` hook instead of relying on the default.",
   },
   "protocols/amqp": {
     title: "AMQP",
@@ -143,8 +143,8 @@ export const docs: Record<string, DocEntry> = {
     content: "# Telemetry\n\nThe Codegen Project CLI collects **anonymous** usage data to help us understand how the tool is being used and make data-driven improvements.\n\n## Privacy First\n\nWe take your privacy seriously. Here's what we collect and what we don't:\n\n### ✅ What We Collect\n\n- **Command usage**: Which commands you run (e.g., `generate`, `init`)\n- **Generator types**: Which generators you use (e.g., `payloads`, `channels`)\n- **Input source types**: Whether you use remote URLs, local relative paths, or absolute paths (not the actual paths)\n- **Feature usage**: Which flags and options you use\n- **Error categories**: Types of errors that occur (not error messages or stack traces)\n- **System information**: CLI version, Node.js version, OS platform\n- **Execution metrics**: Command duration and success rates\n\n### ❌ What We DON'T Collect\n\n- ❌ File paths or file names\n- ❌ Actual URLs or file locations\n- ❌ File contents or schema details\n- ❌ Project names\n- ❌ User names or emails\n- ❌ API keys or credentials\n- ❌ IP addresses (anonymized by analytics provider)\n- ❌ Hostnames\n- ❌ Environment variable values\n- ❌ Git repository information\n- ❌ Custom schema structures\n\n## Managing Telemetry\n\n### Check Status\n\nView your current telemetry settings:\n\n```bash\ncodegen telemetry status\n```\n\nThis shows:\n- Whether telemetry is enabled or disabled\n- Configuration file location\n- What data is collected\n- Environment variable overrides\n\n### Disable Telemetry\n\nYou can disable telemetry in several ways:\n\n#### Option 1: Using the CLI command\n\n```bash\ncodegen telemetry disable\n```\n\n#### Option 2: Environment variable (permanent)\n\nAdd to your shell profile (`.bashrc`, `.zshrc`, etc.):\n\n```bash\nexport CODEGEN_TELEMETRY_DISABLED=1\n```\n\nOr use the standard DO_NOT_TRACK variable:\n\n```bash\nexport DO_NOT_TRACK=1\n```\n\n#### Option 3: Environment variable (per-command)\n\n```bash\nCODEGEN_TELEMETRY_DISABLED=1 codegen generate\n```\n\n#### Option 4: Project-level configuration\n\nIn your `codegen.config.js`:\n\n```javascript\nexport default {\n  inputType: 'asyncapi',\n  inputPath: './asyncapi.yaml',\n  generators: [/* ... */],\n  \n  // Disable telemetry for this project\n  telemetry: {\n    enabled: false\n  }\n}\n```\n\n### Re-enable Telemetry\n\n```bash\ncodegen telemetry enable\n```\n\n## First-Run Notice\n\nWhen you run any command for the first time, you'll see a notice about telemetry:\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                                                             │\n│  The Codegen Project CLI collects anonymous usage data      │\n│  to help us improve the tool.                               │\n│                                                             │\n│  To disable: codegen telemetry disable                      │\n│  Learn more: https://the-codegen-project.org/docs/telemetry │\n│                                                             │\n└─────────────────────────────────────────────────────────────┘\n```\n\nThis notice is shown only once. Telemetry is **opt-out by default**, meaning it's enabled unless you explicitly disable it.\n\n## Debug Mode\n\nTo see what telemetry data is being sent:\n\n```bash\nCODEGEN_TELEMETRY_DEBUG=1 codegen generate\n```\n\nThis logs telemetry events to the console, including:\n- The event being tracked\n- The telemetry configuration state\n- The full payload being sent to the analytics endpoint\n- HTTP response status (success/failure)\n\nEvents are still sent to the analytics endpoint in debug mode, but you can see exactly what's being transmitted. The events will also appear in **GA4 DebugView** when debug mode is enabled.\n\n## Custom Tracking Endpoint (for Organizations)\n\nOrganizations can point telemetry to their own analytics endpoint using environment variables. These environment variables have the **highest priority** and will override any configuration from project-level config or global config files:\n\n```bash\n# Set custom endpoint (highest priority - overrides all other configs)\nexport CODEGEN_TELEMETRY_ENDPOINT=https://analytics.mycompany.com/telemetry\nexport CODEGEN_TELEMETRY_ID=custom-tracking-id\nexport CODEGEN_TELEMETRY_API_SECRET=your-api-secret\n```\n\n**Configuration Priority Order (highest to lowest):**\n1. **Environment variables** (highest priority):\n   - `CODEGEN_TELEMETRY_DISABLED` / `DO_NOT_TRACK` - disable telemetry\n   - `CODEGEN_TELEMETRY_ENDPOINT` - custom analytics endpoint\n   - `CODEGEN_TELEMETRY_ID` - custom tracking ID\n   - `CODEGEN_TELEMETRY_API_SECRET` - custom API secret\n2. **Project-level config** (from `codegen.config.js`)\n3. **Global config file** (`~/.the-codegen-project/config.json`)\n\nExpected endpoint format (GA4 Measurement Protocol compatible):\n\n```\nPOST /telemetry\nContent-Type: application/json\n\n{\n  \"client_id\": \"anonymous-uuid\",\n  \"events\": [{\n    \"name\": \"command_executed\",\n    \"params\": {\n      \"command\": \"generate\",\n      \"flags\": \"watch\",\n      \"input_source\": \"local_relative\",\n      \"input_type\": \"asyncapi\",\n      \"generators\": \"payloads,parameters\",\n      \"generator_count\": 2,\n      \"duration\": 1234,\n      \"success\": true,\n      \"cli_version\": \"0.57.0\",\n      \"node_version\": \"v18.0.0\",\n      \"os\": \"darwin\",\n      \"ci\": false,\n      \"engagement_time_msec\": \"1234\"\n    }\n  }]\n}\n```\n\n## Configuration File\n\nTelemetry settings are stored in:\n\n```\n~/.the-codegen-project/config.json\n```\n\nExample configuration:\n\n```json\n{\n  \"version\": \"1.0.0\",\n  \"telemetry\": {\n    \"enabled\": true,\n    \"anonymousId\": \"550e8400-e29b-41d4-a716-446655440000\",\n    \"endpoint\": \"https://www.google-analytics.com/mp/collect\",\n    \"trackingId\": \"G-XXXXXXXXXX\"\n  },\n  \"hasShownTelemetryNotice\": true,\n  \"lastUpdated\": \"2024-12-11T10:30:00Z\"\n}\n```\n\n## Example Telemetry Events\n\n### Command Execution\n\n```javascript\n{\n  event: 'command_executed',\n  command: 'generate',\n  flags: 'watch',                    // Comma-separated if multiple, 'none' if empty\n  input_source: 'local_relative',    // Not the actual path!\n  input_type: 'asyncapi',\n  generators: 'payloads,parameters,channels',  // Comma-separated list\n  generator_count: 3,\n  duration: 1234,\n  success: true,\n  cli_version: '0.57.0',\n  node_version: 'v18.0.0',\n  os: 'darwin',\n  ci: false,\n  engagement_time_msec: '1234'      // Same as duration for proper engagement tracking\n}\n```\n\n**Why track generator combinations?** This helps us understand:\n- Which generators are commonly used together\n- Popular generator patterns (e.g., \"payloads + parameters\")\n- If certain generators are always used in isolation\n- Common workflows and use cases\n\n### Generator Usage\n\n```javascript\n{\n  event: 'generator_used',\n  generator_type: 'payloads',\n  input_type: 'asyncapi',          // Can be: asyncapi, openapi, jsonschema\n  input_source: 'remote_url',      // Not the actual URL!\n  language: 'typescript',\n  options: '{\"includeValidation\":true,\"serializationType\":\"json\"}',\n  duration: 500,\n  success: true,\n  cli_version: '0.57.0',\n  node_version: 'v18.0.0',\n  os: 'darwin',\n  ci: false,\n  engagement_time_msec: '500'\n}\n```\n\n**Why track individual generators?** This helps us understand:\n- Which generators are most popular\n- How users configure generators (validation, serialization, etc.)\n- Performance characteristics of each generator\n- Success/failure rates per generator type\n\n**Combined with `command_executed` event**, we get both:\n- **Macro view**: What generators are used together\n- **Micro view**: How each generator is configured\n\n### Init Command\n\n```javascript\n{\n  event: 'init_executed',\n  config_type: 'esm',\n  input_type: 'asyncapi',\n  generators: 'payloads,parameters,channels',  // Comma-separated list\n  language: 'typescript',\n  completed: true,\n  cli_version: '0.57.0',\n  node_version: 'v18.0.0',\n  os: 'darwin',\n  ci: false,\n  engagement_time_msec: '100'      // Minimum engagement time\n}\n```\n\n### Error Tracking\n\n```javascript\n{\n  event: 'error_occurred',\n  command: 'generate',\n  error_type: 'configuration_error',  // Category only, not actual error message\n  cli_version: '0.57.0',\n  node_version: 'v18.0.0'\n}\n```\n\n## CI/CD Environments\n\nTelemetry automatically detects CI environments and adjusts behavior:\n\n- **First-run notice is skipped** in CI environments\n- Telemetry still runs by default (to track CI usage patterns)\n- You can disable it with environment variables if needed\n\nDetected CI environments:\n- GitHub Actions\n- GitLab CI\n- CircleCI\n- Travis CI\n- Jenkins\n- Bitbucket Pipelines\n- AWS CodeBuild\n- TeamCity\n- Buildkite\n\n## Privacy & Compliance\n\n### GDPR Compliance\n\nOur telemetry implementation is GDPR compliant:\n\n- ✅ **Lawful Basis**: Legitimate interest (improving software)\n- ✅ **Transparency**: Clear notice on first run\n- ✅ **User Control**: Easy opt-out mechanism\n- ✅ **Data Minimization**: Only collect necessary data\n- ✅ **Purpose Limitation**: Use only for improvement\n- ✅ **Anonymization**: No PII collected\n- ✅ **Right to Object**: Users can disable anytime\n\n### Data Retention\n\nWe store data for 14 months, if you use your own telemetry, then its up to you.\n\n### Anonymous ID\n\nEach installation generates a random UUID (v4) as an anonymous identifier. This ID:\n- Is NOT tied to your identity\n- Cannot be used to identify you personally\n- Is only used to understand usage patterns\n- Can be reset by deleting the config file\n\n## How Telemetry Helps\n\nThe data we collect helps us:\n\n1. **Prioritize features**: Focus on the most-used generators and commands\n2. **Improve reliability**: Identify and fix common error scenarios\n3. **Optimize performance**: Understand typical execution times\n4. **Support platforms**: Know which Node.js versions and OS platforms to support\n5. **Guide documentation**: Understand which features cause confusion\n6. **Understand workflows**: Learn whether users prefer remote URLs, relative paths, or absolute paths\n\n## Technical Details\n\n### Implementation\n\n- **Non-blocking**: Telemetry runs asynchronously and never blocks CLI execution\n- **Fail-safe**: Network errors or timeouts don't affect CLI functionality\n- **Fast timeout**: Telemetry requests timeout after 1 second\n- **Error handling**: All errors are handled gracefully and silently\n\n### Default Analytics Provider\n\nWe use Google Analytics 4 Measurement Protocol by default:\n- Free service with powerful analytics\n- Automatic IP anonymization\n- GDPR compliant\n- No additional infrastructure needed\n\n## Website Analytics\n\nIn addition to CLI telemetry, our documentation website (https://the-codegen-project.org) also uses **Google Analytics 4** to understand how users interact with our documentation.\n\n### What the Website Tracks\n\n- **Page views**: Which documentation pages are viewed\n- **Navigation**: How users navigate through the documentation\n- **Search queries**: What users search for in the docs\n- **Outbound links**: Which external links users click\n- **Time on page**: How long users spend reading documentation\n- **Referral sources**: How users found our documentation\n\n**Note:** The website uses a different Google Analytics property than the CLI telemetry. They are completely separate tracking systems.\n\n### What the Website Does NOT Track\n\n- ❌ Personal information\n- ❌ Form inputs or data\n- ❌ Clipboard contents\n- ❌ Code snippets you copy\n- ❌ IP addresses (anonymized by GA4)\n\n### Website Privacy Controls\n\n**Standard Browser Controls:**\n- Use browser \"Do Not Track\" settings\n- Install privacy extensions (uBlock Origin, Privacy Badger, etc.)\n- Use browser incognito/private mode\n- Disable JavaScript (documentation still accessible)\n\n**Website-Specific Settings:**\n- Our website respects the `DO_NOT_TRACK` browser header\n- No cookies are set for tracking purposes\n- Google Analytics IP anonymization is enabled\n- No third-party tracking scripts beyond GA4\n\n## FAQ\n\n### Q: Will telemetry slow down my CLI?\n\n**A**: No. Telemetry runs asynchronously and doesn't block command execution. Network requests timeout after 1 second and fail silently.\n\n### Q: Can telemetry errors break my CLI?\n\n**A**: No. All telemetry functions are designed to never throw errors. Failures are handled internally and don't affect CLI functionality.\n\n### Q: Does this work behind a corporate proxy?\n\n**A**: Yes. Telemetry respects standard `HTTP_PROXY` and `HTTPS_PROXY` environment variables. If it fails, it fails silently without affecting the CLI.\n\n### Q: Can I see what's being sent?\n\n**A**: Yes! Use debug mode:\n\n```bash\nCODEGEN_TELEMETRY_DEBUG=1 codegen generate\n```\n\n### Q: Why opt-out instead of opt-in?\n\n**A**: Opt-out telemetry provides more representative data about how the tool is actually used, which leads to better improvements for all users. However, we respect your choice to opt-out at any time.\n\n### Q: Is my company's internal tracking supported?\n\n**A**: Yes! Set `CODEGEN_TELEMETRY_ENDPOINT` to your internal analytics service. See the \"Custom Tracking Endpoint\" section above.\n\n### Q: Where is the data sent?\n\n**A**: By default, to Google Analytics 4 (anonymized). You can configure a custom endpoint for organizational tracking.\n\n### Q: Can you track me across projects?\n\n**A**: We use an anonymous UUID that is the same across all your projects (any where you interact with the-codegen-project), but it's not tied to any personal information. You can reset it by deleting `~/.the-codegen-project/config.json`.\n\n### Q: Are CLI telemetry and website analytics linked?\n\n**A**: No. The CLI uses an anonymous UUID that is never shared with the website. Website analytics use standard Google Analytics browser tracking. There is no way to correlate CLI usage with website visits - they are completely independent systems.\n\n## Contact\n\nIf you have questions or concerns about telemetry:\n\n- GitHub Issues: [the-codegen-project/cli](https://github.com/the-codegen-project/cli/issues)",
   },
   "usage": {
-    title: "CLI Usage",
-    content: "# CLI Usage\n\n<!-- usage -->\n```sh-session\n$ npm install -g @the-codegen-project/cli\n$ codegen COMMAND\nrunning command...\n$ codegen (--version)\n@the-codegen-project/cli/0.81.0 linux-x64 node-v22.23.1\n$ codegen --help [COMMAND]\nUSAGE\n  $ codegen COMMAND\n...\n```\n<!-- usagestop -->\n\n## Table of contents\n\n<!-- toc -->\n* [CLI Usage](#cli-usage)\n<!-- tocstop -->\n\n## Commands\n\n<!-- commands -->\n* [`codegen autocomplete [SHELL]`](#codegen-autocomplete-shell)\n* [`codegen generate [FILE]`](#codegen-generate-file)\n* [`codegen help [COMMAND]`](#codegen-help-command)\n* [`codegen init`](#codegen-init)\n* [`codegen telemetry ACTION`](#codegen-telemetry-action)\n* [`codegen version`](#codegen-version)\n\n## `codegen autocomplete [SHELL]`\n\nDisplay autocomplete installation instructions.\n\n```\nUSAGE\n  $ codegen autocomplete [SHELL] [-r]\n\nARGUMENTS\n  SHELL  (zsh|bash|powershell) Shell type\n\nFLAGS\n  -r, --refresh-cache  Refresh cache (ignores displaying instructions)\n\nDESCRIPTION\n  Display autocomplete installation instructions.\n\nEXAMPLES\n  $ codegen autocomplete\n\n  $ codegen autocomplete bash\n\n  $ codegen autocomplete zsh\n\n  $ codegen autocomplete powershell\n\n  $ codegen autocomplete --refresh-cache\n```\n\n_See code: [@oclif/plugin-autocomplete](https://github.com/oclif/plugin-autocomplete/blob/v3.2.45/src/commands/autocomplete/index.ts)_\n\n## `codegen generate [FILE]`\n\nGenerate code based on your configuration, use `init` to get started, `generate` to generate code from the configuration.\n\n```\nUSAGE\n  $ codegen generate [FILE] [--json] [--no-color] [--debug | [-q | -v | --silent] | ] [--help] [-w] [-p\n    <value>]\n\nARGUMENTS\n  FILE  Path or URL to the configuration file, defaults to root of where the command is run\n\nFLAGS\n  -p, --watchPath=<value>  Optional path to watch for changes when --watch flag is used. If not provided, watches the\n                           input file from configuration\n  -q, --quiet              Only show errors and warnings\n  -v, --verbose            Show detailed output\n  -w, --watch              Watch for file changes and regenerate code automatically\n      --debug              Show debug information\n      --help               Show CLI help.\n      --json               Output results as JSON for scripting\n      --no-color           Disable colored output\n      --silent             Suppress all output except fatal errors\n\nDESCRIPTION\n  Generate code based on your configuration, use `init` to get started, `generate` to generate code from the\n  configuration.\n```\n\n_See code: [src/commands/generate.ts](https://github.com/the-codegen-project/cli/blob/v0.81.0/src/commands/generate.ts)_\n\n## `codegen help [COMMAND]`\n\nDisplay help for codegen.\n\n```\nUSAGE\n  $ codegen help [COMMAND...] [-n]\n\nARGUMENTS\n  COMMAND...  Command to show help for.\n\nFLAGS\n  -n, --nested-commands  Include all nested commands in the output.\n\nDESCRIPTION\n  Display help for codegen.\n```\n\n_See code: [@oclif/plugin-help](https://github.com/oclif/plugin-help/blob/v6.0.22/src/commands/help.ts)_\n\n## `codegen init`\n\nInitialize The Codegen Project in your project\n\n```\nUSAGE\n  $ codegen init [--json] [--no-color] [--debug |  | [--silent | -v | -q]] [--help] [--input-file <value>]\n    [--config-name <value>] [--input-type asyncapi|openapi|jsonschema] [--output-directory <value>] [--config-type\n    esm|json|yaml|ts] [--languages typescript] [--channels-protocols\n    nats|kafka|mqtt|amqp|event_source|http_client|websocket] [--no-tty] [--include-payloads] [--include-headers]\n    [--include-client] [--include-parameters] [--include-channels] [--include-types] [--include-models]\n    [--gitignore-generated]\n\nFLAGS\n  -q, --quiet                           Only show errors and warnings\n  -v, --verbose                         Show detailed output\n      --channels-protocols=<option>...  Which protocols to generate channel functions for (used with\n                                        --include-channels/--include-client on AsyncAPI inputs). Repeatable.\n                                        <options: nats|kafka|mqtt|amqp|event_source|http_client|websocket>\n      --config-name=<value>             [default: codegen] The name to use for the configuration file (dont include file\n                                        extension)\n      --config-type=<option>            [default: esm] The type of configuration file. 'esm', 'ts' can do everything,\n                                        'json' and 'yaml' is more restrictive. Read more here:\n                                        https://github.com/the-codegen-project/cli/blob/main/docs/configurations.md\n                                        <options: esm|json|yaml|ts>\n      --debug                           Show debug information\n      --gitignore-generated             Add generated output directories to .gitignore\n      --help                            Show CLI help.\n      --include-channels                Include channels generation, available for TypeScript\n      --include-client                  Include client generation, available for TypeScript\n      --include-headers                 Include headers generation, available for TypeScript\n      --include-models                  Include models generation, available for TypeScript\n      --include-parameters              Include parameters generation, available for TypeScript\n      --include-payloads                Include payloads generation, available for TypeScript\n      --include-types                   Include types generation, available for TypeScript\n      --input-file=<value>              File path for the code generation input such as AsyncAPI document\n      --input-type=<option>             Input file type\n                                        <options: asyncapi|openapi|jsonschema>\n      --json                            Output results as JSON for scripting\n      --languages=<option>              [default: typescript] Which languages do you wish to generate code for?\n                                        <options: typescript>\n      --no-color                        Disable colored output\n      --no-tty                          Do not use an interactive terminal\n      --output-directory=<value>        [default: ./] Output configuration location, path to where the configuration\n                                        file should be located. If relative path, the current working directory of the\n                                        terminal will be used\n      --silent                          Suppress all output except fatal errors\n\nDESCRIPTION\n  Initialize The Codegen Project in your project\n```\n\n_See code: [src/commands/init.ts](https://github.com/the-codegen-project/cli/blob/v0.81.0/src/commands/init.ts)_\n\n## `codegen telemetry ACTION`\n\nManage telemetry settings\n\n```\nUSAGE\n  $ codegen telemetry ACTION [--json] [--no-color] [--debug | [-q | -v | --silent] | ] [--help]\n\nARGUMENTS\n  ACTION  (status|enable|disable) Action to perform: status, enable, or disable\n\nFLAGS\n  -q, --quiet     Only show errors and warnings\n  -v, --verbose   Show detailed output\n      --debug     Show debug information\n      --help      Show CLI help.\n      --json      Output results as JSON for scripting\n      --no-color  Disable colored output\n      --silent    Suppress all output except fatal errors\n\nDESCRIPTION\n  Manage telemetry settings\n\nEXAMPLES\n  $ codegen telemetry status\n\n  $ codegen telemetry enable\n\n  $ codegen telemetry disable\n```\n\n_See code: [src/commands/telemetry.ts](https://github.com/the-codegen-project/cli/blob/v0.81.0/src/commands/telemetry.ts)_\n\n## `codegen version`\n\n```\nUSAGE\n  $ codegen version [--json] [--verbose]\n\nFLAGS\n  --verbose  Show additional information about the CLI.\n\nGLOBAL FLAGS\n  --json  Format output as json.\n\nFLAG DESCRIPTIONS\n  --verbose  Show additional information about the CLI.\n\n    Additionally shows the architecture, node version, operating system, and versions of plugins that the CLI is using.\n```\n\n_See code: [@oclif/plugin-version](https://github.com/oclif/plugin-version/blob/v2.1.2/src/commands/version.ts)_\n<!-- commandsstop -->",
+    title: "Untitled",
+    content: "<!-- usage -->\n```sh-session\n$ npm install -g @the-codegen-project/cli\n$ codegen COMMAND\nrunning command...\n$ codegen (--version)\n@the-codegen-project/cli/0.81.1 linux-x64 node-v22.23.1\n$ codegen --help [COMMAND]\nUSAGE\n  $ codegen COMMAND\n...\n```\n<!-- usagestop -->\n\n## Table of contents\n\n<!-- toc -->\n\n<!-- tocstop -->\n\n## Commands\n\n<!-- commands -->\n* [`codegen autocomplete [SHELL]`](#codegen-autocomplete-shell)\n* [`codegen generate [FILE]`](#codegen-generate-file)\n* [`codegen help [COMMAND]`](#codegen-help-command)\n* [`codegen init`](#codegen-init)\n* [`codegen telemetry ACTION`](#codegen-telemetry-action)\n* [`codegen version`](#codegen-version)\n\n## `codegen autocomplete [SHELL]`\n\nDisplay autocomplete installation instructions.\n\n```\nUSAGE\n  $ codegen autocomplete [SHELL] [-r]\n\nARGUMENTS\n  SHELL  (zsh|bash|powershell) Shell type\n\nFLAGS\n  -r, --refresh-cache  Refresh cache (ignores displaying instructions)\n\nDESCRIPTION\n  Display autocomplete installation instructions.\n\nEXAMPLES\n  $ codegen autocomplete\n\n  $ codegen autocomplete bash\n\n  $ codegen autocomplete zsh\n\n  $ codegen autocomplete powershell\n\n  $ codegen autocomplete --refresh-cache\n```\n\n_See code: [@oclif/plugin-autocomplete](https://github.com/oclif/plugin-autocomplete/blob/v3.2.45/src/commands/autocomplete/index.ts)_\n\n## `codegen generate [FILE]`\n\nGenerate code based on your configuration, use `init` to get started, `generate` to generate code from the configuration.\n\n```\nUSAGE\n  $ codegen generate [FILE] [--json] [--no-color] [--debug | [-q | -v | --silent] | ] [--help] [-w] [-p\n    <value>]\n\nARGUMENTS\n  FILE  Path or URL to the configuration file, defaults to root of where the command is run\n\nFLAGS\n  -p, --watchPath=<value>  Optional path to watch for changes when --watch flag is used. If not provided, watches the\n                           input file from configuration\n  -q, --quiet              Only show errors and warnings\n  -v, --verbose            Show detailed output\n  -w, --watch              Watch for file changes and regenerate code automatically\n      --debug              Show debug information\n      --help               Show CLI help.\n      --json               Output results as JSON for scripting\n      --no-color           Disable colored output\n      --silent             Suppress all output except fatal errors\n\nDESCRIPTION\n  Generate code based on your configuration, use `init` to get started, `generate` to generate code from the\n  configuration.\n```\n\n_See code: [src/commands/generate.ts](https://github.com/the-codegen-project/cli/blob/v0.81.1/src/commands/generate.ts)_\n\n## `codegen help [COMMAND]`\n\nDisplay help for codegen.\n\n```\nUSAGE\n  $ codegen help [COMMAND...] [-n]\n\nARGUMENTS\n  COMMAND...  Command to show help for.\n\nFLAGS\n  -n, --nested-commands  Include all nested commands in the output.\n\nDESCRIPTION\n  Display help for codegen.\n```\n\n_See code: [@oclif/plugin-help](https://github.com/oclif/plugin-help/blob/v6.0.22/src/commands/help.ts)_\n\n## `codegen init`\n\nInitialize The Codegen Project in your project\n\n```\nUSAGE\n  $ codegen init [--json] [--no-color] [--debug |  | [--silent | -v | -q]] [--help] [--input-file <value>]\n    [--config-name <value>] [--input-type asyncapi|openapi|jsonschema] [--output-directory <value>] [--config-type\n    esm|json|yaml|ts] [--languages typescript] [--channels-protocols\n    nats|kafka|mqtt|amqp|event_source|http_client|websocket] [--no-tty] [--include-payloads] [--include-headers]\n    [--include-client] [--include-parameters] [--include-channels] [--include-types] [--include-models]\n    [--gitignore-generated]\n\nFLAGS\n  -q, --quiet                           Only show errors and warnings\n  -v, --verbose                         Show detailed output\n      --channels-protocols=<option>...  Which protocols to generate channel functions for (used with\n                                        --include-channels/--include-client on AsyncAPI inputs). Repeatable.\n                                        <options: nats|kafka|mqtt|amqp|event_source|http_client|websocket>\n      --config-name=<value>             [default: codegen] The name to use for the configuration file (dont include file\n                                        extension)\n      --config-type=<option>            [default: esm] The type of configuration file. 'esm', 'ts' can do everything,\n                                        'json' and 'yaml' is more restrictive. Read more here:\n                                        https://github.com/the-codegen-project/cli/blob/main/docs/configurations.md\n                                        <options: esm|json|yaml|ts>\n      --debug                           Show debug information\n      --gitignore-generated             Add generated output directories to .gitignore\n      --help                            Show CLI help.\n      --include-channels                Include channels generation, available for TypeScript\n      --include-client                  Include client generation, available for TypeScript\n      --include-headers                 Include headers generation, available for TypeScript\n      --include-models                  Include models generation, available for TypeScript\n      --include-parameters              Include parameters generation, available for TypeScript\n      --include-payloads                Include payloads generation, available for TypeScript\n      --include-types                   Include types generation, available for TypeScript\n      --input-file=<value>              File path for the code generation input such as AsyncAPI document\n      --input-type=<option>             Input file type\n                                        <options: asyncapi|openapi|jsonschema>\n      --json                            Output results as JSON for scripting\n      --languages=<option>              [default: typescript] Which languages do you wish to generate code for?\n                                        <options: typescript>\n      --no-color                        Disable colored output\n      --no-tty                          Do not use an interactive terminal\n      --output-directory=<value>        [default: ./] Output configuration location, path to where the configuration\n                                        file should be located. If relative path, the current working directory of the\n                                        terminal will be used\n      --silent                          Suppress all output except fatal errors\n\nDESCRIPTION\n  Initialize The Codegen Project in your project\n```\n\n_See code: [src/commands/init.ts](https://github.com/the-codegen-project/cli/blob/v0.81.1/src/commands/init.ts)_\n\n## `codegen telemetry ACTION`\n\nManage telemetry settings\n\n```\nUSAGE\n  $ codegen telemetry ACTION [--json] [--no-color] [--debug | [-q | -v | --silent] | ] [--help]\n\nARGUMENTS\n  ACTION  (status|enable|disable) Action to perform: status, enable, or disable\n\nFLAGS\n  -q, --quiet     Only show errors and warnings\n  -v, --verbose   Show detailed output\n      --debug     Show debug information\n      --help      Show CLI help.\n      --json      Output results as JSON for scripting\n      --no-color  Disable colored output\n      --silent    Suppress all output except fatal errors\n\nDESCRIPTION\n  Manage telemetry settings\n\nEXAMPLES\n  $ codegen telemetry status\n\n  $ codegen telemetry enable\n\n  $ codegen telemetry disable\n```\n\n_See code: [src/commands/telemetry.ts](https://github.com/the-codegen-project/cli/blob/v0.81.1/src/commands/telemetry.ts)_\n\n## `codegen version`\n\n```\nUSAGE\n  $ codegen version [--json] [--verbose]\n\nFLAGS\n  --verbose  Show additional information about the CLI.\n\nGLOBAL FLAGS\n  --json  Format output as json.\n\nFLAG DESCRIPTIONS\n  --verbose  Show additional information about the CLI.\n\n    Additionally shows the architecture, node version, operating system, and versions of plugins that the CLI is using.\n```\n\n_See code: [@oclif/plugin-version](https://github.com/oclif/plugin-version/blob/v2.1.2/src/commands/version.ts)_\n<!-- commandsstop -->",
   }
 };
 
diff --git a/package-lock.json b/package-lock.json
index dd7b35b9..91ea67b7 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -1,12 +1,12 @@
 {
   "name": "@the-codegen-project/cli",
-  "version": "0.81.0",
+  "version": "0.81.1",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@the-codegen-project/cli",
-      "version": "0.81.0",
+      "version": "0.81.1",
       "license": "Apache-2.0",
       "dependencies": {
         "@apidevtools/json-schema-ref-parser": "^14.2.0",
diff --git a/package.json b/package.json
index a34ed0c2..70db2b7d 100644
--- a/package.json
+++ b/package.json
@@ -1,7 +1,7 @@
 {
   "name": "@the-codegen-project/cli",
   "description": "CLI to work with code generation in any environment",
-  "version": "0.81.0",
+  "version": "0.81.1",
   "bin": {
     "codegen": "./bin/run.mjs"
   },
diff --git a/website/static/codegen.browser.mjs b/website/static/codegen.browser.mjs
index 3f21c85b..3c810e4b 100644
--- a/website/static/codegen.browser.mjs
+++ b/website/static/codegen.browser.mjs
@@ -91388,6 +91388,8 @@ var init_object = __esm({
     init_dirname();
     init_buffer2();
     init_process2();
+    init_get();
+    init_set();
     init_object_default();
   }
 });
@@ -1018180,6 +1018182,46 @@ function chooseComponentModelNames(componentNames) {
   }
   return chosen;
 }
+var HTTP_METHODS = [
+  "get",
+  "post",
+  "put",
+  "patch",
+  "delete",
+  "options",
+  "head",
+  "trace"
+];
+function isHttpMethod(key) {
+  return HTTP_METHODS.includes(key.toLowerCase());
+}
+function collectOperationParameters({
+  pathItem,
+  operation
+}) {
+  const pathLevel = readParameters(pathItem);
+  const operationLevel = readParameters(operation);
+  if (pathLevel.length === 0) {
+    return operationLevel;
+  }
+  const overridden = new Set(
+    operationLevel.map((parameter) => parameterKey(parameter))
+  );
+  const inherited = pathLevel.filter(
+    (parameter) => !overridden.has(parameterKey(parameter))
+  );
+  return [...inherited, ...operationLevel];
+}
+function parameterKey(parameter) {
+  return `${parameter?.in}:${parameter?.name}`;
+}
+function readParameters(container) {
+  if (!container || typeof container !== "object") {
+    return [];
+  }
+  const parameters = container.parameters;
+  return Array.isArray(parameters) ? parameters : [];
+}
 function deriveOperationId({
   operationId,
   method: method2,
@@ -1018213,8 +1018255,14 @@ function processOpenAPIParameters(openapiDocument) {
     openapiDocument.paths ?? {}
   )) {
     for (const [method2, operation] of Object.entries(pathItem)) {
+      if (!isHttpMethod(method2)) {
+        continue;
+      }
       const operationObj = operation;
-      const allParameters = operationObj.parameters ?? [];
+      const allParameters = collectOperationParameters({
+        pathItem,
+        operation: operationObj
+      });
       const cookieParams = allParameters.filter(
         (param) => param.in === "cookie"
       );
@@ -1019391,6 +1019439,23 @@ function pickJsonSchema(content) {
   ) ?? jsonEntries[0];
   return preferred[1].schema ?? null;
 }
+function warnDroppedContentTypes({
+  content,
+  location: location2
+}) {
+  if (!content) {
+    return;
+  }
+  const dropped = Object.keys(content).filter(
+    (contentType) => !isJsonContentType(contentType)
+  );
+  if (dropped.length === 0) {
+    return;
+  }
+  Logger2.warn(
+    `${location2} declares content type(s) [${dropped.join(", ")}] alongside a JSON one; only the JSON variant was generated`
+  );
+}
 function extractOpenAPI2ResponseSchema(response) {
   if (response.schema) {
     return response.schema;
@@ -1019444,7 +1019509,7 @@ function extractPayloadsFromOperations(paths) {
       continue;
     }
     for (const [method2, operation] of Object.entries(pathItem)) {
-      if (!operation || typeof operation !== "object") {
+      if (!operation || typeof operation !== "object" || !isHttpMethod(method2)) {
         continue;
       }
       const operationObj = operation;
@@ -1019461,10 +1019526,18 @@ function extractPayloadsFromOperations(paths) {
           Logger2.warn(
             `OpenAPI operation '${method2.toUpperCase()} ${pathKey}' request body has no JSON-compatible content type (found: ${Object.keys(requestBody.content).join(", ")}); no request payload was generated`
           );
+        } else if (requestSchema) {
+          warnDroppedContentTypes({
+            content: requestBody.content,
+            location: `OpenAPI operation '${method2.toUpperCase()} ${pathKey}' request body`
+          });
         }
-      } else if ("parameters" in operationObj && operationObj.parameters) {
+      } else {
         requestSchema = extractOpenAPI2RequestSchema(
-          operationObj.parameters
+          collectOperationParameters({
+            pathItem,
+            operation: operationObj
+          })
         );
       }
       if (requestSchema) {
@@ -1019499,6 +1019572,11 @@ function extractPayloadsFromOperations(paths) {
               Logger2.warn(
                 `OpenAPI operation '${method2.toUpperCase()} ${pathKey}' response '${statusCode}' has no JSON-compatible content type (found: ${Object.keys(responseObj.content).join(", ")}); no response payload was generated`
               );
+            } else if (responseSchema) {
+              warnDroppedContentTypes({
+                content: responseObj.content,
+                location: `OpenAPI operation '${method2.toUpperCase()} ${pathKey}' response '${statusCode}'`
+              });
             }
           }
           if (responseSchema) {
@@ -1019823,10 +1019901,7 @@ function renderUnionUnmarshal(model, renderer) {
 }`;
 }
 function extractStatusCodeValue(unionMember) {
-  if (!(unionMember instanceof ConstrainedReferenceModel && unionMember.ref instanceof ConstrainedObjectModel)) {
-    return null;
-  }
-  const memberOriginalInput = unionMember.ref.originalInput;
+  const memberOriginalInput = unionMember instanceof ConstrainedReferenceModel ? unionMember.ref.originalInput : unionMember.originalInput;
   const statusCode = memberOriginalInput?.["x-modelina-status-codes"];
   if (!statusCode) {
     return null;
@@ -1019839,9 +1019914,17 @@ function extractStatusCodeValue(unionMember) {
   }
   return null;
 }
+function hasOwnUnmarshal(unionMember) {
+  return unionMember instanceof ConstrainedReferenceModel && unionMember.ref instanceof ConstrainedObjectModel;
+}
 function generateStatusCodeCheck(unionMember, codeValue) {
+  const parseExpression = hasOwnUnmarshal(unionMember) ? `${unionMember.type}.unmarshal(json)` : (
+    // Arrays, primitives and enums have no unmarshal of their own; parse
+    // structurally, mirroring the union's generic `unmarshal`.
+    `JSON.parse(json) as ${unionMember.type}`
+  );
   return `  if (statusCode === ${codeValue}) {
-    return ${unionMember.type}.unmarshal(json);
+    return ${parseExpression};
   }`;
 }
 function renderUnionUnmarshalByStatusCode(model) {
@@ -1020409,8 +1020492,14 @@ function extractHeadersFromOperations(paths) {
   const operationHeaders = {};
   for (const [pathKey, pathItem] of Object.entries(paths)) {
     for (const [method2, operation] of Object.entries(pathItem)) {
+      if (!isHttpMethod(method2)) {
+        continue;
+      }
       const operationObj = operation;
-      const allParameters = operationObj.parameters ?? [];
+      const allParameters = collectOperationParameters({
+        pathItem,
+        operation: operationObj
+      });
       const headerParams = allParameters.filter((param) => {
         return param.in === "header";
       });
@@ -1024726,15 +1024815,15 @@ function validateOAuth2Config(auth: OAuth2Auth): void {
   // If using a flow, validate required fields
   switch (auth.flow) {
     case 'client_credentials':
-      if (!auth.tokenUrl) throw new Error('OAuth2 Client Credentials flow requires tokenUrl');
-      if (!auth.clientId) throw new Error('OAuth2 Client Credentials flow requires clientId');
+      if (!auth.tokenUrl) throw new HttpGlobalError('OAuth2 Client Credentials flow requires tokenUrl');
+      if (!auth.clientId) throw new HttpGlobalError('OAuth2 Client Credentials flow requires clientId');
       break;
 
     case 'password':
-      if (!auth.tokenUrl) throw new Error('OAuth2 Password flow requires tokenUrl');
-      if (!auth.clientId) throw new Error('OAuth2 Password flow requires clientId');
-      if (!auth.username) throw new Error('OAuth2 Password flow requires username');
-      if (!auth.password) throw new Error('OAuth2 Password flow requires password');
+      if (!auth.tokenUrl) throw new HttpGlobalError('OAuth2 Password flow requires tokenUrl');
+      if (!auth.clientId) throw new HttpGlobalError('OAuth2 Password flow requires clientId');
+      if (!auth.username) throw new HttpGlobalError('OAuth2 Password flow requires username');
+      if (!auth.password) throw new HttpGlobalError('OAuth2 Password flow requires password');
       break;
 
     default:
@@ -1024798,7 +1024887,7 @@ async function handleOAuth2TokenFlow(
   });
 
   if (!tokenResponse.ok) {
-    throw new Error(\`OAuth2 token request failed: \${tokenResponse.statusText}\`);
+    throw new HttpGlobalError(\`OAuth2 token request failed: \${tokenResponse.statusText}\`);
   }
 
   const tokenData = await tokenResponse.json();
@@ -1024845,7 +1024934,7 @@ async function handleTokenRefresh(
   });
 
   if (!refreshResponse.ok) {
-    throw new Error('Unauthorized');
+    throw new HttpGlobalError('Unauthorized');
   }
 
   const tokenData = await refreshResponse.json();
@@ -1024960,6 +1025049,17 @@ const API_KEY_DEFAULTS = {
 // Common Types - Shared across all HTTP client functions
 // ============================================================================
 
+/**
+ * The global \`Error\`, captured under a name a payload model cannot take.
+ *
+ * A document is free to declare a schema called \`Error\` (it is the
+ * conventional name for one), and its generated model is imported into this
+ * module, shadowing the global for the whole file. Every reference below goes
+ * through these aliases so that is harmless.
+ */
+const HttpGlobalError = globalThis.Error;
+type HttpGlobalError = InstanceType<typeof globalThis.Error>;
+
 /**
  * Standard HTTP response interface that wraps fetch-like responses
  */
@@ -1024994,7 +1025094,7 @@ export interface HttpClientResponse<T> {
  * (when the error response had a JSON body). Thrown by \`handleHttpError\` and
  * routed through the \`onError\` hook / retry logic unchanged.
  */
-export class HttpError extends Error {
+export class HttpError extends HttpGlobalError {
   status: number;
   statusText: string;
   body?: unknown;
@@ -1025044,7 +1025144,7 @@ export interface RetryConfig {
   backoffMultiplier?: number;    // Multiplier for exponential backoff (default: 2)
   retryableStatusCodes?: number[]; // Status codes to retry (default: [408, 429, 500, 502, 503, 504])
   retryOnNetworkError?: boolean; // Retry on network errors (default: true)
-  onRetry?: (attempt: number, delay: number, error: Error) => void; // Callback on each retry
+  onRetry?: (attempt: number, delay: number, error: HttpGlobalError) => void; // Callback on each retry
 }
 
 // ============================================================================
@@ -1025076,7 +1025176,7 @@ export interface HttpHooks {
   /**
    * Called on request error for logging, error transformation, etc.
    */
-  onError?: (error: Error, params: HttpRequestParams) => Error | Promise<Error>;
+  onError?: (error: HttpGlobalError, params: HttpRequestParams) => HttpGlobalError | Promise<HttpGlobalError>;
 }
 
 // ============================================================================
@@ -1025204,7 +1025304,7 @@ function calculateBackoffDelay(
  * Determine if a request should be retried based on error/response
  */
 function shouldRetry(
-  error: Error | null,
+  error: HttpGlobalError | null,
   response: HttpResponse | null,
   config: Required<RetryConfig>,
   attempt: number
@@ -1025227,14 +1025327,14 @@ async function executeWithRetry(
   retryConfig?: RetryConfig
 ): Promise<HttpResponse> {
   const config = { ...DEFAULT_RETRY_CONFIG, ...retryConfig };
-  let lastError: Error | null = null;
+  let lastError: HttpGlobalError | null = null;
   let lastResponse: HttpResponse | null = null;
 
   for (let attempt = 0; attempt <= config.maxRetries; attempt++) {
     try {
       if (attempt > 0) {
         const delay = calculateBackoffDelay(attempt, config);
-        config.onRetry(attempt, delay, lastError ?? new Error('Retry attempt'));
+        config.onRetry(attempt, delay, lastError ?? new HttpGlobalError('Retry attempt'));
         await sleep(delay);
       }
 
@@ -1025246,9 +1025346,9 @@ async function executeWithRetry(
       }
 
       lastResponse = response;
-      lastError = new Error(\`HTTP Error: \${response.status} \${response.statusText}\`);
+      lastError = new HttpGlobalError(\`HTTP Error: \${response.status} \${response.statusText}\`);
     } catch (error) {
-      lastError = error instanceof Error ? error : new Error(String(error));
+      lastError = error instanceof HttpGlobalError ? error : new HttpGlobalError(String(error));
 
       if (!shouldRetry(lastError, null, config, attempt + 1)) {
         throw lastError;
@@ -1025260,7 +1025360,7 @@ async function executeWithRetry(
   if (lastResponse) {
     return lastResponse;
   }
-  throw lastError ?? new Error('Request failed after retries');
+  throw lastError ?? new HttpGlobalError('Request failed after retries');
 }
 
 /**
@@ -1025272,6 +1025372,24 @@ function handleHttpError(status: number, statusText: string, body?: unknown): ne
 ${renderHandleHttpErrorBody(errorStatusCodes)}
 }
 
+/**
+ * Read a JSON body only when the response actually carries one.
+ *
+ * \`204 No Content\`, \`205 Reset Content\` and \`304 Not Modified\` are defined to
+ * have no body, and an empty body makes \`response.json()\` throw - so a
+ * successful bodyless response would otherwise surface as a JSON parse error.
+ */
+async function readOptionalJsonBody(response: HttpResponse): Promise<Record<any, any> | undefined> {
+  if ([204, 205, 304].includes(response.status)) {
+    return undefined;
+  }
+  try {
+    return await response.json();
+  } catch {
+    return undefined;
+  }
+}
+
 /**
  * Extract headers from response into a plain object
  */
@@ -1025358,12 +1025476,18 @@ function renderHttpFetchClient({
   description: description7,
   deprecated,
   oauth2Enabled = true,
-  hasSerializeHeaders = false
+  hasSerializeHeaders = false,
+  noContentStatusCodes = []
 }) {
   const messageType = requestMessageModule ? `${requestMessageModule}.${requestMessageType}` : requestMessageType;
   const widenPayload = requestMessageModule === void 0 && requestMessageType !== void 0 && requestMessageType !== "null";
   const payloadInputType = widenPayload && requestMessageType ? payloadUnionType({ messageType: requestMessageType }) : messageType;
-  const replyType = replyMessageModule ? `${replyMessageModule}.${replyMessageType}` : replyMessageType;
+  const hasNoContentResponses = noContentStatusCodes.length > 0;
+  const replyType = resolveReplyType({
+    replyMessageType,
+    replyMessageModule,
+    hasNoContentResponses
+  });
   const contextInterfaceName = `${pascalCase2(functionName)}Context`;
   const hasParameters = channelParameters4 !== void 0;
   const hasHeaders = channelHeaders !== void 0;
@@ -1025398,7 +1025522,8 @@ function renderHttpFetchClient({
     servers,
     includesStatusCodes,
     jsDoc,
-    oauth2Enabled
+    oauth2Enabled,
+    hasNoContentResponses
   });
   const code = `${contextInterface}
 
@@ -1025414,6 +1025539,43 @@ ${functionCode}`;
     parameterType: channelParameters4?.name
   };
 }
+function generateResponseParsing({
+  replyMessageType,
+  replyMessageModule,
+  includesStatusCodes,
+  hasNoContentResponses
+}) {
+  if (!replyMessageType) {
+    return `// This operation declares no response body.
+    const rawData = await readOptionalJsonBody(response);
+    const responseData = undefined;`;
+  }
+  let unmarshalExpression;
+  if (!replyMessageModule) {
+    unmarshalExpression = `${replyMessageType}.unmarshal(JSON.stringify(rawData))`;
+  } else if (includesStatusCodes) {
+    unmarshalExpression = `${replyMessageModule}.unmarshalByStatusCode(JSON.stringify(rawData), response.status)`;
+  } else {
+    unmarshalExpression = `${replyMessageModule}.unmarshal(JSON.stringify(rawData))`;
+  }
+  if (hasNoContentResponses) {
+    return `const rawData = await readOptionalJsonBody(response);
+    const responseData = rawData === undefined ? undefined : ${unmarshalExpression};`;
+  }
+  return `const rawData = await response.json();
+    const responseData = ${unmarshalExpression};`;
+}
+function resolveReplyType({
+  replyMessageType,
+  replyMessageModule,
+  hasNoContentResponses
+}) {
+  if (!replyMessageType) {
+    return "undefined";
+  }
+  const payloadType = replyMessageModule ? `${replyMessageModule}.${replyMessageType}` : replyMessageType;
+  return hasNoContentResponses ? `${payloadType} | undefined` : payloadType;
+}
 function generateContextInterface(interfaceName, payloadType, parametersType, headersType, method2) {
   const fields = [];
   if (payloadType && ["POST", "PUT", "PATCH"].includes(method2.toUpperCase())) {
@@ -1025462,7 +1025624,8 @@ function generateFunctionImplementation(params) {
     servers,
     includesStatusCodes,
     jsDoc,
-    oauth2Enabled
+    oauth2Enabled,
+    hasNoContentResponses
   } = params;
   const defaultServer = servers[0] ?? "'http://localhost:3000'";
   const hasBody = messageType && ["POST", "PUT", "PATCH"].includes(method2.toUpperCase());
@@ -1025486,12 +1025649,12 @@ function generateFunctionImplementation(params) {
     target: "payload"
   })}
   const body = payload?.marshal();` : `const body = undefined;`;
-  let responseParseCode;
-  if (replyMessageModule) {
-    responseParseCode = includesStatusCodes ? `const responseData = ${replyMessageModule}.unmarshalByStatusCode(JSON.stringify(rawData), response.status);` : `const responseData = ${replyMessageModule}.unmarshal(JSON.stringify(rawData));`;
-  } else {
-    responseParseCode = `const responseData = ${replyMessageType}.unmarshal(JSON.stringify(rawData));`;
-  }
+  const responseParseCode = generateResponseParsing({
+    replyMessageType,
+    replyMessageModule,
+    includesStatusCodes,
+    hasNoContentResponses
+  });
   const contextDefault = !hasBody && !hasParameters ? " = {}" : "";
   const oauth2ValidateBlock = oauth2Enabled ? `  // Validate OAuth2 config if present
   if (config.auth?.type === 'oauth2' && AUTH_FEATURES.oauth2) {
@@ -1025516,7 +1025679,7 @@ function generateFunctionImplementation(params) {
           response = refreshResponse;
         }
       } catch {
-        throw new Error('Unauthorized');
+        throw new HttpGlobalError('Unauthorized');
       }
     }
 ` : "";
@@ -1025575,7 +1025738,6 @@ ${oauth2TokenBlock}
     }
 
     // Parse response
-    const rawData = await response.json();
     ${responseParseCode}
 
     // Extract response metadata
@@ -1025586,14 +1025748,14 @@ ${oauth2TokenBlock}
       status: response.status,
       statusText: response.statusText,
       headers: responseHeaders,
-      rawData,
+      rawData: rawData ?? {},
     };
 
     return result;
 
   } catch (error) {
     // Apply onError hook if present
-    if (config.hooks?.onError && error instanceof Error) {
+    if (config.hooks?.onError && error instanceof HttpGlobalError) {
       throw await config.hooks.onError(error, requestParams);
     }
     throw error;
@@ -1026390,7 +1026552,7 @@ function getFunctionTypeMappingFromAsyncAPI(object) {
 init_dirname();
 init_buffer2();
 init_process2();
-var HTTP_METHODS = [
+var HTTP_METHODS2 = [
   "get",
   "post",
   "put",
@@ -1026464,7 +1026626,7 @@ function collectErrorStatusCodes(openapiDocument) {
     if (!pathItem) {
       continue;
     }
-    for (const method2 of HTTP_METHODS) {
+    for (const method2 of HTTP_METHODS2) {
       const operation = pathItem[method2];
       collectResponseErrorCodes(
         operation?.responses,
@@ -1026477,7 +1026639,7 @@ function collectErrorStatusCodes(openapiDocument) {
 function getOpenAPIHttpServerUrls(openapiDocument) {
   const servers = openapiDocument.servers;
   if (!Array.isArray(servers)) {
-    return [];
+    return getSwagger2ServerUrls(openapiDocument);
   }
   const urls = [];
   for (const server of servers) {
@@ -1026512,6 +1026674,31 @@ function getOpenAPIHttpServerUrls(openapiDocument) {
   }
   return urls;
 }
+function getSwagger2ServerUrls(openapiDocument) {
+  const { host, basePath, schemes } = openapiDocument;
+  if (!host) {
+    return [];
+  }
+  const httpSchemes = (schemes ?? ["https"]).filter(
+    (scheme) => ["http", "https"].includes(scheme.toLowerCase())
+  );
+  if (httpSchemes.length === 0) {
+    Logger2.warn(
+      `Swagger 2.0 document declares host '${host}' but no http/https scheme; no default baseURL was generated`
+    );
+    return [];
+  }
+  const orderedSchemes = httpSchemes.includes("https") ? ["https", ...httpSchemes.filter((scheme) => scheme !== "https")] : httpSchemes;
+  let normalizedBasePath = basePath ?? "";
+  if (normalizedBasePath === "/") {
+    normalizedBasePath = "";
+  } else if (normalizedBasePath && !normalizedBasePath.startsWith("/")) {
+    normalizedBasePath = `/${normalizedBasePath}`;
+  }
+  return orderedSchemes.map(
+    (scheme) => `'${scheme.toLowerCase()}://${host}${normalizedBasePath}'`
+  );
+}
 function processOpenAPIOperations(openapiDocument, payloads, parameters, headers, oauth2Enabled) {
   const renders = [];
   const servers = getOpenAPIHttpServerUrls(openapiDocument);
@@ -1026519,7 +1026706,7 @@ function processOpenAPIOperations(openapiDocument, payloads, parameters, headers
     if (!pathItem) {
       continue;
     }
-    for (const method2 of HTTP_METHODS) {
+    for (const method2 of HTTP_METHODS2) {
       const render = processOperation(
         pathItem,
         method2,
@@ -1026572,7 +1026759,8 @@ function processOperation(pathItem, method2, path3, payloads, parameters, header
     messageType: replyMessageType,
     includesStatusCodes: replyIncludesStatusCodes
   } = responseMessageInfo;
-  if (!replyMessageType) {
+  const noContentStatusCodes = getNoContentStatusCodes(operation);
+  if (!replyMessageType && noContentStatusCodes.length === 0) {
     return void 0;
   }
   const description7 = operation.description ?? operation.summary;
@@ -1026592,13 +1026780,36 @@ function processOperation(pathItem, method2, path3, payloads, parameters, header
     description: description7,
     deprecated,
     oauth2Enabled,
-    hasSerializeHeaders: headersModel !== void 0
+    hasSerializeHeaders: headersModel !== void 0,
+    noContentStatusCodes
   });
   render.tags = operation.tags ?? [];
   render.pathSegments = splitAddressSegments(path3);
   render.method = method2.toLowerCase();
   return render;
 }
+function getNoContentStatusCodes(operation) {
+  const responses = operation.responses;
+  if (!responses) {
+    return [];
+  }
+  const codes2 = [];
+  for (const [statusCode, response] of Object.entries(responses)) {
+    const code = Number(statusCode);
+    if (isNaN(code) || code >= 400) {
+      continue;
+    }
+    if (!response || typeof response !== "object") {
+      continue;
+    }
+    const { content, schema: schema8 } = response;
+    const hasBody = content !== void 0 && Object.keys(content).length > 0 || schema8 !== void 0;
+    if (!hasBody) {
+      codes2.push(code);
+    }
+  }
+  return codes2;
+}
 function validateOpenAPIContext(context2) {
   const { openapiDocument, inputType } = context2;
   if (inputType !== "openapi") {
@@ -1035166,16 +1035377,6 @@ init_dirname();
 init_buffer2();
 init_process2();
 var MODELINA_INFERRED_NAME2 = "x-modelgen-inferred-name";
-var HTTP_METHODS2 = [
-  "get",
-  "post",
-  "put",
-  "patch",
-  "delete",
-  "options",
-  "head",
-  "trace"
-];
 function getSchemaMap(document2) {
   if ("components" in document2 && document2.components && document2.components.schemas) {
     return document2.components.schemas;
@@ -1035223,7 +1035424,7 @@ function retainPathItem({
     exclude
   });
   let keepAnyMethod = false;
-  for (const method2 of HTTP_METHODS2) {
+  for (const method2 of HTTP_METHODS) {
     const operation = pathItem[method2];
     if (!operation) {
       continue;