機能提案: ミニマルなメタデータバリデーション（rules セクション拡張）

[rizumita]

概要

現在の rules セクションを拡張し、フロントマターのメタデータに対するミニマルなバリデーション機能を追加する提案。

背景・動機

現状の課題

1. 既存ツールの不足: Markdown フロントマターのスキーマ検証ツールは成熟しておらず、CI/CLI向けの決定版が存在しない

   • remark-lint-frontmatter-schema: 2年間更新なし、作者自身が「far less powerful」と評価
   • 多くのプロジェクトが自前で簡易バリデーターを実装している状況

2. Shirushi の現状: doc_id 生成に必要な doc_type 等は読み取るが、検証は行わない

3. ユースケース: ドキュメント管理において doc_id と共に title, tags, category 等の一貫性を担保したいニーズがある

設計原則

• Shirushi のアイデンティティを維持: あくまで「ドキュメントID管理システム」であり、汎用スキーマバリデーターにはならない
• YAGNI: 最小限の機能に留める
• 段階的拡張: 必要に応じて将来拡張可能な設計

提案内容

Phase 1: 基本的なフィールド検証（v0.2 候補）

現在の rules.require_fields を拡張:

rules:
  - when:
      doc_type: "spec"
    require_fields:
      - "version"
      - "owner"
    validate_fields:
      status:
        type: enum
        values: ["draft", "active", "deprecated", "superseded"]
      tags:
        type: array
        min_items: 1

サポートする検証タイプ（ミニマル）

タイプ	説明	例
enum	許可された値のリスト	values: ["draft", "active"]
array	配列の基本検証	min_items: 1, max_items: 10
string	文字列の基本検証	min_length: 1, max_length: 100, pattern: "^[a-z-]+$"

新しいエラーコード

• INVALID_FIELD_VALUE: フィールド値が validate_fields のルールに違反
• MISSING_REQUIRED_FIELD: require_fields で指定されたフィールドが存在しない（既存エラーの明確化）

スコープ外（明示的に対象外とするもの）

以下は対象外とし、将来的にも追加しない方針:

• ❌ ネストしたオブジェクトの検証
• ❌ JSON Schema 完全互換
• ❌ 条件付き検証（if/then/else）
• ❌ カスタムバリデーター関数
• ❌ クロスフィールド検証

これらが必要な場合は、別ツール（remark-lint-frontmatter-schema 等）との併用を推奨。

受け入れ基準

• validate_fields で enum, array, string タイプをサポート
• 検証失敗時に明確なエラーメッセージを出力
• 既存の require_fields との後方互換性を維持
• ADR でスコープ制限の設計判断を記録
• ユーザーガイドに使用例を追加

代替案

1. Option A（現状維持）: Shirushi は doc_id のみに専念し、メタデータ検証は別ツールに委ねる
2. Option B（本提案）: ミニマルな拡張で実用的なメタデータ検証を追加

関連

• 仕様書 Section 6.1 の rules セクション（現在は require_fields のみ）
• 非目的 Section 2.2:「ドキュメント内容の品質チェックは対象外」→ 本提案はこれを維持しつつ、構造的メタデータのみを対象とする

優先度

v0.2 以降（v0.1 の lint / scan 実装完了後）