# Multi-config provider markers (3-segment form) and parser edge cases.
# Exercises ProviderConfigId::FromStr via host_block::provider_id parser,
# plus set_host_provider_id and rewrite_legacy_markers_to_label writer paths.

# --- Well-formed cases ---

# Standard 3-segment labeled marker.
Host do-work-frontend
  HostName 1.1.1.1
  User deploy
  # purple:provider digitalocean:work:382010
  # purple:tags production,web

# A second labeled config for the same provider.
Host do-personal-blog
  HostName 2.2.2.2
  User root
  # purple:provider digitalocean:personal:482001

# Legacy 2-segment marker (must keep parsing as bare digitalocean).
Host do-legacy-vm
  HostName 3.3.3.3
  User root
  # purple:provider digitalocean:382011

# --- Fallback / legacy interpretation cases ---

# Middle segment fails validate_label (uppercase). Must fall back to legacy
# interpretation: provider=azure, server_id="RES:i-12345".
Host azure-vm
  HostName 4.4.4.4
  User azureuser
  # purple:provider azure:RES:i-12345

# Middle segment is a valid label, server_id contains another colon
# (path-like). splitn(3) must keep the entire tail as server_id.
Host aws-vm
  HostName 5.5.5.5
  User ec2-user
  # purple:provider aws:work:us-east-1:i-abc

# Trailing-dash label rejected by validate_label, falls back to legacy.
Host hetzner-bad-label
  HostName 6.6.6.6
  # purple:provider hetzner:work-:12345

# Leading-dash label rejected, falls back to legacy.
Host hetzner-leading-dash
  HostName 6.6.6.7
  # purple:provider hetzner:-work:12345

# Whitespace inside label rejected, falls back to legacy.
Host hetzner-space-label
  HostName 6.6.6.8
  # purple:provider hetzner:work label:12345

# Longer-than-32-char label rejected, falls back to legacy.
Host hetzner-long-label
  HostName 6.6.6.9
  # purple:provider hetzner:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa:12345

# --- Malformed (must yield no provider claim) ---

# Empty middle (between two colons) — must be treated as malformed.
Host empty-label
  HostName 7.7.7.7
  # purple:provider digitalocean::99

# Empty server_id (3-segment).
Host empty-server-id
  HostName 7.7.7.8
  # purple:provider aws:work:

# Empty server_id (2-segment).
Host empty-server-id-legacy
  HostName 7.7.7.9
  # purple:provider aws:

# Empty provider segment.
Host empty-provider
  HostName 7.7.8.0
  # purple:provider :work:42

# Single token, no colon — not a valid marker.
Host no-colon
  HostName 7.7.8.1
  # purple:provider aws

# Trailing whitespace.
Host trailing-ws
  HostName 7.7.8.2
  # purple:provider aws:work:42

# Tab indent (writer must preserve).
Host tab-indent
	HostName 7.7.8.3
	# purple:provider aws:work:i-tab

# 4-space indent.
Host four-space-indent
    HostName 7.7.8.4
    # purple:provider aws:work:i-spaces

# Multiple markers in one block (hand-edit). Reader returns first; setter
# dedupes. Both code paths must round-trip.
Host duplicate-markers
  HostName 7.7.8.5
  # purple:provider aws:i-old
  # purple:provider aws:work:i-new

# --- Colon-bearing server_id (Proxmox-style) ---
#
# These are the highest-risk patterns because the middle segment (`qemu`,
# `lxc`) is ALSO a valid label charset. The label-aware parser treats them
# as labeled markers; the raw 2-segment parser (used by bare-config sync)
# treats them as legacy markers with embedded colons. Both interpretations
# must round-trip cleanly. The v3.7.0 data-loss bug surfaced exactly here.

Host pve-vm-300
  HostName 10.0.0.30
  # purple:provider proxmox:qemu:300

Host pve-ct-101
  HostName 10.0.0.31
  # purple:provider proxmox:lxc:101

Host pve-ha
  HostName 10.0.0.32
  # purple:provider proxmox:ha:cluster-01

# Extreme: many colons in server_id.
Host pve-deep
  HostName 10.0.0.33
  # purple:provider proxmox:a:b:c:d:e

# Provider-specific patterns that LOOK like labels but aren't.
Host fake-label-1
  HostName 10.0.0.34
  # purple:provider fake:work:id-1

Host fake-label-2
  HostName 10.0.0.35
  # purple:provider fake:personal:id-2
