What causes "branding.primary-color: {e}" in astrid-runtime/astrid?

Set primary-color to a valid hex color in '#rrggbb' form (e.g. '#336699').

branding.primary-color: {e}

Error message

branding.primary-color: {e}

What it means

validate_manifest checks [branding].primary-color with validate_hex_color and prefixes any parser error with 'branding.primary-color:'. It fires when the configured color is not a valid hex color (e.g. wrong length, missing '#', non-hex characters).

Source

Thrown at crates/astrid-cli/src/commands/distro/validate.rs:249

                "invites.max-principals must be \"unlimited\" or a non-negative integer (got {cap:?})",
            );
        }
    }

    // Branding — only structural rails. The dashboard interprets the
    // values; the parser just refuses obvious garbage.
    if let Some(branding) = &manifest.branding {
        if let Some(icon) = &branding.icon
            && icon.len() > 64 * 1024
        {
            anyhow::bail!(
                "branding.icon is {} bytes — distros must not embed assets larger than 64 KiB",
                icon.len()
            );
        }
        if let Some(color) = &branding.primary_color {
            validate_hex_color(color)
                .map_err(|e| anyhow::anyhow!("branding.primary-color: {e}"))?;
        }
        if let Some(color) = &branding.accent_color {
            validate_hex_color(color).map_err(|e| anyhow::anyhow!("branding.accent-color: {e}"))?;
        }
    }

    Ok(())
}

/// Enforce a manifest's `[distro].astrid-version` floor against the running CLI.
///
/// Called on the init / `distro apply` path *after* the manifest is fetched and
/// parsed but *before* any prompting or install, so a distro whose `Distro.toml`
/// (fetched from the repo `main` tip) bumps its CLI floor fails fast with an
/// actionable message instead of breaking onboarding mid-flight on an older CLI.
///
/// A manifest with no `astrid-version` floor imposes no requirement.
pub(crate) fn enforce_astrid_version(manifest: &DistroManifest) -> anyhow::Result<()> {

View on GitHub (pinned to affd8760f4)

Solutions

Set primary-color to a valid hex color in '#rrggbb' form (e.g. '#336699').
Match the exact format validate_hex_color accepts (check whether 3-digit shorthand is allowed).
Remove the branding.primary-color key to fall back to the default theme.

Example fix

# before (Distro.toml)
[branding]
primary-color = "blue"
# after
[branding]
primary-color = "#0000ff"

Defensive patterns

Strategy: validation

Validate before calling

fn is_hex_color(s: &str) -> bool {
    let t = s.strip_prefix('#').unwrap_or(s);
    t.len() == 6 && t.chars().all(|c| c.is_ascii_hexdigit())
}

Prevention

Only use #rrggbb literals in branding fields.
Convert from design-tool outputs to hex before pasting.
Run `astrid distro validate` locally before pushing the manifest.

When it happens

Trigger: A Distro.toml with branding.primary-color set to values like 'red', 'FF0000' (no #), '#F00' if shorthand is unsupported, '#GGGGGG', or an empty string.

Common situations: Authors pasting CSS named colors or rgb() values instead of hex; losing the '#' when hand-editing TOML; copy-pasting from design tools that emit 8-digit ARGB or uppercase prefixes.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09). Data as JSON: /api/errors/8358199778a70500. Report an issue: GitHub.