rubrica-builder

Rúbrica Builder — 自己完結型のルーブリックを作成・監査する

後で採点に使う評価ツールを構築します。目標は「見栄えのよい」ルーブリックではなく、自己完結型のルーブリックです。なぜそれほど重要なのでしょうか？システムが採点するとき、AI が見るのはルーブリックと生徒の提出物の2つだけだからです。課題の指示を再び確認することはありません。課題の要件がルーブリックに書かれていなければ、単純に評価されません。ルーブリックは、教授が求めたこととAIが採点することをつなぐ唯一の橋渡しです。

そのため、このスキルは次の1つの問いを中心に展開します。**課題の指示を手元に置かなくても、このルーブリックでこの提出物を採点できますか？**答えが「いいえ」なら、ルーブリックは不完全です。

粒度を決める原則（必ず読んでください）

このスキルはデフォルトでv2のルーブリックを生成します。得点はもはや基準（peso）だけに設定されるのではなく、サブ基準にも独自のpesoがあります。基準のサブ基準のpesoの合計は、その基準のpesoと正確に一致する必要があります（references/modelo-rubrica.mdを参照）。既に読み込まれているルーブリックには、旧モデルのv1（pesoのないサブ基準、純粋なチェックリスト）も引き続き存在しますが、可能な限り、生成するものは常にv2にしてください。

サブ基準にも得点が設定されるようになったため、従来のルール（「単独で減点する必要があるなら、基準に昇格させる」）は、もはや適切な判断基準ではありません。独自のpesoを持つサブ基準は、すでに独立して減点できる要素です。粒度を決める問いは、次のように変わります。

他とは直交する、別の評価領域・側面ですか？ → 独立した基準。すでに基準が扱っている領域内の、具体的で細かな要件ですか？ → 独自のpesoを持つサブ基準。たとえ単独で減点する必要がある場合でも同じです。

粒度の判断基準 — 評価可能な要件ごとに、次のように考えてください。

• 他とは異なる評価領域・側面ですか（すでにある項目の細部ではなく、作業の別の側面ですか）？ → 独自のpesoを持つ基準。
• 独自の減点が必要な場合でも、すでに基準が扱っている領域内の具体的な要件ですか？ → 独自のpesoを持つサブ基準（v2）、またはエビデンス（v1）。

典型的な例：課題で「CRUD エンドポイント」を領域・基準とする場合、各操作（POST、GET、PUT、DELETE）は別個の領域ではなく、その領域内の具体的な要件です。したがって、新しい基準ではなく、pesoを持つサブ基準にします。一方、「データベースへの永続化」は「CRUD エンドポイント」とは直交する領域なので、独立した基準にします。

**ただし、細分化しすぎないでください。**基準の数は多ければよいというものではありません。些細な項目を1〜2点の基準に細分化すると、配点の解像度が薄れ、ルーブリックが煩雑になります。分割の基準は、指示で区別されている実際の領域です。分けること自体にこだわる必要はなく、「独自の減点が必要だから」という理由も不要です（v2ではサブ基準のpesoですでに対応できます）。

**数値に関する補足：**1つの基準に複数のサブ基準をまとめる場合は、拘束力のない補足としてinstrucciones_puntuacionを使ってください（例：「エラー処理がない場合は二重に減点する」）。サブ基準間の配点は、それぞれのpesoですでに示されるため、文章で説明する必要はありません。

始める前に：モデルを読む

references/modelo-rubrica.md を読んでください。スキーマの正式な情報源（実際の Pydantic を反映）であり、両方のバージョンについて説明しています。v1 は既存のルーブリック向けで、サブ基準に peso がありません。v2 はサブ基準ごとに独自の peso があり、このスキルがデフォルトで生成するバージョンです。また、modo_consolidacion／extensiones_personalizadas についても説明しています。Active-IA のポータブル JSON によって、このフィールドは「Cargar criterios」に貼り付ける JSON の中に含まれるようになりました（任意です。なくても問題はなく、フォームは変更しません）。このスキルは、可能な限りこれらの項目を常に補完します。採点者が根拠のあるファイルを読まないのであれば、ルーブリックはそれだけでは十分ではありません。また、課題文を調整する（またはルーブリックを作成する）場合は、references/limites-corrector.md も読んでください。採点者が評価できることと、できないこと（リンク、画像、実行、コード／PDF のいずれか一方のフローのみ）について、実際の統合サービスに即して説明しています。リポジトリの落とし穴にも注意してください。

• docs/specs/Rubrica.md では nota_final を使用していますが、誤りです。正しくは nota_maxima です。
• 古い skills/rubricas/ スキルは、基準ごとに puntaje_maximo を使い、サブ基準がありません。v1 とも v2 とも異なる廃止済みモデルなので、無視してください。
• 基準の重みは peso です（puntaje_maximo ではありません）。合計は 100 でなければなりません。
• schema_version は基準の JSON に含めません。これはフォームの別フィールドです。ルーブリックが v2 であることを示すのは、サブ基準に peso があることです。JSON に schema_version を決して記述しないでください（「出力形式」を参照）。

必要な入力

モード	必要なもの
CURAR	課題文全体 ＋（任意）実際の提出形式（コードまたは PDF）。
CREAR	提出課題の課題文全体（テキスト、PDF、画像、表）。
AUDITAR	確認する課題文 ＋ 既存のルーブリック（JSON）。
TEST	ルーブリック（JSON）＋生徒の提出物（ファイル、フォルダー、.zip または .txt）。

課題文がない場合は、推測せずに依頼してください。課題文がなければ、ルーブリックで何を評価すべきか分かりません。推測で作ったルーブリックこそ、このスキルが解決しようとしている問題です。

課題文に評価に関わる画像、表、図、模式図が含まれている場合は、ルーブリック内のテキストに変換してください（基準の descripcion または evidencias に記載します）。採点 AI はその画像を見ず、ルーブリックだけを読みます。テキストに書かれていない内容は、存在しないのと同じです。

モードの判定

• 課題文があり、採点できるか確認する／課題文を調整する依頼（「これは AI で採点できますか？」「この TP を調整して」「写真を求めていて、コードの課題です」など）→ CURAR。
• 課題文だけがあり、ルーブリック／基準を作成する依頼 → CREAR。
• 課題文とルーブリックの JSON がある → AUDITAR。
• ルーブリックと生徒の提出物がある（試す／テストする） → TEST。
• どれか判断できない場合は、4 つのうちどれを希望するのか尋ねてください。

CURAR は CREAR より前に行う上流の工程です。ルーブリックの作成中に、採点フローを妨げる要件を見つけた場合（「CURAR モード」を参照）、その幽霊のような基準を黙って書き加えてはいけません。いったん止めて、まずその点を調整してください。

---

CURAR モード — 課題文を採点フローに合わせる

ルーブリックを作成する前に、あまり問われないことを確認します。この課題文は、そのまま AI で採点できますか？ 採点者には厳格な制約があります（references/limites-corrector.md を読んでください）。リンクは開かず、コードモードでは画像を破棄し、コードまたは PDF のどちらか一方のフローだけを採点し、何も実行しません。課題文がそのいずれかを求めていると、ルーブリックがどれほど忠実でも、その点は採点されません。CURAR はそうした点を検出し、課題の意図を損なわずに解決します。

目標は課題文を切り捨てることではありません。採点フローを一つに保ち、可能な箇所では、教育上の目標を維持しながら、そのフローで扱えるよう要件を調整します。調整できない内容は削除せず、残したうえで手動採点が必要な項目として示します。

重要な違い：課題文 ≠ ルーブリック

• 課題文から重要な内容が失われることは決してありません。 内容を調整するか、そのまま維持します。
• 修正不可能な項目を含めないのはルーブリックです。 「除外する」が適用されるのはルーブリックだけです。AI が評価できない内容は、基準として記載しません。課題文にはそのまま残します。

フローを妨げる項目の3つの扱い方

1. 調整する（推奨）。 要件を書き換えて、単一のフローに組み込めるようにし、AI で採点可能な状態を維持しながら、意図を保ちます。例：

   • 「リポジトリのリンクを提出してください」 → 「プロジェクトの .zip を提出し、アップロードされたことを確認できるよう、README にリポジトリの URL を記載してください。」
   • 「プログラムの出力画像を添付してください」 → 「その出力を画面に表示する／プロジェクト内の .txt に出力を保存してください。」
   • 「アーキテクチャ図を提示してください」 → 「README またはコードのコメントにアーキテクチャを記述してください。」
   • 「デプロイをオンライン状態にしてください」 → 「デプロイのコードと手順を記載した README を含めてください。証拠はコードを基に確認します。」

2. 維持＋手動採点。 重要な項目でも、フローを崩さずに調整できない場合（典型例：動画による弁明）は、課題文にそのまま残します――削除しません――そして報告書に次のように記載します。「これは AI では採点できません。課題文には残し、手動で採点します。ルーブリックには含めません。」（弁明動画には、実際に専用のチャンネルがあります：スキル active-ia-video-feedback。）

3. 除外する（ルーブリックからのみ）。 成績評価上、補足的な項目（装飾的なリンクや提出用の zip など）であれば、基準として記載しません。課題文には残します。

フローは対話形式です

CURAR が重要なケースを独断で決めることはありません。次のように進めます。

1. 課題文のうちフローを妨げる項目をすべて検出します（references/limites-corrector.md と照合してください）。各項目について、課題文から引用して根拠を示します。
2. 課題文の要件に応じて、主要なフローを決めます――コードまたは PDF。課題文にコードと PDF のレポートが混在していて、どちらか明確でない場合は、どちらの形式にするか質問します。
3. 各項目について、具体的な推奨案を示し、どうするかを質問します。例：

   「提出形式でリンクを求めていて、これがフローを妨げています。.zip を求め、アップロードされたことを確認できるよう README にリポジトリを記載するのがおすすめです。このように調整しますか、それとも手動採点に残しますか、あるいは除外しますか？」

4. ユーザーの決定を適用して、次の項目に進みます。
5. 調整結果の報告書と、書き直した課題文を提出します（以下の形式を参照）。

フローを妨げるものがない場合は、その旨を伝えます。課題文はそのまま採点可能であり、調整は不要です。問題をでっち上げないでください。

CURAR の出力形式

1. 調整結果の報告書 — 検出した項目ごとに記載：

## Curado de la consigna

Flujo de corrección recomendado: <código (solo_codigo / web_completo / proyecto_completo) | PDF>

- [<ADAPTADO | MANUAL | SACADO-DE-RÚBRICA>] <qué pide la consigna, citado>
  - Por qué rompe el flujo: <límite estructural concreto>
  - Cura aplicada: <qué se hizo y, si adaptado, cómo quedó el texto>
- ... (un ítem por punto)

Veredicto: <corregible tal cual | corregible con estos ajustes | requiere corrección
manual de algunos puntos>

2. 書き直した課題文 — 調整後の全文を1つのブロックにまとめ、元の意図を忠実に保ちます。調整済みの項目は書き換え、手動採点の項目には「手動で採点」と明記します。CREAR にそのまま渡せる状態にします。

ユーザーが希望したら、調整済みの課題文を使って CREAR に続けます。そうすれば、生成されるルーブリックは、単一のフローで100％採点可能になります。

---

CREAR モード

目的：課題文を、完全かつ自己完結したルーブリックに変換します。

1. 課題文全体を読み、要件を抽出します。 評価可能な項目をすべて列挙します。求められる機能、技術的な制約（言語、フレームワーク、バージョン）、提出条件（公開リポジトリ、形式、成績に影響する場合は締め切り）、必須の検証、必須の構成、禁止事項を含めます。課題で明示された各要件は、いずれかの基準または証拠に反映させる必要があります。すべて課題文の記述に基づかせます。課題文にない内容は含めません。

2. グループ分けは、固定数ではなく減点の粒度に基づいて行います。 各基準は独立した採点項目です（「粒度を決める原則」を参照）。各要件にテストを適用してください。教授が個別に減点できるようにしたい項目は独立した基準とし、より大きな項目の内部検証に当たるものはサブ基準にします。目安として基準数は通常4～12個ですが、数は実際の採点項目の数に従い、上限やノルマはありません。課題での重要度に応じてpesoを割り当て、主要な項目ほど重くします。合計は必ず100にしてください。

3. 各基準を、証拠と独自のpesoを持つサブ基準に分解します（v2）。 証拠は採点の要です。提出物だけを見て確認できる、真偽が判定可能な主張にしてください。「POST /productosのルートが存在する」は良い証拠ですが、「コードがきれいに書かれている」は証拠になりません（主観的で、検証できないためです）。各サブ基準には、少なくとも1つの証拠が必要です。さらに、各サブ基準にpesoを割り当て、合計が親基準のpesoと完全に一致するようにします。

   • 課題の指示や各サブ基準の相対的重要度から明確な配点がわかる場合は、それを使います。
   • 明確な配点がない場合は、**最大剰余法（ハミルトン方式）**で均等に配分します。base = floor(peso_criterio / n)、 resto = peso_criterio - base * nとし、最初のresto個のサブ基準（順番どおり）にbase + 1を、残りにbaseを割り当てます。例：peso: 25の基準にサブ基準が3つある場合→base=8、resto=1→9, 8, 8（合計25）。

4. modo_consolidacionを決定します（必要であればextensiones_personalizadasも設定します）。基準と証拠を作成したら、各証拠を検証するために採点者がどのファイルを読む必要があるかを再確認し（references/limites-corrector.mdのモード別拡張子一覧を参照）、次から選択します。

   • 評価対象が純粋なソースコードだけで、読む必要のあるHTML／CSSやREADMEがない場合→solo_codigo。
   • Webプロジェクト（HTML／CSS／設定用JSON）の場合→web_completo。
   • README／Markdown、YAML、SQL、シェルスクリプト、.properties、.gradleなども読む必要がある場合（実行手順のドキュメント、マイグレーション、設定など）→proyecto_completo。
   • 課題で、事前定義されたどのモードでもカバーされない拡張子のファイル（ノートブックの.ipynb、.r、.dart、データセットの.csvなど）が必要な場合→personalizado。必要な拡張子を、extensiones_personalizadasに正確に列挙します（先頭にピリオドを付けます。例：.ipynb）。
   • **必須のクロスチェック：**作成済みの各証拠を確認し、その証拠が含まれるファイルが選択したモードでカバーされていることを確かめます。モードが読み込まないファイルに関する証拠は、要件を省略するのと同じくらい役に立ちません。採点者がその証拠を確認できないためです（拡張子フィルターについてはreferences/limites-corrector.mdを参照）。

5. 減点と不合格条件。 課題にペナルティ（リポジトリが非公開、コンパイルできないなど）や、成績に上限を設けるルール（盗用、主要要件の不足）が定められている場合は、それをモデル化します。penalizacionesは割合を減点し、condiciones_desaprobacionは上限（nota_maxima）を設定します。課題にこれらについての記載がない場合は[]のままにし、教授が求めていないペナルティをでっち上げないでください。

6. スクリプトで検証します（「必須の検証」を参照）。

7. 以下の出力形式で提出します。

---

AUDITARモード

ここでは、評価を専門とする教授として批判的に分析します。課題の指示とルーブリックの草案を受け取り、ルーブリックを課題に忠実で、厳密かつ完全なものにし、自立して採点できるようにすることが目的です。次の順に確認してください。

ステップ0 — v1からv2への移行（ルーブリックが古い場合）

コンテンツを監査する前に、モデルを確認してください。どのサブ基準にも peso がない場合、ルーブリックは v1 です。この監査の一環として v2 に移行してください。 これは任意ではなく、確認する必要もありません。最適なルーブリックは常に v2 です。 移行時の絶対ルール：情報を失わないこと。既存のすべての基準、サブ基準、説明、エビデンスを保持し、変更するのは構成方法だけです。移行で変更するのは criterios と subcriterios のみです。ルーブリックの titulo、descripcion、metadata、 penalizaciones、condiciones_desaprobacion は、元の v1 とまったく同じ状態に保ちます（変更が必要な場合は、移行自体ではなく、Contradicciones、Omisiones など、監査の別の手順で行います）。

peso を追加するだけでは不十分な理由： v1 では、教授が CRUD の POST、GET、PUT/DELETE をそれぞれ別に減点できるようにしたい場合、基準をそれぞれ作るしかありませんでした。サブ基準には点数がなかったためです。この技術的な制約だけを理由に、実際には複数に分割された同じ領域である v1 基準が 2 つ以上見つかることはよくあります。適切な移行とは、それらのグループを見つけて、サブ基準を持つ 1 つの v2 基準に再統合することです。既存の項目に peso を付けるだけではありません。

a) 既存の基準を実際の領域ごとにグループ化します。 各基準について、「粒度を決める原則」と同じテスト（異なる領域か、同じ領域の別のインスタンスか）を使って、他の基準とグループになるかを判断してください。 基準を統合するべきグループの兆候：

• 対象だけが異なる並行した名前のパターン：「Endpoint POST」、 「Endpoint GET」、「Endpoint PUT/DELETE」；「Crear relación Alumno」、「Crear relación Curso」。
• 課題では、同じ列挙された指示の項目として示されている（「CRUD は作成、読み取り、更新、削除をサポートすること」など）。作業の別々のポイントとして示されているわけではありません。
• どれか 1 つに失敗しても、別のものに失敗した場合と異なる種類のエラーにはならず、異なるインスタンスに同じチェックを適用したものです。

統合しない兆候（独立した基準として残します）：ルーブリックの目次を作ると、それぞれが異なる性質の内容を評価しているため、別々の行にするのが適切な場合です（例：「永続化」と「ドキュメント」と「セキュリティ」）。

b) 統合する 2 つ以上の基準からなる各グループについて、次のように 1 つの v2 基準を作成します。

• 新しい基準の peso = 統合する各基準の peso の合計（点数を失いません）。
• nombre／descripcion = 元の名前を要約した、共通の領域。
• 元の各基準を、新しい基準の1 つのサブ基準にします。
  • サブ基準の peso = その基準が持っていた peso をそのまま引き継ぎます（そのため、ここではハミルトン法は不要です。重み付けはすでに存在し、それを 1 段階下げるだけです。15+15+15=45＝新しい基準の peso となり、自動的に一致します）。
  • descripcion = 元の基準の説明。
  • evidencias = その基準が v1 で持っていたすべてのサブ基準のエビデンスを、一字一句そのままコピーしたもの（言い換えたり要約したりしないでください。これらは検証可能な記述であり、文言を変えると検証対象が変わる可能性があります）。すべてを 1 つのリストにまとめ、その v1 サブ基準の説明が新しい情報を加える場合は、エビデンスとして追加します。
  • 元の基準に instrucciones_puntuacion があった場合は、そのルールがどのサブ基準に対応するかを示して、新しい基準の instrucciones_puntuacion に移します（このフィールドは基準レベルでのみ有効です）。

例：C2: Endpoint POST (peso 15)、C3: Endpoint GET (peso 15)、 C4: Endpoint PUT/DELETE (peso 15) → C2: Endpoints CRUD (peso 45) という 1 つの基準に統合し、サブ基準を C2.1（peso 15、元は C2）、C2.2（peso 15、元は C3）、C2.3（peso 15、元は C4）とします。 c) 単独で残る基準（グループを形成せず、もともと独自の領域だったもの）の場合：重みのない v1 の下位基準が複数あるなら、そのときは Hamilton（または課題の指示で明確な重み付け）で配分します。ここでは引き継ぐ元の重みがないためです。要件を部分ごとに重み付けするのは今回が初めてです。

d) 基準の peso の合計が 100 になるよう再計算します。 統合しても合計（統合する重みの合計）は維持されるため、通常はこれだけで整います。整わない場合は、どこかの統合に誤りがあります。

e) （任意、仕上げ） 統合後に欠番が残らないよう、基準の id を連番に振り直します。バリデーターでは必須ではありませんが、ルーブリックが読みやすくなります。

f) 続行する前に完全性を確認します。 この手順は必須であり、任意ではありません。「情報を失わない」というルールを支えるものです。元の v1 のルーブリックを要素ごとに確認し（各基準、各下位基準、各エビデンス、各 instrucciones_puntuacion）、それぞれが v2 の結果のどこかに、基準、下位基準、またはエビデンスとして記載されていることを確認します。意図的に移行しないと決めたもの（たとえば、手順 4「創作」で課題の指示に裏付けられていないと特定されたもの）がある場合、移行中に黙って削除してはいけません。手順 0 の時点ではそのまま残し、理由が記録されるよう、該当する監査手順で削除してください。

g) 発見事項の要約で移行内容を報告します（「出力形式」を参照）。criterio/subcriterio v1 → dónde quedó en v2 の対応表（何を統合したか、新しいどの領域にどの重みで配置したか、何がそのまま残ったか）と、項目 (f) の完全性確認で欠落が見つからなかったことの確認を記載します。

ルーブリックが v2 になったら（たった今移行した場合も、すでに v2 だった場合も）、以下の内容監査の手順に進みます。

1. 矛盾。 ルーブリックが課題の指示と食い違っている箇所です。典型的な例：課題で何かを削除する／使用しないよう求めているのに、ルーブリックでは任意としていたり、残すことを評価したりしています。ルーブリックの記述を課題の指示に合わせて修正してください。

2. 欠落。 ルーブリックで評価されていない、課題の明示的かつ重要な要件です。提出条件、具体的な検証、技術的な制約、必須の構成、実行などが該当します。基準、下位基準、またはエビデンスとして追加してください。これは最も重大な不備です。欠落したものは、決して修正されません。

3. 要件の希薄化。 ここまで来るとルーブリックはすでに v2 になっています（必要であれば手順 0 で移行済みです）。そのため、実際の希薄化はもはや「独自の重みを持たない下位基準」ではありません（この問題はモデルが自動で解決します）。別の問題です。次の点を確認してください。

   • 領域の配置が不適切： 評価の別次元に当たる要件（「粒度を決める原則」を参照）が、対応していない基準の下位基準として埋もれています → 独立した基準に昇格させ、重みを調整してください。
   • 下位基準の重み配分が不適切： 重要な下位基準の peso が大きな基準内で小さく設定され、課題の指示における実際の重要度が反映されていません（例：課題の指示では重みが異なるのに、均等に配分している）→ 下位基準間の重みを調整してください（合計は基準の peso と一致させる必要があります）。
   • 内訳のない残余： 重要な基準の下に下位基準が 1 つだけあり、その下位基準がすべての peso を占めていますが、実際には個別の要件が複数含まれており、peso を持つ下位基準に分けたほうがよい状態です。採点時に実際の粒度を確保できるよう、内訳を追加してください。

4. 創作。 ルーブリックに含まれているものの、TPのどこにも裏付けがない基準、加点、ルールです。削除してください。ルーブリックは課題の要件より緩くても厳しくてもならず、忠実な鏡である必要があります。（両刃の剣に注意してください。採点者が提出物だけを見て確認できない証拠も追加しないでください。例：「動画を提出した」「リポジトリが公開されている」などは、作り上げた情報です。受け取った資料で確認できない場合、採点対象の証拠にはなりません。）

5. 視覚的要素。 TPに評価上重要な画像／表／図解があり、ルーブリックのテキストに反映されていない場合は、追加してください。

6. 統合モード。 ルーブリックにどのmodo_consolidacionが設定されているか確認し（設定がない場合、バックエンドはsolo_codigoを想定します）、証拠を読むために必要なすべてのファイルの拡張子に対応していることを確認してください（一覧はreferences/limites-corrector.md）。現在のモードが対応していない拡張子のファイルに依存する証拠が見つかった場合（よくある例：README.mdの確認を求めているのに、.mdを含まないsolo_codigoモードが設定されている）、これは基準の欠落と同じくらい重大な構造上の欠陥です。証拠の記述がどれだけ適切でも、採点者がそのファイルを読むことはありません。モードをweb_completo／proyecto_completoに変更するか、正確な拡張子を指定してpersonalizadoに変更し、指摘事項に記載してください。

7. 重みの調整。 基準の追加、削除、統合（ステップ0からの移行を含む）を行った場合は、合計が再び正確に100になり、各基準のサブ基準の合計もその基準のpesoと一致するよう、pesoを再計算してください。課題で示された相対的な重要度を尊重してください。

8. スクリプトで検証してください。

9. 出力形式（指摘事項の要約を含む）に従って提出してください。

---

TESTモード — 採点をシミュレーションする

有効なルーブリックだからといって、適切に採点できるとは限りません。TESTモードでは、特定の提出物に対して実際に採点を実行し、点数とフィードバックを表示することで、アップロード前にルーブリックが必要な評価の違いを判別できるか確認できます。

システムのパイプライン（コードの統合＋採点プロンプト）を再現しますが、N8N→Geminiではなく、ClaudeのCLIで採点を実行します。Claudeは本番モデルの代替として動作します。結果は参考値であり（別のモデルを使用するため）、Geminiが出す最終スコアと同一ではありませんが、ルーブリックの問題を見つけるのに役立ちます。

python scripts/simular_correccion.py \
  --rubrica <rubrica.json> \
  --entrega <archivo|carpeta|.zip|.txt> \
  --materia "Nombre de la materia" \
  --alumno  "Nombre del alumno" \
  --modo solo_codigo            # o web_completo | proyecto_completo | personalizado

• ルーブリックのJSONにmodo_consolidacionがすでに含まれている場合（現在はCREAR/AUDITARが生成します）、--modoは省略可能です。スクリプトが自動的にその値を使用します。ルーブリックに設定されているモードを変更したい場合にのみ、手動で指定してください。
• --no-runを指定すると、資料を準備してコマンドを表示しますが、claudeは実行しません（モデルが受け取るprompt_correccion.txtを確認するのに便利です）。
• ルーブリックがtipoフィールドのないCriteriosStructureの場合は、--tipo TPを指定してください。
• --modo personalizadoの場合は、--ext ".ipynb,.sql"を指定してください（または、JSONにextensiones_personalizadasがすでに含まれていれば、その値が使用されます）。
• prompt_correccion.txt（実際に使われた資料）とcorreccion.json（結果）が保存されます。

結果の読み方。 スクリプトはルーブリックに照らして採点結果を検証し、基準が評価されていない、スコアが重みを超えている、合計が一致していない、または存在しない減点／条件が適用されている場合に通知します。ただし、重要なのはあなた自身の判断です。スコアは提出物の実際の品質を反映していますか？フィードバックは具体的な証拠を挙げていますか？曖昧な基準があり、モデルが判断に迷っていませんか？何かが合わない場合、改善すべきなのはたいていルーブリックです（曖昧な説明、検証できない証拠、偏った重み配分など）。CREAR/AUDITARに戻って改善し、もう一度テストしてください。

採点者が参照する内容（ルーブリック設計で重要）

採点ではルーブリックの全項目が使用されます。各基準について、id、nombre、 peso、descripcion、instrucciones_puntuacion、エビデンスを含む サブ基準に加えて、penalizaciones、condiciones_desaprobacion、 metadata が渡されます。そのため、エビデンスが重要です。モデルが確認するチェックリストになります。

v2では、各サブ基準のpesoも渡され、採点結果には基準ごとの subcriterios_evaluadosの内訳が含まれます（各サブ基準のスコア、状態、 フィードバックを記載し、それらの合計は基準のpuntaje_obtenidoと一致する 必要があります）。v1では、サブ基準のpesoも、レスポンスの subcriterios_evaluadosもありません。それ以外は従来どおりです。 scripts/simular_correccion.pyは、バリデーターと同じ方法でバージョンを推定し （サブ基準にpesoがあるかどうかで判定）、それに応じてプロンプトと結果の 検証を調整します。

堅牢性を高めるための推奨事項：各基準のdescripcionは、それだけで内容が 伝わるように記述してください。エビデンスで確認する内容を要約しておくと、 連携先から想定より少ないコンテキストしか送られない場合でも、採点が正しく 機能します。

---

必須の検証

ルーブリックを提出する前に、JSONを保存して次を実行してください。

python scripts/validar_rubrica.py <ruta_al_json>

（標準入力から読み込む場合はpython scripts/validar_rubrica.py -を実行します）

このスクリプトは実際のバックエンドのルールを再現しています。検証に合格すれば、 システムはルーブリックを受け付けます。不合格の場合は、修正すべき箇所 （重みの合計、ID、パターン、空のエビデンス、nota_finalとnota_maximaの 不一致など）が具体的に示されます。**バリデーターが合格と判定する前に、 ルーブリックを提出しないでください。**不合格の場合は修正して、もう一度実行 してください。手軽に実行でき、バックエンドで差し戻されるのを防げます。

バリデーターはv1とv2に対応し、サブ基準にpesoがあるかどうかで バージョンを推定します（Active-IAのフロントエンドと同じです）。schema_versionを 渡す必要はありません。v2では、すべてのサブ基準にpesoがあり、その合計が 基準のpesoと正確に一致する必要があります。v1では必須ではありません。 バージョンを明示的に指定する必要がある場合（たとえばv1の動作を明示的に テストする場合）は、--schema-version 1|2を使用してください。

出力形式

必ず次の順番で出力してください。

1.（AUDITARの場合のみ）確認事項の概要 — JSONの前に簡潔に記載します。

## Hallazgos
- Migración v1→v2: <"la rúbrica ya era v2, sin cambios" | mapeo
  "criterio/subcriterio v1 → dónde quedó en v2" con cada fusión y su peso
  heredado | "no aplica">
- Verificación de completitud: <"OK, todo el contenido v1 está presente en
  el v2" | qué faltaba y se agregó>
- Contradicciones: <qué y dónde, o "ninguna">
- Omisiones: <qué requisitos faltaban, o "ninguna">
- Invenciones: <qué se quitó, o "ninguna">
- Modo de consolidación: <"OK, cubre todas las evidencias" | qué extensión faltaba
  cubrir y a qué modo se subió>
- Ajuste de pesos: <cómo quedó el reparto>

2. CriteriosStructureのJSON — ```jsonブロックに記載します。 「Cargar criterios」ボタンに貼り付けられる形式にしてください（編集モーダルも Active-IAのポータブルJSONに対応しています）。次の項目を含めます： titulo、descripcion、puntaje_maximo、metadata、criterios、 penalizaciones、condiciones_desaprobacion、および必ず modo_consolidacion。modo_consolidacionが"personalizado"の場合は、 extensiones_personalizadasも含めます（そうでない場合は省略するか、nullに してください）。以前はJSONのコピー／貼り付け時に失われていたフィールドですが、 現在はルーブリックに含まれ、フォームに自動入力されます。schema_versionは 含めないでください。これはルーブリックのペイロードとは別のフィールド （tipo／numero／anioなど）であり、CriteriosStructureには含まれません。 ルーブリックがv2であることを示すのは、各サブ基準のpesoです。Active-IAの フロントエンドが自動的に推定します。

3. フォームのフィールド — 内容ではなくインスタンスの識別情報です。JSONには 含めず、別途入力してください。

Para completar en el formulario de la rúbrica:
- tipo: <TP | PARCIAL_1 | ... según la consigna>
- numero: <ej: 2 para el TP2>
- anio: <año académico>
(materia_id lo elegís vos según la materia)

4. バリデーターの確認 — 「✅ RÚBRICA VÁLIDA」の行を貼り付けてください。

有効なv2ルーブリックの全項目を含むひな形として、 assets/ejemplo-rubrica.jsonを参照してください（各サブ基準のpesoと、 適切に選択されたmodo_consolidacionを含みます。この例では、基準の1つが README.mdを評価するため、proyecto_completoを使用しています。 solo_codigo／web_completoには.mdが含まれません）。後方互換性のため、 examples/rubrica-tp-cli-v1.jsonはv1の例です（サブ基準にpesoはありません）。

ルーブリックを台無しにするミス（避けてください）

• 配点の合計が100にならない — 最もよくあるミスです。バリデーターで検出されますが、最初から配点を考えてください。
• 主観的な証拠や、提出物に含まれない情報を求める証拠（「きちんと整理されている」など）。
• 課題の指示にない減点や条件を作る。
• 課題の要件をカバーする評価基準がないままにする。
• 重要な要件を埋もれさせる：別個の評価領域／観点を、それに合わない評価基準のサブ基準として埋め込むのではなく、独立した評価基準にする（「粒度を決める原則」を参照）。
• （v2）pesoがないサブ基準、または合計が親評価基準のpesoと一致しないサブ基準 — バリデーターで検出されますが、最初から配点を考えてください（課題の指示に明確な重みづけがない場合はHamiltonを使用）。
• 些細な項目を1～2点の評価基準に細分化しすぎると、配点の解像度が下がり、ルーブリックが煩雑になります。細分化する際は、実質的な判断材料を基準にし、細かさ自体を目的にしないでください。
• nota_maximaの代わりにnota_finalを使ったり、評価基準ごとにpesoではなくpuntaje_maximoを使ったりする（これは廃止されたV1のモデルです）。
• materia_id／tipo／numero／anioを評価基準のJSONに入れる。これらはフォームに指定する項目であり、インポートするJSONには含めません。
• 独自の証拠が必要とする拡張子に対応していないmodo_consolidacionを選ぶ（例：.mdを含まないsolo_codigoモードでREADME.mdに関する証拠を設定する）。証拠があっても飾りにすぎず、採点者はそのファイルを読みません。必ず、CREARの手順4／AUDITARの手順6で相互確認してください。