tfplugindocs already writes Markdown. duxt does not parse it as another
generated artefact; it reads the directory as a source whose established file
and heading conventions carry more structure than an ordinary manual.

## Steps

::steps
1. **Generate the provider documentation in its own repository.** Keep the
   `docs/` tree tfplugindocs writes, including its provider, resources, data
   sources, functions and guides directories. duxt reads that output; it does
   not run tfplugindocs during the Nuxt build.

2. **Declare the repository as a source flavour.**

   ```ts [app/app.config.ts]
   export default defineAppConfig({
     duxt: {
       sources: [
         {
           repo: 'acme/terraform-provider-acme',
           path: 'docs',
           slug: 'terraform',
           name: 'Terraform Provider',
           flavor: 'tfplugindocs',
           releases: { select: 'minor' }
         }
       ]
     }
   })
   ```

3. **Choose the versions readers should retain.** `releases` discovers provider
   tags using the same `all`, `minor` and `major` policies as any other source.
   Use an explicit `{ tag }` when the reference must remain pinned to one
   release, or add a branch beside the releases for upcoming documentation.

4. **Build and inspect the provider navigation.** duxt derives the provider
   title from the first H1, orders the known tfplugindocs categories, and keeps
   subcategory groups as navigation structure rather than pretending they are
   pages. The Markdown remains ordinary Content data, so search, locale
   fallback, version switching and machine-readable routes need no provider
   integration of their own.
::

## What the flavour changes

Without `flavor`, the directory is an ordinary Markdown source and its folders
are shown as Content finds them. With `flavor: 'tfplugindocs'`, duxt recognises
the generator's categories and frontmatter, derives the provider-aware tree and
normalises the page metadata needed by the shared documentation layout.

It does not rewrite Terraform syntax, run examples, invent missing category
pages or turn provider docs into an OpenAPI-style request client. The source
flavour only interprets the structure already present in the generated
Markdown.

## Checklist

- [ ] tfplugindocs has generated the Markdown tree before the Nuxt build.
- [ ] The source has an explicit `repo` when it uses tags, branches or release
      discovery.
- [ ] `path` points at the generated documentation directory.
- [ ] `flavor` is exactly `'tfplugindocs'`.
- [ ] The source has a stable `slug` and a reader-facing `name` where several
      repositories share the site.
- [ ] The chosen release policy preserves every version that existing links
      must keep reaching.
- [ ] A production build shows provider categories without synthetic group
      routes.