src/Clet/Hosting/CommandLineRoot.cs:353

• IsKnownOptionToken treats -<short> tokens from clet.Options as “known option tokens”, but the parser never actually supports single-dash clet options (only host -j/-f/-i/-t/-o/-r). This means values like --initial -o (for clets that define shortName o) will be rejected as “requires a value”, even though -o should be a valid literal value. Consider removing the token.Length==2 && token[0]=='-' clet-option check, or adding real parsing support for clet short options with an escape hatch for literal values.

        if (token.StartsWith ("--", StringComparison.Ordinal))
        {
            return IsCletOption (clet, token[2..]);
        }

        if (token.Length == 2 && token[0] == '-')
        {
            string shortName = token[1..];

            return clet.Options.Any (opt => string.Equals (opt.ShortName, shortName, StringComparison.OrdinalIgnoreCase));
        }

src/Clet/Hosting/CommandLineRoot.cs:323

• TryReadOptionValue currently rejects any candidate value that matches a known option token (e.g. --json, --output, or any --<cletOption>). This prevents passing legitimate literal values that happen to start with -- (e.g. --title --json or --initial --output). If this stricter behavior is intentional, it would be safer to add an explicit escape hatch (common patterns: -- end-of-options marker, or supporting --initial=<value> / --title=<value>), so callers can still pass such literals when needed.

    private static bool TryReadOptionValue (string[] args, int optionIndex, IClet clet, out string value)
    {
        value = string.Empty;

        if (optionIndex + 1 >= args.Length)
        {
            return false;
        }

        string candidate = args[optionIndex + 1];

        if (IsKnownOptionToken (candidate, clet))
        {
            return false;
        }

        value = candidate;

        return true;
    }