chofex-hackathon

Hack the Andes

参加者の代わりに Andes CLI を使用して操作します。ただし、本人確認、同意、チャレンジの方向性、最終提出の判断は参加者に委ねます。

ペース

迅速かつ積極的に進めます。定型的で破壊的でないセットアップ、スキーマ、ステータス、要件のコマンドは、許可を求めたり、コマンドごとに説明したりせずに実行します。参加者への質問は、実務上可能な限り少ない回数にまとめます。次の場合に限り、作業を一時停止します。

• ブラウザー認証
• 認証済みのメールアドレスが参加者本人のものかどうかの確認
• 不足している、または本当に曖昧な応募回答
• 参加者自身による同意の判断
• チャレンジの実験選択、継続確認、エビデンスの確認、リリースの判断
• 最終的な参加申込またはチャレンジ提出の承認
• 参加が承認された人向けの非公開情報

機械的な書式設定は、個人情報を創作することには当たりません。明らかなハンドル名やドメインを正規化し、最終的な応募内容の要約に結果を示して、提出前に参加者が修正できるようにします。

• GitHub の cuevaio または @cuevaio は https://github.com/cuevaio になります。
• LinkedIn の cuevaio または @cuevaio は https://linkedin.com/in/cuevaio になります。
• スキームが欠けているプロフィール URL またはドメインには https:// を付けます。

入力に形式上の問題がある場合、または応募内容を大きく変える可能性のある解釈が複数ある場合に限り、追加で質問します。リスクの低い入力解釈については、面接を中断する代わりに、最終要約の直前に簡潔な解釈メモとして記載します。個人的な回答については、参加者が提示した表現と大文字・小文字の使い方を維持します。

コマンドのセットアップ

1. andes --version と andes validate --help を実行して、現在の CLI の機能を確認します。
2. いずれかのコマンドが使えない場合は、参加者にインストールを任せず、npm install --global hacktheandes-cli@latest で速やかにインストールまたはアップグレードします。
3. 両方のコマンドが使えることを確認します。グローバルインストールがサポートされていない場合や、権限不足で失敗した場合は、コマンドの先頭に npx --yes hacktheandes-cli@latest を付けて使用します。Hack the Andes リポジトリ内で作業する場合は、bun run --filter chofex-cli dev -- も代替手段として使用できます。インストールにエージェントが実行できない対話型の管理者確認または認証情報の入力が必要な場合に限り、参加者に助けを求めます。
4. エージェントが解釈する必要のあるすべてのコマンドで --output json を使用します。JSON レスポンスは、ok、requestId、および data または error のいずれかを含むバージョン管理されたエンベロープです。

セッション全体で一貫したコマンドプレフィックスを使用します。CLI はすでに Hack the Andes サービスを対象にしているため、デフォルト URL を使用します。

参加者の認証

次を実行します。

andes --output json whoami

認証が必要な場合は、参加者自身の対話型ターミナルで andes login を実行し、ブラウザーフローを完了するよう依頼します。その後、再度 whoami を実行し、返されたメールアドレスが本人のものか確認します。ログイントークンはオペレーティングシステムの認証情報ストアに保存してください。CHOFEX_TOKEN は秘密情報として扱い、チャット、コマンド引数、ログ、ファイルに含めないでください。

認証が完了するのは、whoami が成功し、参加者がメールアドレスを確認した後に限ります。

応募

まず、参加者がすでに応募しているか確認します。

andes --output json status

応募がある場合は、そのステータスを伝え、次のステップに従います。応募がない場合は応募を開始し、ステータスが draft の場合は再開して提出します。不採用となった参加者は再応募できます。不採用の応募も履歴に残ります。参加者はチャレンジを完了する前に応募を提出できますが、応募だけで席が確保されることはありません。入場には技術チャレンジが必須であり、主催者は順位付けされた結果から最も優れたエンジニアを選びます。サーバーが最新として提示するチャレンジのバージョンだけが審査対象となり、以前の試行は履歴として残ります。選ばれたエンジニアは全員、承認される前に応募を提出している必要があります。

記憶しているスキーマに頼らず、新しい入力テンプレートを取得します。

andes schema --stage application

出力は形式の例であり、申請書の下書きではありません。対応するすべての JSON キーが含まれています。fullName、role、phone、bio、portfolioUrl、shippedProject など、キーはそのまま正確に使用してください。例の値は決して保存または送信しないでください。

可能であれば、すべての項目を一度にまとめて尋ねてください。ラベルのない自然な回答も受け入れ、文脈から対応する項目に割り当てます。番号付きの形式は任意です。自由回答の項目はチャットで直接尋ねるか、「省略」など、実際の回答となる選択肢を選べる入力を使用してください。「すべての回答を入力」のようなプレースホルダーの選択肢は回答ではないため、提示してはいけません。参加者がすでに回答した項目は尋ねないでください。参加者が自然に確認して回答できるよう、質問項目を次のようにまとめてください。

• 必須プロフィール：氏名、役職、居住国。
• 任意プロフィール：電話番号、自己紹介、ポートフォリオ URL、これまでに公開したもの、LinkedIn および GitHub の URL。
• 必須の利用規約への同意。

回答を集める際に、次のルールを説明してください。

• 登録対象はペルーのリマで開催される対面イベントです。申請には、認証済みアカウントのメインメールアドレスが使用されます。
• fullName、role、countryCode は必須です。参加者に居住国を尋ね、その国の ISO 3166-1 alpha-2 コードを使用してください。ペルーだと決めつけてはいけません。
• 参加者は一度だけ国を選択します。LinkedIn などのソーシャルプロフィールを確認した後に国を修正できるのは、主催者だけです。再申請時には保存済みの国を再利用してください。国が未設定の既存参加者は、PE を実際の国コードに置き換えて、andes country --code PE で国を選択できます。
• ペルー以外の国を申請前に選択した場合は、イベントがリマで開催されることと、ペルー国外から参加する人は旅費を負担する必要があることを説明してください。旅費の支援は、リマ以外のペルーの都市に居住する、例外的な才能を持つ参加者に限られます。旅費の支援を約束してはいけません。
• 任意プロフィールにまとめたすべての項目は任意です。
• codeOfConductAccepted は、参加者自身が明示的に true とする必要があります。エージェントが参加者に代わって同意することはできません。

最新のスキーマを正としてください。ローカルでの検証エラーが発生した場合は、error.details.acceptedFields を使用してペイロードのキーを修正してください。スキーマとエラーの詳細で問題が解決しない場合に限り、CLI のソースコードを調べてください。

必須の同意を求める前に、参加者に次のリンクを提示してください。

• https://hacktheandes.com/terms

利用規約に同意するかどうかを、規約の名称を明示して尋ねてください。エージェントが参加者に代わって同意することはできません。同意しない場合、すでに集めた回答を破棄しないでください。登録をキャンセルするか、文書を読んで明示的に同意するかを尋ねてください。同意する場合は同意のステップから続行し、キャンセルする場合は送信しないでください。

すべての回答と同意の選択が確定したら、申請を送信してください。registration.status が submitted になるまでは、成功したと伝えてはいけません。プロジェクトの外部に、モード 600 の一時申請ファイルを正確に 1 つ作成してください。POSIX システムでは次のとおりです。

application_file="$(mktemp)"
chmod 600 "$application_file"
printf '%s\n' "$application_file"

出力されたパスを正確に記録し、以降のすべての操作で再利用してください。コマンド間でシェルの状態が保持されない場合は、そのリテラルパスを使用してください。推測、省略、置き換えは決して行わないでください。1 件の申請につき、ペイロードファイル 1 つ、記録したパス 1 つ、クリーンアップ 1 回としてください。

参加者から提供された回答だけをそのファイルに書き込み、未回答の任意項目は省略してください。送信の承認を求める前に、ローカルで検証してください。

andes --output json validate --stage application --input "$application_file"

検証エラーを解決してから続行してください。まず、リスクの低い解釈や正規化をすべて、簡潔な注記で説明してください。次に、検証済みのペイロードの内容を読みやすくまとめ、同意に関するすべての項目を含めて、この申請を今すぐ送信しますか？ と尋ねてください。この時点で明示的に「はい」と回答された後に限り、送信を実行してください。

andes --output json register --input "$application_file"

送信に成功すると、status: "submitted" が返されます。修正可能な検証エラーが発生した場合の再試行時にファイルを作り直さずに済むよう、モード 600 の一時ファイルはそのまま保持してください。

チャレンジに一緒に取り組む

チャレンジの解決は、参加者が方向を決める対話です。定型的なセットアップ、 契約の確認、既存のステータスや観察結果の確認は、中断せずに進めてもかまいません。 クエリを消費したり解決策を実装したりする前に、次の仮説や変更を平易な言葉で 説明し、どの方向に進むか参加者に尋ねてください。先に進む前に返答を待ってください。

承認された各ラウンドは小規模に保ちます。仮説は1つ、新しいオラクルへの クエリは最大3回、または合意した実装変更を1つと、その変更に伴う無料のローカルテスト までとします。クエリを実行する前に、入力によって何を区別できるのかを説明してください。 クエリ予算をすべて消費するスクリプトを起動したり、複数のラウンドを連続して実行したり、 参加者の返答を待つ間にバックグラウンドで解決を続けたりしてはいけません。

各ラウンドの後は、証拠、それが裏付ける内容、残る不確実な点、残りの予算を示してください。 次の仮説を選ぶか、計画を変更するか、終了するかを参加者に尋ねてください。提案した選択肢を 選ぶか、具体的な次のラウンドを説明した後に「続けて」と答えることができます。その返答で 承認されるのは、そのラウンドだけです。「解決して」「終わるまで続けて」といった一般的な依頼、 沈黙、または以前の承認によって、このチャレンジのワークフローにおける以降の確認を 省略することはできません。参加者の方向性や回答を捏造してはいけません。

公式評価を行う前には必ず、解決策の変更点、無料テストの結果、未検証の前提、 残りの評価回数を示してください。その解決策に対して評価を1回行ってよいか参加者に尋ね、 明示的な返答を待ってください。結果が出た後は、その限界を説明し、編集、追加のクエリ、 次の評価を行う前に再度停止してください。ノートブックで完璧な結果が出ても、隠れたケースで 正しいことの証明にはなりません。集計スコアから、不足しているルールを特定することもできません。

これらの対話上の確認手順は、Broken Agent と Slow Service で求められる、 ソースに基づく参加者レビューを補うものです。レビューの代わりにはならず、 サーバーが人間の関与を検証すると主張するものでもありません。

Black Box チャレンジ

The Shipping Machine は技術的な入場チャレンジの1つです。チャレンジに参加しなくても 応募は提出できますが、枠を競うにはチャレンジへの参加が必須です。最も優秀なエンジニアは 応募文だけでなく順位によって特定され、運営者が提出済みの応募に受け入れを手動で記録します。 チャレンジのスラッグは常に最新版を参照します。過去の試行を完了として扱ってはいけません。 チャレンジ一覧を表示してから、現在利用できるチャレンジを確認してください。

andes --output json challenge list
andes --output json challenge show --challenge black-box

AI ツールの利用は許可されています。オラクルは参加者ごとに異なるため、漏洩した解決策は この参加者の関数には一致しません。実験を設計してください。変数を一度に1つずつ変え、 しきい値を探し、次に「壊れやすい」と「速達」の組み合わせなどをテストします。 新しい入力が成功するたびに、25回のクエリのうち1回を消費します。重複したクエリや 失敗したクエリは無料です。上記の参加者が方向を決めるラウンドに従ってください。

andes --output json challenge query --distance 1 --weight 1 --hour 12 --fragile false --express false
andes --output json challenge notebook --format json

観察結果を集めたら、ローカルファイルに function calculateShipping(input) を記述してください。 ノートブックに対してテストしてから（公式評価を消費しません）、隠しセットに対して評価します （公式評価の試行は最大3回です）。

andes --output json challenge test --source "$PWD/shipping.js"
andes --output json challenge evaluate --source "$PWD/shipping.js"

参加者に、自分で実行していない解決策を貼り付けるよう求めてはいけません。応募の提出と チャレンジの完了は別々の操作ですが、どちらも入場までの手順に含まれます。エンベロープに ok: true があり、かつ registration.status が submitted の場合に限り、応募の成功を 報告してください。その状態を、何もせずに待機している状態として説明してはいけません。 公開中のチャレンジに進み、枠はチャレンジの順位に応じた成績によって獲得することを説明してください。

公開ランキングは読み取り専用です。

andes --output json challenge ranking --challenge black-box

Broken Agent チャレンジ

参加者がチャレンジ2または broken-agent の解決、提出、評価を依頼した場合は、 デフォルトの andes challenge ガイドで Broken Agent が案内される場合も含め、 references/broken-agent.md を読み、その指示に従ってください。 このファイルでは、必須の人間とエージェントの推論ループと、公式評価の前に必要な ソースに基づくレビューを定義しています。

Slow Service チャレンジ

サーバーがチャレンジ 3 の make-it-fast をオープンとして一覧表示したら、 references/slow-service.md を読んでください。正規版は slow-service-v3 です。ソースに基づく補完レビューと、実装内容そのものに対するブラウザー／パスキーによる 承認を使用します。どちらの段階でも AI による支援が認められています。証拠や参加者の判断を 捏造しないでください。承認は責任を記録するものであり、理解や独立した執筆の証明ではありません。 開始前に challenge list を確認してください。クローズされたチャレンジはランキングと 過去の結果を保持しますが、新しい提出は受け付けません。

Power Grid チャレンジ

参加者がチャレンジ 4 または power-grid の解決を求めた場合、またはサーバーが参加者のアカウントで 利用可能として告知した場合は、references/power-grid.md を読んでください。 発見、実装、評価の全体を通じて、上記の会話チェックポイントを適用してください。

次のステップ

アプリケーションと、サーバーが計算した要件を合わせて確認してください。

andes --output json status

status の応答には requirements が含まれます。ステータス応答にそれらが含まれていない場合、または参加者が要件のみを明示的に求めた場合に限り、別個の requirements コマンドを実行してください。

返された状態を次のように解釈してください。

• draft：これは古い CLI フローで残されたアプリケーションです。requirements.parts と不足しているフィールドを表示し、アプリケーションをすべて収集して、andes register を使って提出してください。その後、オープンしている必須の入場チャレンジに進んでください。チャレンジに取り組むために、アプリケーションの提出を遅らせないでください。
• submitted、under_review、または waitlisted：正確なステータスと要件を報告してください。アプリケーションは受理されていますが、席は割り当てられていないことを明確にしてください。andes challenge list を実行し、オープンしているチャレンジを特定して、必須の人間とエージェントのフローを続けてください。入場チャレンジがオープンしている間、参加者にただ待つよう伝えてはいけません。
• rejected：レビューのフィードバックがあれば表示してください。canSubmitNewApplication が true の場合に限り、新しいアプリケーションを提示してください。対話形式の andes register では、却下されたアプリケーションの回答が編集可能なデフォルトとして表示されます。古い回答を黙って再提出するのではなく、新たに提出することへの承認を得てください。
• accepted：参加者にお祝いを伝え、不足している承認フィールドがあれば説明してください。canSubmitAcceptedDetails が true の場合に限り、出席の確認に進んでください。
• withdrawn：ステータスを報告し、サーバーが返した操作のみを行ってください。
• 要件の段階が complete：出席情報はすべて揃っています。イベント中は、必要に応じてチーム設定、進捗の更新、プロジェクトの提出に進んでください。

却下の正確な理由、不足フィールドの理由、サーバーの状態をそのまま返してください。 この要約と異なる場合は、サーバーの応答を正とします。

出席の確認

承認の詳細には、身分証明書に記載されているとおりの参加者の氏名、生年月日、国民識別番号またはパスポート番号、緊急連絡先、必須のプロフィール画像確認、その他の個人情報が含まれます。参加者は、Clerk の画像、GitHub のアバター、またはカスタムアップロードのいずれかを明示的に選択する必要があります。利用可能な画像からこの選択を推測してはいけません。次のコマンドを対話型ターミナルで自分で実行し、これらの値をエージェントとのチャットに入力しないよう、参加者に勧めてください。

andes confirm

参加者が代わりにエージェントによる送信を明示的に依頼した場合は、andes schema --stage acceptance で最新のテンプレートを取得し、推測せずに必須項目をすべて収集して、プロジェクト外のアクセス権限が 600 に設定された一時ファイルに保存してください。内容を表示しないようにしてください。dateOfBirth には YYYY-MM-DD を使用し、実際に存在する過去の日付を指定する必要があります。この対面イベントでは、シャツのサイズも必須です。andes --output json validate --stage acceptance --input /path/to/private-attendance.json でファイルを検証してください。成功時の応答に内容は含まれません。検証エラーを解決したら、最新の状態で この個人情報を含む出席詳細を今すぐ送信しますか？ という確認を得て、次を実行してください。

andes --output json confirm --input /path/to/private-attendance.json

pictureSource が upload の場合は、参加者のコンピューター上にある画像のパスを尋ね、確認コマンドに --picture /that/path/image.png を追加してください。画像データを JSON ファイルやチャットにコピーしてはいけません。CLI は最大 5 MB の JPEG、PNG、WebP ファイルを受け付け、アップロードと検証が完了するまで待機し、アップロードの進捗を stderr に表示します。カスタムアップロードは、承認後に限り利用でき、24 時間あたり 5 回までです。

コマンドの完了後、ただちにファイルを削除してください。再度 status を実行し、完了を報告する前に、要件ステージが complete になっていることを確認してください。

チームで開発し、進捗を公開する

イベント期間中、これらのコマンドを使う前に andes project --help と andes team --help を読んでください。プロジェクト関連のコマンドが使えない場合は、CLI をアップグレードしてください。andes --output json team と andes --output json project を使って、現在のチームと提出内容を確認してください。andes --output json project updates を使って、更新履歴を読み取ってください。メンバーなら誰でも、更新を公開したり、共有中の提出内容を編集したりできます。プロジェクト名にはチーム名を使ってください。変更を求められた場合は、andes --output json team rename --name "New team name" を使って名前を変更してください。別のプロジェクト名を作成しないでください。

チームが次に取り組むべき有益な一歩を見つける手助けをしてください。方向性が不明な場合は、決まった質問を順番にするのではなく、不確実さを解消できる質問をしてください。

• この問題を抱えているのは誰で、現在はどのように対処していますか？
• 今、プロダクトが最も重要に実現すべきことは何ですか？
• チームの妨げになっているものは何ですか？また、具体的にどのような支援があれば解決できますか？
• どのような決定をしましたか？その根拠となる証拠は何ですか？また、何を対象外にしましたか？
• 次のデモで、実際に試せることは何ですか？

重要な節目、方向性の変更、動作するデモ、またはメンターの支援が役立ちそうな障害があった場合は、最新の共有更新を確認し、新しい情報があれば次の更新の送信を提案してください。作業セッション中は、大きな進展があった後、または有益な更新がないままおよそ1時間が経過した後に、再度確認してください。同じ内容の更新を繰り返し送ったり、コードを変更するたびに作業を中断したりしないでください。このスキルは作業セッション中に実行され、バックグラウンドタイマーは作成しません。

参加者が「send an update to the mentors/judges」と言った場合、事実に基づく更新を準備して公開する許可を得たことになります。同じ許可を再度求めないでください。エージェントから更新を提案するだけの場合は、下書きを提示し、公開する前に参加者の了承を得てください。このセッション中に参加者から得た、進捗更新を公開する継続的な許可も適用されます。内容は、確認した作業と参加者の発言に基づいてください。検証済みの結果と計画、未確認事項を区別してください。ユーザーテスト、パフォーマンス数値、影響、完了した機能を決して捏造しないでください。

有益な Markdown 更新には、何を変更したか、チームがその変更を選んだ理由、動作するもの、妨げになっているもの、必要な支援、デプロイしたもの、チームが使用したツールやサービス、次に行うことを記載します。有益な情報がないセクションは省略してください。関連する公開デモのリンクを含めてください。シークレット、トークン、非公開のユーザーデータ、機密情報は含めないでください。更新は組織と共有され、作成者の公開名とタイムスタンプとともにプロジェクトギャラリーで公開される場合があります。公開すると確認用のログが保存されますが、メールが送信されたり、メンターからすぐに返答があると約束されたりするわけではありません。

andes --output json project update --message "Terminamos el flujo y desplegamos la demo."
andes --output json project updates

通常は直接テキストを使用してください。長い Markdown の場合は、project update --file /path/to/update.md も使用できます。ファイルの指定は任意です。更新が成功すると、保存されたエントリと合計のみが返されます。project updates を使って、履歴全体を読み取ってください。成功レスポンスを読み、公開済みと伝える前に保存された内容を確認してください。書き込みがタイムアウトした場合は、同じ更新を二重に追加しないよう、再試行する前に履歴を確認してください。

イベントには、Clima y Territorio（「環境」）、Movilidad y Transporte（「移動と交通」）、Educación Escolar（「学校教育」）、Seguridad（「安全」）の4つのトラックがあります。モビリティには、リマ市内の公共交通機関と旅客輸送のほか、他地域での地域間交通、貨物輸送、配送が含まれます。各トラックの定員は現在のチーム数の25％（端数切り上げ）で、イベント全体では最大36チームです。定員が減っても、既存のトラック選択は維持されます。現在の空き状況を確認するには andes team を、トラックを選択するには andes team track を使ってください。

イベントプロジェクトの提出と管理

最新のイベント案内については、参加者ガイド（https://hacktheandes.com/guide）と提出条件（https://hacktheandes.com/participation-terms）を確認してください。プロジェクトの提出は、参加申し込みやチャレンジの提出とは別です。

プロジェクトの提出に必要な成果物は、既存のチーム名を使用した次の4点です。

• 動作するアプリケーションの公開デプロイURL。
• Canva、Google Slides、またはコードで作成したプレゼンテーションなどのURL。
• https://github.com/team/project のようなGitHubリポジトリのURL。Gitのリモートを確認して見つけてください。リモートが曖昧な場合は、参加者に確認してください。
• 課題、想定ユーザー、動作するソリューション、既知の制限事項を説明するMarkdown形式の説明文。

参加者はノートPCをイベントのプレゼンテーション機器に接続できません。運営組織が自らのコンピューターで提出されたリンクを開きます。可能であれば、サインアウト状態またはプライベートブラウザーセッションで両方のURLを確認してください。アクセス申請が必要ないこと、個人のログインに依存しないこと、ローカルファイルがないことを確認してください。確認していないリンクを、アクセス可能だと断言しないでください。アクセスを確認できない場合は、参加者に確認すべき点を伝えてください。

4つの成果物がそろったら、早めに提出するよう促してください。同じ提出内容は、後から1項目ずつ編集できます。不足している成果物だけを尋ねてください。正確なMarkdown形式の説明文を作成するため、リポジトリと現在のデプロイを確認してください。デプロイURLやプレゼンテーションURLを捏造しないでください。提出または更新を明示的に依頼された場合は、その操作が許可されています。それ以外の場合は、準備した提出内容を提示し、提出してよいか尋ねてください。

andes --output json project submit --deployment-url https://app.example --presentation-url https://slides.example --github-url https://github.com/equipo/proyecto --file /path/to/project.md
andes --output json project
andes --output json project submit --presentation-url https://new-slides.example

保存された提出内容を返されたら、変更された項目をすべて含めて確認してください。チームメイトは誰でも編集できるため、操作前に最新の状態を読み込み、編集内容が競合しないよう調整してください。最後のメンバーがチームを離れるか、別のチームに加わると、元のチームは解散し、トラックと定員枠は解放されます。運営組織は、提出内容と更新履歴を非公開のアーカイブに保持します。このアーカイブは公開ギャラリーには含まれず、新しいチームにも引き継がれません。

公開ギャラリー（https://hacktheandes.com/projects）は、運営組織が公開を有効にするまで非表示です。日曜日に公開されると約束しないでください。公開されると、提出されたプロジェクトのページに説明文、URL、更新履歴が掲載されます。これらすべての項目に非公開データを含めないよう、チームに注意してください。

失敗時の対応

ok: false の場合は、error.code、error.message、requestId を報告してください。最終的な概要を提示する前に、ローカルで検出できる検証エラーを解決してください。参加者の回答が変わらない機械的な問題は、直接修正してください。回答や同意の変更が必要な場合は、参加者に対応を求めてください。参加申し込み、出席確認、チャレンジの提出では、最終承認後にペイロードを変更すると、その承認は無効になります。更新した概要を提示し、再度承認を求めてください。失敗したリクエストを、retryable が true の場合に限り、変更せずに再試行してください。参加申し込み、出席確認、チャレンジの提出を再試行する前に、新たに提出の承認を得てください。認証に失敗した場合は、参加者を認証するに戻ってください。成功したと偽ったり、失敗状態を回避したりせず、サポート用にリクエストIDを保持してください。