Release v0.1.0 - #1

A static scan of all {{% ref %}}/{{% relref %}} shortcodes in
content/en/docs/v1/ surfaced 8 unique ref targets (13 usages across
6 files) that did not resolve:

- seven of them used a leading-slashless target (ref "docs/v1/..."),
  which Hugo treats as a path relative to the calling page. Since
  the calling pages all live under content/en/docs/v1/... the
  resolver looked for docs/v1/docs/v1/... and found nothing. Add
  the leading slash so they are treated as absolute refs against
  content/en/docs/v1/...

- install/providers/hetzner.md pointed Talm readers at
  #1-initialize-cluster-configuration, but a '1. Install Dependencies'
  section was later added ahead of the initialize step (verified via
  git log -S), so the real anchor is #2-initialize-cluster-configuration.
  Update the hetzner.md link and give it the leading slash at the
  same time.

Verified the full fix with a Python walker that re-resolves every
{{% ref %}} target against the actual file tree — the walker goes
from 8 missing targets down to 0 after the change. Hugo still builds
clean (440 pages).

Files touched:

- content/en/docs/v1/install/providers/hetzner.md
- content/en/docs/v1/operations/services/_index.md
- content/en/docs/v1/guides/concepts.md
- content/en/docs/v1/operations/services/monitoring/dashboards.md
- content/en/docs/v1/operations/services/monitoring/alerting.md
- content/en/docs/v1/operations/services/monitoring/logs.md

Assisted-By: Claude <[email protected]>
Signed-off-by: Aleksei Sviridkin <[email protected]>

A static scan of all {{% ref %}}/{{% relref %}} shortcodes in
content/en/docs/v1/ surfaced 8 unique ref targets (13 usages across
6 files) that did not resolve:

- seven of them used a leading-slashless target (ref "docs/v1/..."),
  which Hugo treats as a path relative to the calling page. Since
  the calling pages all live under content/en/docs/v1/... the
  resolver looked for docs/v1/docs/v1/... and found nothing. Add
  the leading slash so they are treated as absolute refs against
  content/en/docs/v1/...

- install/providers/hetzner.md pointed Talm readers at
  #1-initialize-cluster-configuration, but a '1. Install Dependencies'
  section was later added ahead of the initialize step (verified via
  git log -S), so the real anchor is #2-initialize-cluster-configuration.
  Update the hetzner.md link and give it the leading slash at the
  same time.

Verified the full fix with a Python walker that re-resolves every
{{% ref %}} target against the actual file tree — the walker goes
from 8 missing targets down to 0 after the change. Hugo still builds
clean (440 pages).

Files touched:

- content/en/docs/v1/install/providers/hetzner.md
- content/en/docs/v1/operations/services/_index.md
- content/en/docs/v1/guides/concepts.md
- content/en/docs/v1/operations/services/monitoring/dashboards.md
- content/en/docs/v1/operations/services/monitoring/alerting.md
- content/en/docs/v1/operations/services/monitoring/logs.md

Assisted-By: Claude <[email protected]>
Signed-off-by: Aleksei Sviridkin <[email protected]>

Leading-slash ref issues in the v1.2 tree were already fixed by the
v1.0/v1.1/v1.2 refactor. Six remaining broken links survived the
refactor because they were plain markdown links, not ref shortcodes:

- hetzner.md — stale anchor #1-initialize-cluster-configuration → #2
  (talm.md grew a new "## 1. Install Dependencies" section ahead of
  "Initialize Cluster Configuration", which is now ## 2).
- servers-com/_index.md — unversioned /docs/getting-started/... link
  wrapped in a ref shortcode and pointed at /docs/v1.2/.
- operations/faq/_index.md — same fix for /docs/operations/... link
  → ref /docs/v1.2/operations/troubleshooting.
- oidc/enable_oidc.md, oidc/self-signed-certificates.md — replaced
  Hugo-unfriendly relative paths (../sibling/) with absolute ref
  shortcodes so the build fails if the target is renamed.
- virtualization/vm-instance.md — ./DEVELOPMENT.md pointed at a file
  that does not exist; replaced with ref to /docs/v1.2/development.

Assisted-By: Claude <[email protected]>
Signed-off-by: Aleksei Sviridkin <[email protected]>