[SlavaKatiukha]

Replace MkDocs with Hugo and the shared Virtuozzo documentation theme. Keep the current docs and all 24 published versions, including existing URLs, images, redirects, and code examples.

Changes:

• Move current articles to content/. Add sidebar section links, version menus, search, code copying, and page feedback.
• Use Devbox, Task, and uv for setup, previews, builds, and Python dependencies.
• Add versioned builds, validation, and manual staging and production workflows.
• Remove the old MkDocs tools, theme, and unused files. Update the contributor and deployment guides.

Validation:

• task build
• task hugo:verify
• All 234 Python tests passed on case-sensitive storage.

[HlibAntonov]

I was thinking about straight up updating branches that we decide to keep to Hugo using approach in https://github.com/virtuozzo/cloudscripting-docs/tree/poc/hugo-migration as a template (it is a simple conversion according to AI). It uses current theme native shortcodes not custom ones, updates old product names and links, fix broken links, applies other editorial and some structural changes.
However, if we agree that it is ok to freeze existing versions as is (with all their problems) and that no further edits will be made on these versions, then conversion is not needed. In any case, future versions should be on Hugo so the template can still be used to create the next CS docs version. It will probably be a bit different from older versions, but will give access to our Hugo tools and simplify any further edits.

[HlibAntonov]

Thanks for the thorough work here. Before this merges I want to check the approach against where we're heading with versions, because I think the goals have narrowed since this was scoped.

Our intended version model

• We plan to publish 8.8.1 and later (9 versions today) and retire the older ones. Happy to discuss the cutoff, but we don't expect to keep all 24.
• Old version content stays as is; we only need it rendered through Hugo with the current theme.
• Every future version branch (8.16.1 onward) is authored in Hugo from the start.
• server-docs and infrastructure-docs already publish versions this way: each version branch is a self-contained Hugo site, and one workflow loops over the branches, checks out the theme, builds with the version's base URL and rsyncs to /var/www/webroot/<repo>/<version>/. We'd like cloudscripting-docs to end up on the same model rather than a second one for the same task.

Where the PR's design doesn't match that

1. Conversion is a permanent build step. scripts/migration/release_build.py re-exports each pinned MkDocs commit and re-runs the converter on every task build-all. The converter, page maps and baseline fixtures stay in the critical path for as long as 8.15.1 is published. With a one-time conversion of the branches, the converter runs once and can be removed.

2. No path for Hugo-only versions. load_acceptance_catalog requires every build to have a page map, baseline and exceptions entry in migration/releases/acceptance.json, and the builder rejects a baseline that doesn't bind a passing legacy MkDocs render. A Hugo-first branch has no legacy render to capture. README and docs/deployment.md don't describe how a new release is onboarded, so our next release couldn't ship through this pipeline without extending the tooling.

3. Two build formats for the lifetime of the repo. After migration we'd have 9 releases on the mkdocs path and all new ones on the hugo path, with the old path rarely exercised.

4. Editing an old version is costly. A link fix in 8.12.1 means editing the branch, moving its pin in migration/release-sources.yaml, and regenerating acceptance evidence that was captured with the MkDocs toolchain this PR removes from master.

5. Size. scripts/migration, scripts/deploy and tests/migration are ~8.5k lines of Python plus 736 files under migration/. Most of it guarantees fidelity for versions we expect to retire.

6. The root pin isn't reachable. release-sources.yaml pins root to c779dbee16190019695af0201c822a0307004842, which is not on origin (the validation pin 76628f8a is). As committed, build-release.yml cannot run.

7. Deployment is bundled with the build model. The symlink strategy, hosting contract and runbooks are an operational change on their own, and hosting-contract.yaml currently keeps deployment disabled. The other docs repos deploy with rsync per version today, so I'd like to decide that separately.

Proposal

• Convert 8.8.1–8.15.1 once on their branches with the converter, commit the Hugo content, and drop the MkDocs toolchain there. Each branch becomes a plain Hugo site, same shape as 8.16.1, future branches, and the other docs repos.
• Adopt the server-docs deploy-to-prod.yml loop (branch list, theme checkout, params.version, per-version base URL, rsync) with the version switcher data generated from the same list.
• Reuse from this PR: the theme features (sidebar headings, feedback link, code tabs, dark mode are already ported to the theme branch), the hugo-check.yml CI shape, and check_site as a one-time acceptance check of each converted branch against the live site. The old-URL → new-path data in the page maps can seed per-version redirects.
• Retired versions get a redirect to the nearest kept version or a short notice page.
• If ops want the artifact promotion and symlink switch model, open it as a separate PR that could then apply to all docs repos, not just this one.

Happy to walk through the branch conversion together; the POC converter on poc/hugo-migration already handles the Goldmark differences we hit.