Hedera Hackathon Submission Validator

Hedera ハッカソン提出作品バリデーター

Hedera ハッカソン提出作品のコードベースをレビューし、公式の審査基準に照らして採点します。リポジトリ内のコード、README、ドキュメントから観察できる事実に焦点を当ててください。

ステップ 1: プロジェクトを把握する

コードベースをスキャンして、何が作られたのかを理解します:

1. README.md (または同等のもの) を読み、プロジェクトの概要を把握する
2. 技術スタックを特定する:
   • package.json、Cargo.toml、go.mod、requirements.txt など
   • Hedera SDK の依存関係 (@hashgraph/sdk、hedera-sdk-* など) を探す
3. Hedera の統合ポイントを見つける:
   • Hedera SDK のインポートと使用箇所を検索する
   • HTS プリコンパイルのアドレス (0x167) を検索する
   • Hedera のサービス呼び出し (トークン作成、コンセンサス送信など) を検索する
   • ミラーノード API の呼び出しを検索する
   • エコシステム連携 (ウォレット接続、DEX など) を検索する
4. プロジェクト構造とコード品質を評価する
5. ドキュメントを探す: アーキテクチャドキュメント、設計上の意思決定、ビジネスモデル、ピッチ資料
6. テストと CI/CD の設定を確認する

ステップ 2: 各基準に照らして採点する

提出作品を 7 つの審査基準それぞれに照らして評価します。それぞれについて、スコア (1〜5)、コードベースからの根拠、および具体的な改善提案を提示してください。指針となる質問とスコア 1/3/5 の記述を含む完全なルーブリックについては、references/judging-criteria.md を参照してください。

革新性 (ウェイト 10%)

以下を確認します:

• これは新規性のあるソリューションですか、それとも既存プラットフォームのクローンですか?
• Hedera エコシステムに新しい機能をもたらしていますか?
• README は、何が独自なのかを説明していますか?
• 類似のプロジェクトが存在するか確認します (コードから推測できる範囲で)

実現可能性 (ウェイト 10%)

以下を確認します:

• ソリューションは技術的に堅牢ですか?
• 本当に Web3/ブロックチェーンを必要としていますか? それとも Web2 でも機能しますか?
• ビジネスモデルは文書化されていますか? (リーンキャンバス、マネタイズ戦略)
• コードはドメインへの理解を示していますか?

実行力 (ウェイト 20%) - 最優先

以下を確認します:

• 完成度: これは動作する MVP、PoC、それとも単なる足場 (scaffolding) ですか?
• コード品質: クリーンなアーキテクチャ、エラーハンドリング、テストはありますか?
• UI/UX: フロントエンドがある場合、洗練されていますか、それとも粗削りですか?
• ドキュメント: README の完全性、セットアップ手順、アーキテクチャドキュメント
• 設計上の意思決定: 主要な技術的選択が文書化され、正当化されていますか?
• 戦略: ロードマップやハッカソン後の計画はありますか?
• GTM: 市場投入 (go-to-market) 戦略は文書化されていますか?

統合 (ウェイト 15%) - 優先度高

以下を確認します:

• 使用サービス: どの Hedera サービスが実際に統合されていますか? (HTS、HCS、スマートコントラクト、HFS、スケジュールトランザクション)
• 統合の深さ: 意味のある使用ですか、それとも表面的ですか? (例: ミラーノードへのクエリだけ = 浅い)
• エコシステムパートナー: エコシステムのプラットフォームが統合されていますか? (SaucerSwap、HashPack など)
• 創造性: 明白でない方法で Hedera サービスが使われていますか?
• 複数サービス: 複数の Hedera サービスが組み合わされていますか?

統合の深さを評価します:

• ミラーノードへのクエリのみ = 1 点
• 単一サービス、明白な使用 = 2〜3 点
• 複数サービス、意味のある使用 = 3〜4 点
• 複数サービス + エコシステムパートナー + 創造的な使用 = 5 点

検証 (ウェイト 15%)

以下を確認します:

• 外部ユーザーによるテストの証拠はありますか? (フィードバック文書、ユーザー調査結果、アナリティクス)
• 市場からのフィードバックサイクルは文書化されていますか?
• トラクションデータはありますか? (ユーザー数、登録数など)
• 注: これはコードだけから評価するのは困難です。証拠が見つからない場合はその旨を指摘してください。

成功 (ウェイト 20%) - 最優先

以下を確認します:

• そのソリューションのアーキテクチャは Hedera アカウントの作成を促進しますか?
• 使用によってネットワーク上で意味のある TPS が生成されますか?
• 新しいオーディエンスに Hedera を露出させますか?
• ネットワークへの潜在的な影響は文書化されているか、コードから推定できますか?

ピッチ（10% の重み）

以下をレビューします：

• ピッチの品質の指標としての README の品質
• 課題と解決策が明確に説明されているか？
• 指標や市場データが引用されているか？
• Hedera の役割が明確に述べられているか？
• リポジトリ内にピッチデックやデモスクリプトがあるか？

ステップ 3: スコアカードを生成する

包括的なレポートを出力します：

# Hackathon Submission Review

## Project Summary

- **Name**: [from README]
- **Description**: [1-2 sentences]
- **Tech Stack**: [languages, frameworks, Hedera SDK version]
- **Hedera Services Used**: [list]

## Scorecard

| Section     | Score    | Weight | Weighted | Key Finding        |
| ----------- | -------- | ------ | -------- | ------------------ |
| Innovation  | X/5      | 10%    | X.X      | [one-line summary] |
| Feasibility | X/5      | 10%    | X.X      | [one-line summary] |
| Execution   | X/5      | 20%    | X.X      | [one-line summary] |
| Integration | X/5      | 15%    | X.X      | [one-line summary] |
| Validation  | X/5      | 15%    | X.X      | [one-line summary] |
| Success     | X/5      | 20%    | X.X      | [one-line summary] |
| Pitch       | X/5      | 10%    | X.X      | [one-line summary] |
| **Total**   | **X/35** |        | **X.X**  |                    |

**Estimated Final Grade: X%**

## Detailed Findings

### [Section Name] - X/5

**Evidence**: [What was found in the code]
**Gaps**: [What's missing]
**Quick Wins**: [Specific, actionable improvements]

[Repeat for each section]

## Top 5 Improvements (Ranked by Score Impact)

1. [Highest impact improvement] - affects [criteria] ([weight]%)
2. ...
3. ...
4. ...
5. ...

## Hedera Integration Depth Analysis

- Services detected: [list with evidence]
- Ecosystem integrations: [list or "none detected"]
- Creative usage: [describe or "none detected"]
- Recommendation: [specific services or integrations to add]

ステップ 4: 優先順位付けされたアクションアイテム

スコアカードの後に、最終的な重み付きスコアへの影響順に並べた改善項目の優先リストを提供します。以下に焦点を当ててください：

1. 実行の改善（20% の重み）- コード品質、テスト、ドキュメント
2. 成功の改善（20% の重み）- ネットワークへの影響、アカウント作成フロー
3. 統合の改善（15% の重み）- さらなる Hedera サービスの追加、エコシステムパートナー
4. 検証の改善（15% の重み）- ユーザーフィードバックの仕組みの追加

各改善項目について、工数（簡単な修正、中程度、大規模）とスコアの増加見込みを推定してください。

スコアリング式の参照

Weighted Score = (Score / 5) * (Section Weighting / 100 * 35)
Final Grade = (Sum of Weighted Scores / 35) * 100

重要な注意事項

• 建設的に、意気消沈させないように。不足点は機会として捉えてください。
• スコアは想定ではなく、コードベースで見つかった証拠に基づいてください。
• コードから基準を評価できない場合（例：検証、ピッチ）、その旨を明示し、チームがどのように証拠を文書化できるかを提案してください。
• 各基準の詳細な 1/3/5 の記述子を備えた完全なルーブリックについては、references/judging-criteria.md を参照してください。