docs/cli-reference/manual/profile.md (1)

30-33: Clarify purpose of "legacy" profile example.

With Pydantic v1 removed, a "legacy" profile using pydantic_v2.BaseModel no longer demonstrates a distinct use case—it's the same as the default. Consider either:

1. Removing this example profile entirely
2. Repurposing it to show a different configuration (e.g., older Python version compatibility, specific field options)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/cli-reference/manual/profile.md` around lines 30 - 33, The "legacy"
profile shown as [tool.datamodel-codegen.profiles.legacy] with output-model-type
= "pydantic_v2.BaseModel" is redundant now that Pydantic v1 is removed; either
delete the entire legacy profile example or change it to demonstrate a genuinely
different configuration (e.g., show compatibility settings such as an older
Python target, custom field options, or an alternate output-model-type) by
replacing the block under [tool.datamodel-codegen.profiles.legacy] with the new
meaningful settings and update the surrounding text to explain its purpose.

docs/cli-reference/utility-options.md (1)

164-167: Same clarification needed for "legacy" profile.

This is the same example as in profile.md. As noted there, a "legacy" profile with pydantic_v2.BaseModel doesn't convey a meaningful use case. Consider updating both locations consistently.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/cli-reference/utility-options.md` around lines 164 - 167, Clarify the
purpose of the "legacy" profile shown by the TOML block with the header
[tool.datamodel-codegen.profiles.legacy] and the example setting
output-model-type = "pydantic_v2.BaseModel": update this doc (and the same
example in profile.md) to either replace the example with a realistic legacy
use-case or add a short note explaining why pydantic_v2.BaseModel is shown
(e.g., compatibility with older codebases, illustrative only), and ensure both
locations use identical wording so readers understand the intended scenario for
the "legacy" profile.

docs/faq.md (1)

218-226: Duplicate "See" reference and outdated filename.

Line 218 and Line 225 both contain "See [Output Model Types]..." which appears redundant. Also, the link target what_is_the_difference_between_v1_and_v2.md seems semantically outdated now that v1 is removed—consider renaming this file in a follow-up if it hasn't already been updated.

📝 Proposed fix to remove duplicate

 See [Output Model Types](what_is_the_difference_between_v1_and_v2.md) for a detailed comparison.

 ```bash
 # For new projects
 datamodel-codegen --output-model-type pydantic_v2.BaseModel ...

-See Output Model Types for more details.

📎 Related: #803

</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

Verify each finding against the current code and only fix it if needed.

In @docs/faq.md around lines 218 - 226, Remove the duplicated "See Output Model
Types" reference (the second
occurrence after the code block) and update the link target to the current,
semantically correct filename used in the repo (replace
what_is_the_difference_between_v1_and_v2.md with the new Output Model Types doc
name if it was renamed); ensure the code block with "datamodel-codegen
--output-model-type pydantic_v2.BaseModel ..." remains unchanged and only the
duplicate reference and outdated link are removed/updated.

</details>

</blockquote></details>

</blockquote></details>

<details>
<summary>🤖 Prompt for all review comments with AI agents</summary>

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @action.yml:

• Around line 17-19: The action output description for the input named
  "output-model-type" is missing the "pydantic_v2.dataclass" option; update the
  description string for output-model-type to include "pydantic_v2.dataclass" so
  it matches the DataModelType enum (DataModelType) values used by the codebase
  and accurately documents supported types.

In @docs/ci-cd.md:

• Line 36: The docs table for the CLI option output-model-type is missing the
  pydantic_v2.dataclass option; update the options list for output-model-type
  to include pydantic_v2.dataclass alongside pydantic_v2.BaseModel,
  dataclasses.dataclass, typing.TypedDict, and msgspec.Struct so the
  documented choices match the actual CLI behavior.

In @docs/dynamic-model-generation.md:

• Line 283: Update the table row that currently reads "Pydantic v2 only | Only
  Pydantic v2 is supported" to avoid redundant phrasing; replace the right-hand
  cell with a clearer alternative such as "Pydantic v2 is the only supported
  output" (locate the row by the exact string "Pydantic v2 only | Only Pydantic v2
  is supported" and update the second cell text accordingly).

In @docs/index.md:

• Line 19: Update the summary bullet that currently reads "Generates Pydantic
  v2, dataclasses, TypedDict, or msgspec output" to explicitly
  include the Pydantic dataclass variant by adding "pydantic_v2.dataclass" (or
  wording like "Pydantic v2 (BaseModel and pydantic_v2.dataclass)") so the docs
  match the rest of the PR where pydantic_v2.dataclass is treated as a distinct
  output type; locate and edit the bullet in docs/index.md to reflect the
  additional supported output.

In @scripts/build_cli_docs.py:

• Around line 458-465: The code currently silently skips legacy model keys like
  "pydantic_v1" when iterating sorted_models (constructed from
  example.model_outputs using the order list ["pydantic_v2", "dataclass",
  "typeddict", "msgspec"]); instead, add explicit validation that fails fast: when
  encountering any deprecated/unknown keys (e.g., model_key == "pydantic_v1" or
  model_key not in the allowed set), raise a clear ValueError (or SystemExit) with
  context including the example identifier and the offending key so stale
  .cli_doc_collection.json data is surfaced; apply the same guard/change for the
  second occurrence handling the same logic (the block around the other occurrence
  corresponding to lines 511-518) so validation happens before rendering.

---

Outside diff comments:
In @docs/openapi.md:

• Around line 273-278: The documented list of supported output formats is
  missing the pydantic_v2.dataclass entry; update the list that currently shows
  pydantic_v2.BaseModel, dataclasses.dataclass, typing.TypedDict, and
  msgspec.Struct to also include pydantic_v2.dataclass so the docs reflect all
  available output model types.

---

Nitpick comments:
In @docs/cli-reference/manual/profile.md:

• Around line 30-33: The "legacy" profile shown as
  [tool.datamodel-codegen.profiles.legacy] with output-model-type =
  "pydantic_v2.BaseModel" is redundant now that Pydantic v1 is removed; either
  delete the entire legacy profile example or change it to demonstrate a genuinely
  different configuration (e.g., show compatibility settings such as an older
  Python target, custom field options, or an alternate output-model-type) by
  replacing the block under [tool.datamodel-codegen.profiles.legacy] with the new
  meaningful settings and update the surrounding text to explain its purpose.

In @docs/cli-reference/utility-options.md:

• Around line 164-167: Clarify the purpose of the "legacy" profile shown by the
  TOML block with the header [tool.datamodel-codegen.profiles.legacy] and the
  example setting output-model-type = "pydantic_v2.BaseModel": update this doc
  (and the same example in profile.md) to either replace the example with a
  realistic legacy use-case or add a short note explaining why
  pydantic_v2.BaseModel is shown (e.g., compatibility with older codebases,
  illustrative only), and ensure both locations use identical wording so readers
  understand the intended scenario for the "legacy" profile.

In @docs/faq.md:

• Around line 218-226: Remove the duplicated "See Output Model
  Types" reference (the second
  occurrence after the code block) and update the link target to the current,
  semantically correct filename used in the repo (replace
  what_is_the_difference_between_v1_and_v2.md with the new Output Model Types doc
  name if it was renamed); ensure the code block with "datamodel-codegen
  --output-model-type pydantic_v2.BaseModel ..." remains unchanged and only the
  duplicate reference and outdated link are removed/updated.

</details>

---

<details>
<summary>ℹ️ Review info</summary>

<details>
<summary>⚙️ Run configuration</summary>

**Configuration used**: Path: .coderabbit.yaml

**Review profile**: CHILL

**Plan**: Pro

**Run ID**: `0cc7e1de-a354-4c43-bfd2-186ae870c109`

</details>

<details>
<summary>📥 Commits</summary>

Reviewing files that changed from the base of the PR and between 01c2f418250f0e05bdfe24beb01b52148ea504f5 and e9230304e47657baea8973a5fe8ee5e8d3674a35.

</details>

<details>
<summary>⛔ Files ignored due to path filters (2)</summary>

* `docs/llms-full.txt` is excluded by none and included by none
* `uv.lock` is excluded by `!**/*.lock`, `!**/*.lock` and included by none

</details>

<details>
<summary>📒 Files selected for processing (15)</summary>

* `README.md`
* `action.yml`
* `docs/ci-cd.md`
* `docs/cli-reference/manual/profile.md`
* `docs/cli-reference/utility-options.md`
* `docs/dynamic-model-generation.md`
* `docs/faq.md`
* `docs/index.md`
* `docs/openapi.md`
* `docs/python-version-compatibility.md`
* `docs/root-model-and-type-alias.md`
* `docs/using_as_module.md`
* `docs/what_is_the_difference_between_v1_and_v2.md`
* `pyproject.toml`
* `scripts/build_cli_docs.py`

</details>

<details>
<summary>💤 Files with no reviewable changes (3)</summary>

* docs/python-version-compatibility.md
* docs/root-model-and-type-alias.md
* pyproject.toml

</details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->

docs/cli-reference/utility-options.md (1)

164-167: Consider centralizing duplicated profile examples.

The exact same profile configuration example appears in both docs/cli-reference/manual/profile.md (lines 30-33) and here. While this duplication might be intentional for self-contained documentation pages, it creates a maintenance burden—future updates would need to be synchronized across both files.

Consider using a documentation include/snippet mechanism if your documentation framework supports it, or add a cross-reference comment noting the duplication.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/cli-reference/utility-options.md` around lines 164 - 167, The dataclass
profile example ([tool.datamodel-codegen.profiles.dataclass] with
output-model-type = "dataclasses.dataclass") is duplicated across documentation;
please centralize it by extracting this snippet into a single reusable
include/snippet (or a shared docs partial) and replace the copies with an
include reference, or alternatively add a clear cross-reference comment pointing
to the canonical snippet location so future edits only need to be made in one
place.