フィーチャーフラグ名の検証

空でないこと、すべて小文字であること、ハイフン区切りの kebab-case か snake_case のいずれか一方であること（同一文字列で両区切りを混在させないこと）、少なくとも2セグメント、enable・feature・ff・rollout・beta などの記述的プレフィックスで始まること、64文字以内、端や連続の区切りを避けること、です。空入力は invalid_input で失敗し課金されません。規約違反は valid を false にした成功ペイロードと順序付き issues リストを返し、継続的インテグレーションが明確な報告でビルドを落とせます。

命名規約が求める内容

空の名前は評価対象がないため即座に invalid_input として拒否されます。第二に、各文字は小文字の ASCII 英字、数字、および区切りのスタイルをちょうど1種類だけ、つまり kebab-case 用のハイフンか snake_case 用のアンダースコアのいずれかでなければなりません。これらの規則は LaunchDarkly 風のキー、Unleash のトグル、社内の多くの JSON や YAML フラグファイルにきれいに対応し、ベンダー固有の方言を発明しません。

入力契約・応答形・エラーの扱い

例の enable-checkout-express は enable プレフィックス付きの有効な kebab-case フラグです。すべての規則を満たすと valid は true、issues は空配列、style は kebab または snake になります。数値は文字列化され、オブジェクトと配列は拒否されます。実装は純粋な parse の tier A のため、ネットワークもタイムスタンプもなくランタイム間でバイト安定です。必須の文字列フィールド name を含む JSON ボディを POST してください（ハンドラは輸送の柔軟性のため alias の flag_name と text も受け付けます）。成功時の応答には常に valid（真偽値）、trim 後の name、style（kebab・snake、または分類不能時は null）、prefix（先頭セグメントまたは null）、順序付き文字列配列の segments、segment_count、has_descriptive_prefix、機械可読コードの安定した順序付きリスト issues、UI 表示向けの短い convention 文が含まれます。名前はあるが規約を破る場合、valid は false で issues に not_lowercase、mixed_separators、missing_descriptive_prefix、too_few_segments、invalid_characters、consecutive_separators、leading_or_trailing_separator、too_long、missing_separator_segments、invalid_pattern などのコードが並び、例外は投げません。リンタとプルリクエストボットが一括で問題を出せます。空・欠落・非文字列の名前だけが invalid_input を投げ、前払い残高は消費しません。

フラグ名検証が役立つ場面

プラットフォームと開発者体験のチームは、この検査をスキャフォールディング生成に組み込み、プレフィックスと区切りスタイルなしの新規フラグが入らないようにします。プロダクト分析と実験ツールはロールアウトキー登録時に同じ規則を使い、mobile・web・backend でプレフィックスごとのダッシュボード集約を揃えます。継続的インテグレーションのジョブはフラグカタログや環境サンプルを触るプルリクエストを走査し、半年後に運用者を迷わせる名前があればビルドを失敗させます。コードレビューボットは候補文字列で API を呼び、趣味のスタイル議論の代わりに issues リストをレビュースレッドへ貼ります。成功呼び出しは公開の基本価格 $0.002 でモデルトークンがないため、移行スクリプトで何千もの名前を検証しても予想外の費用になりにくく、空送信はクライアントエラーとして課金されません。社内の動詞をサポート集合へ写像してプレフィックステーブルを組織のハウススタイルに合わせるか、このエンドポイントを包み、基本規約を通っても方針が禁じるプレフィックスを拒否してください。