chofex-hackathon

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Hack the Andes

Use the andes CLI to act on the participant's behalf while keeping identity, consent, challenge direction, and final submission decisions with the participant.

使用 andes CLI 代表参与者执行操作，同时将身份确认、同意、挑战方向和最终提交决定保留给参与者。

Pace

节奏

Move quickly and proactively. Run routine, non-destructive setup, schema, status, and requirements commands without asking permission or narrating each command. Batch participant questions into the fewest practical turns. Pause only for:

browser authentication;
confirmation that the authenticated email belongs to the participant;
application answers that are missing or genuinely ambiguous;
the participant's own consent decisions;
challenge experiment selection, continuation checkpoints, evidence review, and release judgment;
final admission or challenge submission approval; and
private accepted-participant details.

Mechanical formatting is not personal-data invention. Normalize obvious handles and domains, show the result in the final application summary, and let the participant correct it before submission:

GitHub

cuevaio

@cuevaio

becomes

https://github.com/cuevaio

cuevaio

@cuevaio

becomes

https://linkedin.com/in/cuevaio

A profile URL or bare domain missing a scheme gets
```
https://
```
.

Ask a follow-up only when the input is malformed or has more than one plausible meaning that would materially change the application. State low-risk parsing in a concise interpretation note immediately before the final summary instead of interrupting the interview. Preserve participant-provided wording and casing for personal answers.

快速并主动地推进。常规、无破坏性的设置、schema、状态和要求命令可直接运行，无需请求许可或逐条解说命令。

尽可能将参与者的问题合并为最少的交互轮次。仅在以下情况暂停：

浏览器身份认证；
确认认证邮箱属于参与者；
缺失或确实有歧义的申请答案；
参与者本人作出的同意决定；
挑战实验选择、继续检查点、证据审查和发布判断；
最终录取或挑战提交批准；以及
已录取参与者的私密详细信息。

机械性格式处理不属于个人数据臆造。规范化明显的账号名和域名，在最终申请摘要中展示结果，并允许参与者在提交前更正：

GitHub

cuevaio

或

@cuevaio

变为

https://github.com/cuevaio

。

cuevaio

或

@cuevaio

变为

https://linkedin.com/in/cuevaio

。

缺少 scheme 的个人资料 URL 或裸域名应补上
```
https://
```
。

仅当输入格式错误，或存在多个合理含义且会实质改变申请时，才追问。对于低风险解析，在最终摘要前紧接用一条简洁的解释说明注明结果，不要打断问答过程。保留参与者提供的个人答案原文和大小写。

Command setup

命令设置

Check for the current CLI capabilities with
```
andes --version
```
and
```
andes validate --help
```
.
If either command is unavailable, install or upgrade proactively with
```
npm install --global hacktheandes-cli@latest
```
; do not delegate installation to the participant.
Verify both commands. If global installation is unsupported or fails for lack of permission, use
```
npx --yes hacktheandes-cli@latest
```
as the command prefix. When working inside the Hack the Andes repository,
```
bun run --filter chofex-cli dev --
```
is also an acceptable fallback. Ask the participant for help only when installation requires an interactive administrator or credential step that the agent cannot perform.
Use
```
--output json
```
for every command the agent needs to interpret. JSON responses are versioned envelopes with
```
ok
```
,
```
requestId
```
, and either
```
data
```
or
```
error
```
.

Use one consistent command prefix for the whole session. The CLI already targets the Hack the Andes service, so use the default URL.

使用
```
andes --version
```
和
```
andes validate --help
```
检查当前 CLI 功能。
如果任一命令不可用，主动通过
```
npm install --global hacktheandes-cli@latest
```
安装或升级；不要把安装工作交给参与者。
验证两个命令。如果全局安装因权限受限而不可用或失败，使用
```
npx --yes hacktheandes-cli@latest
```
作为命令前缀。在 Hack the Andes 仓库中工作时，
```
bun run --filter chofex-cli dev --
```
也不失为可接受的回退方案。仅当安装需要 Agent 无法执行的交互式管理员或凭据步骤时，才请参与者提供帮助。
Agent 需要解读的每条命令都使用
```
--output json
```
。JSON 响应是带版本号的 envelope，包含
```
ok
```
、
```
requestId
```
，以及
```
data
```
或
```
error
```
。

整个会话保持使用同一个命令前缀。CLI 已默认指向 Hack the Andes 服务，因此使用默认 URL。

Authenticate the participant

对参与者进行身份认证

Run:

andes --output json whoami

If authentication is required, ask the participant to run

andes login

in their own interactive terminal and finish the browser flow. Then run

whoami

again and ask them to confirm that the returned email is theirs. Login tokens belong in the operating-system credential store. Treat

CHOFEX_TOKEN

as a secret and keep it out of chat, command arguments, logs, and files.

Authentication is complete only when

whoami

succeeds and the participant confirms the email.

运行：

andes --output json whoami

如果需要身份认证，请参与者在自己的交互式终端中运行

andes login

并完成浏览器流程。然后再次运行

whoami

，并请他们确认返回的邮箱属于自己。登录 token 应保存在操作系统凭据存储中。将

CHOFEX_TOKEN

视为 secret，使其不出现在聊天、命令参数、日志和文件中。

只有当

whoami

成功且参与者确认邮箱属于自己后，身份认证才算完成。

Apply

申请

First, check whether the participant already has an application:

andes --output json status

If one exists, report its status and follow Next steps. Start an application when there is no application, resume and submit it when the status is

draft

, or let a rejected participant apply again. A rejected application remains in history. The participant may submit the application before completing a challenge, but the application alone never reserves a seat. Technical challenges are mandatory for admission, and organizers select the strongest engineers from their ranked results. Only the latest server-advertised challenge version counts; legacy attempts remain historical. Every selected engineer must also have a submitted application before being accepted.

Get a fresh input template instead of relying on a memorized schema:

andes schema --stage application

The output is an example shape, not an application draft. It contains every supported JSON key. Copy those keys exactly; for example, use

fullName

role

phone

bio

portfolioUrl

, and

shippedProject

. Never save or submit the example values.

Collect every field in one compact batch when practical. Accept a natural, unlabeled reply and map it using context; numbered formatting is optional. For open-ended fields, ask directly in chat or use an input whose selectable choices are actual answers such as “Omit.” A placeholder choice such as “Enter all answers” is not an answer and must not be offered. Ask only for fields the participant has not already answered. Group the questionnaire so the participant can scan and answer it naturally:

required profile: full name, role, and country of residence;
optional profile: phone number, bio, portfolio URL, something they have shipped, LinkedIn, and GitHub URLs; and
required Terms and Conditions.

Explain these rules while collecting answers:

Registration is for the in-person event in Lima, Peru. The application uses the authenticated account's primary email.
```
fullName
```
,
```
role
```
, and
```
countryCode
```
are required. Ask for the participant's country of residence and use its ISO two-letter code. Do not assume Peru.
The participant chooses their country once. Only the organizers can correct it after reviewing LinkedIn or other social profiles. Reuse the saved country on reapplication. Existing participants with no country can select it with
```
andes country --code PE
```
, replacing
```
PE
```
with their actual country.
Before submitting a country other than Peru, explain that the event is in Lima and participants outside Peru must cover their travel costs. Travel support is reserved for exceptional talent residing in Peruvian cities other than Lima. Do not promise travel support.
Every field grouped under optional profile is optional.
```
codeOfConductAccepted
```
must be the participant's explicit
```
true
```
; an agent cannot consent for them.

Treat the fresh schema as authoritative. On local validation errors, use

error.details.acceptedFields

to correct payload keys. Inspect CLI source only when the schema and error details do not resolve the problem.

Before requesting required consent, give the participant this link:

```
https://hacktheandes.com/terms
```

Ask for the Terms and Conditions decision by name. An agent cannot consent for the participant. If they do not accept, do not discard the answers already collected. Ask whether they want to cancel registration or read the document and explicitly accept it. Continue from the consent step if they accept; do not submit if they cancel.

Once every answer and consent choice is settled, submit the application. Do not claim success until

registration.status

submitted

. Create exactly one mode-600 temporary application file outside the project. On a POSIX system:

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

Record the exact printed path and reuse it for every later operation. When shell state does not persist between commands, use that literal path; never guess, shorten, or replace it. One application uses one payload file, one recorded path, and one cleanup.

Write only participant-provided answers to that file and omit unanswered optional fields. Validate it locally before asking for submission approval:

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

Resolve validation errors before continuing. First state every low-risk interpretation or normalization in a concise note. Then show a readable summary of the exact validated payload, include every consent, and ask: Submit this application now? Run the submission only after an explicit yes given at this point.

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

A successful submission returns

status: "submitted"

. Keep the mode-600 temporary file through correctable validation failures so a retry does not require rebuilding it.

先检查参与者是否已有申请：

andes --output json status

如果已有申请，报告其状态并遵循后续步骤。没有申请时开始申请；状态为

draft

时恢复并提交；被拒参与者则允许再次申请。被拒申请仍保留在历史记录中。参与者可以在完成挑战前提交申请，但仅提交申请绝不会预留席位。技术挑战是录取的必选项，主办方会根据排名结果选取最优秀的工程师。只有服务器公布的最新挑战版本有效；旧版尝试仅作为历史记录。每位入选工程师还必须已提交申请，才能被录取。

获取新的输入模板，不要依赖记忆中的 schema：

andes schema --stage application

输出是示例结构，不是申请草稿。它包含所有受支持的 JSON key。必须准确复制这些 key；例如，使用

fullName

、

role

、

phone

、

bio

、

portfolioUrl

和

shippedProject

。绝不能保存或提交示例值。

在可行情况下，用一次紧凑的批量交互收集所有字段。可以接受自然、无标签的回答，并结合上下文映射；编号格式是可选的。对于开放式字段，应直接在聊天中询问，或使用可选项本身就是实际答案的输入控件，例如“Omit.”。不能提供“Enter all answers”之类的占位选项，因为它不是答案。只询问参与者尚未回答的字段。将问卷分组，便于参与者浏览并自然作答：

必填个人资料：全名、角色和居住国家；
可选个人资料：电话号码、个人简介、作品集 URL、已经交付过的产品、LinkedIn 和 GitHub URL；以及
必填 Terms and Conditions。

收集答案时解释以下规则：

报名面向在秘鲁利马举行的线下活动。申请使用认证账户的主要邮箱。
```
fullName
```
、
```
role
```
和
```
countryCode
```
为必填项。询问参与者的居住国家，并使用其 ISO 双字母代码。不要默认是秘鲁。
参与者只能选择一次国家。主办方在审核 LinkedIn 或其他社交资料后，才会更正国家。重新申请时沿用已保存的国家。尚未设置国家的现有参与者可通过
```
andes country --code PE
```
进行选择，并将
```
PE
```
替换为实际国家。
在提交秘鲁以外国家前，说明活动在利马举办，秘鲁境外参与者须自行承担差旅费用。差旅支持仅保留给居住在秘鲁境内但不在利马的杰出人才。不得承诺差旅支持。
可选个人资料分组下的每个字段均为选填。
```
codeOfConductAccepted
```
必须是参与者明确给出的
```
true
```
；Agent 不能代其同意。

以最新 schema 为准。本地验证出错时，使用

error.details.acceptedFields

修正 payload key。只有在 schema 和错误详情都无法解决时，才检查 CLI 源码。

在请求必需同意前，向参与者提供此链接：

```
https://hacktheandes.com/terms
```

按名称询问其对 Terms and Conditions 的决定。Agent 不能代为同意。如果不接受，不要丢弃已收集的答案。询问他们希望取消注册，还是阅读文档并明确接受。若接受，从同意步骤继续；若取消，不要提交。

所有答案和同意选择都确定后，提交申请。在

registration.status

为

submitted

前，不要声称成功。在项目目录之外创建且仅创建一个 mode-600 临时申请文件。在 POSIX 系统上：

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

记录打印出的确切路径，并在后续所有操作中复用。当 shell 状态无法在命令间保持时，使用该字面路径；绝不猜测、缩短或替换。一次申请只用一个 payload 文件、一个记录的路径和一次清理。

文件中只写入参与者提供的答案，省略未回答的可选字段。在请求提交批准前先进行本地验证：

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

继续前解决验证错误。先用简洁说明列出每项低风险解释或规范化处理。然后显示经验证 payload 的可读摘要，涵盖每项同意，并询问：现在提交此申请吗？ 只有在此刻获得明确肯定答复后才运行提交。

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

成功提交会返回

status: "submitted"

。在可修正的验证失败期间保留 mode-600 临时文件，以便重试时无需重新构建。

Work through challenges together

共同完成挑战

Challenge solving is a participant-directed conversation. Routine setup, reading the contract, and checking existing status or observations may proceed without interruption. Before spending queries or implementing a solution, explain the next hypothesis or change in plain language and ask the participant which direction to take. Wait for their reply before proceeding.

Keep each approved round small: one hypothesis, at most three new oracle queries, or one agreed implementation change with its free local tests. Explain what the inputs distinguish before querying. Do not launch a script that spends the whole query budget, chain multiple rounds, or continue solving in the background while waiting for the participant.

After each round, show the evidence, what it supports, what remains uncertain, and the remaining budgets. Ask the participant to choose the next hypothesis, change the plan, or stop. They may select a proposed option or say "continue" after a concrete next round has been described. Their reply authorizes only that round. A general "solve it for me", "keep going until finished", silence, or an earlier approval does not replace later checkpoints in this challenge workflow. Do not invent the participant's direction or answers.

Before every official evaluation, show the solution changes, free-test results, unverified assumptions, and remaining evaluation count. Ask whether to spend one evaluation on that exact solution and wait for an explicit reply. After the result, explain its limits and pause again before edits, more queries, or another evaluation. A notebook-perfect result does not prove hidden correctness; an aggregate score does not identify a missing rule.

These conversational checkpoints supplement the source-bound participant reviews required by Broken Agent and Slow Service. They do not replace those reviews or claim that the server verifies human involvement.

挑战解题是由参与者主导的对话。可以不中断地执行常规设置、阅读 contract，以及检查现有 status 或 observations。

在消耗 query 或实现 solution 前，用通俗语言解释下一项 hypothesis 或改动，并询问参与者希望采用哪个方向。收到回复后再继续。

每个获准轮次保持小规模：一个 hypothesis、最多三次新的 oracle query，或一项双方商定的实现改动及其免费本地测试。查询前说明不同输入能够区分什么。不得启动会耗尽整个 query 预算的脚本、串联多个轮次，或在等待参与者时继续在后台解题。

每轮结束后，展示证据、证据支持什么、仍有哪些不确定性以及剩余预算。询问参与者选择下一项 hypothesis、修改计划或停止。参与者可以选择建议项，也可以在已具体描述下一轮后回复“continue”。该回复只授权这一轮。笼统的“solve it for me”“keep going until finished”、沉默或先前的批准，都不能替代挑战流程中后续的检查点。不得臆造参与者选择的方向或答案。

每次正式 evaluation 前，展示 solution 改动、免费测试结果、尚未验证的假设和剩余 evaluation 次数。询问是否对这一确切 solution 消耗一次 evaluation，并等待明确回复。结果出来后，说明其局限，再次暂停，之后才能编辑、发起更多 query 或进行另一次 evaluation。notebook 上的完美结果不能证明 hidden set 正确；aggregate score 不能识别缺失规则。

这些对话检查点是对 Broken Agent 和 Slow Service 所要求的 source-bound 参与者评审的补充。它们不能取代这些评审，也不能声称服务器会验证真人参与。

Black Box challenge

The Shipping Machine is one of the technical admission challenges. It does not block application submission, but challenge participation is mandatory to compete for a seat. Rankings—not the application prose alone—identify the strongest engineers, and organizers record acceptance manually on the submitted application. The challenge slug always resolves to the latest version; never use a historical attempt as completion. List challenges, then inspect the currently available challenge:

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

AI tools are allowed. The oracle is personalized, so a leaked solution will not match this participant's function. Design experiments: change one variable at a time, look for thresholds, then test combinations such as fragile and express together. Each successful new input consumes one of 25 queries; duplicate or failed queries are free. Follow the participant-directed rounds above.

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

After collecting observations, write

function calculateShipping(input)

in a local file. Test against the notebook (does not consume an official evaluation), then evaluate against the hidden set (limited to 3 official attempts):

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

Never ask the participant to paste a solution that they did not run. Application submission and challenge completion are separate operations, but both belong to the admission path. Report application success only when the envelope has

ok: true

and

registration.status

submitted

. Never describe that state as waiting with no action: proceed to the open challenge and explain that a seat is earned through ranked challenge performance.

Public rankings are read-only:

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

The Shipping Machine 是技术录取挑战之一。它不会阻止申请提交，但参加挑战是争取席位的必要条件。排名（而非仅凭申请文案）用于识别最优秀的工程师，主办方会在已提交的申请中手动记录录取结果。挑战 slug 始终解析到最新版本；绝不能把历史尝试视为完成。先列出挑战，再检查当前可用挑战：

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

允许使用 AI 工具。oracle 是个性化的，因此泄露的 solution 不会匹配参与者的 function。设计实验：一次只改变一个变量，寻找阈值，再测试 fragile 和 express 等组合。每个成功的新输入会消耗 25 次 query 中的 1 次；重复或失败的 query 免费。遵循上述由参与者主导的轮次。

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

收集 observations 后，在本地文件中编写

function calculateShipping(input)

。先用 notebook 测试（不会消耗正式 evaluation），再对 hidden set 评估（最多 3 次正式尝试）：

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

绝不能要求参与者粘贴自己未运行过的 solution。申请提交和挑战完成是两个独立操作，但都属于录取路径。只有当 envelope 的

ok: true

且

registration.status

为

submitted

时，才能报告申请成功。绝不能将该状态描述为“等待且无需行动”：应继续处理开放挑战，并说明席位需要通过排名表现来赢得。

公开排名是只读的：

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

Broken Agent challenge

When the participant asks to solve, submit, or evaluate challenge 2 or

broken-agent

—including when the default

andes challenge

guide identifies Broken Agent—read and follow

references/broken-agent.md

. It defines the required human–agent reasoning loop and the source-bound review needed before an official evaluation.

当参与者要求解决、提交或评估 challenge 2 或

broken-agent

时——包括默认

andes challenge

指南识别出 Broken Agent 时——请阅读并遵循

references/broken-agent.md

。该文件定义了正式 evaluation 前必需的 human–agent 推理循环和 source-bound 评审。

Slow Service challenge

When the server lists challenge 3,

make-it-fast

, as open, read

references/slow-service.md

. Its canonical version is

slow-service-v3

. It uses source-bound companion review and browser/passkey approval of the exact implementation. AI help is allowed in both stages. Do not invent evidence or the participant's decision. The approval records responsibility, not proof of understanding or independent authorship. Check

challenge list

before starting; a closed challenge retains its ranking and historical results but does not accept new submissions.

当服务器将 challenge 3

make-it-fast

列为开放状态时，请阅读

references/slow-service.md

。其规范版本是

slow-service-v3

。它使用 source-bound 配套评审，以及通过 browser/passkey 对确切实现进行审批。两个阶段都允许使用 AI 帮助。不得臆造证据或参与者的决定。该审批记录的是责任归属，而不是对理解程度或独立创作能力的证明。

开始前检查

challenge list

；已关闭的挑战仍保留排名和历史结果，但不再接受新提交。

Power Grid challenge

When the participant asks to solve challenge 4 or

power-grid

, or the server advertises it as available to their account, read

references/power-grid.md

. Apply the conversation checkpoints above throughout discovery, implementation, and evaluation.

当参与者要求解决 challenge 4 或

power-grid

，或服务器向其账户开放该挑战时，请阅读

references/power-grid.md

。在探索、实现和 evaluation 全过程中应用上述对话检查点。

Next steps

后续步骤

Read the application and server-calculated requirements together:

andes --output json status

The

status

response includes

requirements

. Run the separate

requirements

command only when the status response omits them or the participant specifically asks for requirements alone.

Interpret the returned state as follows:

```
draft
```
: this is an application left by an older CLI flow. Show
```
requirements.parts
```
and missing fields, collect the complete application, and use
```
andes register
```
to submit it. Then continue to the open mandatory admission challenge; do not delay application submission for challenge work.
```
submitted
```
,
```
under_review
```
, or
```
waitlisted
```
: report the exact status and requirements. Make clear that the application has been received but no seat is assigned. Run
```
andes challenge list
```
, identify the open challenge, and continue its required human–agent flow. Never tell the participant to merely wait while an admission challenge is open.
```
rejected
```
: show the review feedback when present. Offer a new application only if
```
canSubmitNewApplication
```
is true. Interactive
```
andes register
```
presents the rejected application's answers as editable defaults. Obtain a fresh submission approval rather than silently resubmitting old answers.
```
accepted
```
: congratulate the participant and explain any
```
missing
```
acceptance fields. Continue to Confirm attendance only when
```
canSubmitAcceptedDetails
```
is true.
```
withdrawn
```
: report the status and follow only the actions returned by the server.
requirements stage
```
complete
```
: attendance details are complete. During the event, continue to team setup, progress updates and project submission as relevant.

Return the exact rejection reason, missing-field reasons, and server state. The server response is authoritative when it differs from this summary.

结合读取申请结果和服务器计算出的 requirements：

andes --output json status

status

响应包含

requirements

。仅当 status 响应未包含 requirements，或参与者明确只询问要求时，才单独运行

requirements

命令。

按以下方式解释返回状态：

```
draft
```
：这是旧版 CLI 流程遗留的申请。显示
```
requirements.parts
```
和缺失字段，收集完整申请，并使用
```
andes register
```
提交。随后继续完成开放的技术挑战；不要因挑战工作而推迟申请提交。
```
submitted
```
、
```
under_review
```
或
```
waitlisted
```
：报告确切状态和 requirements。明确说明申请已收到，但尚未分配席位。运行
```
andes challenge list
```
，找出开放挑战并继续其必需的人机流程。绝不能告知参与者只需等待，而开放录取挑战仍然存在。
```
rejected
```
：存在审核反馈时显示。仅当
```
canSubmitNewApplication
```
为 true 时提供新申请。交互式
```
andes register
```
会将被拒申请答案作为可编辑默认值展示。必须重新获得提交批准，不得静默重新提交旧答案。
```
accepted
```
：祝贺参与者，并说明任何
```
missing
```
录取字段。仅当
```
canSubmitAcceptedDetails
```
为 true 时继续确认出席。
```
withdrawn
```
：报告状态，并且只执行服务器返回的操作。
requirements 阶段为
```
complete
```
：出席信息已完整。活动期间，根据实际情况继续进行团队设置、进展更新和项目提交。

返回确切的拒绝原因、缺失字段原因和服务器状态。如果服务器响应与本摘要不一致，以服务器响应为准。

Confirm attendance

确认出席

Acceptance details include the participant's full name exactly as it appears on their ID document, birth date, national ID or passport number, emergency contact, a required profile-picture confirmation, and other private information. The participant must explicitly choose their Clerk picture, their GitHub avatar, or a custom upload; never infer this choice from an available image. Recommend that the participant keep these values out of agent chat by running this themselves in an interactive terminal:

andes confirm

If the participant explicitly asks the agent to submit them instead, fetch a fresh template with

andes schema --stage acceptance

, collect every required value without guessing, store it in a mode-600 temporary file outside the project, and avoid printing its contents.

dateOfBirth

uses

YYYY-MM-DD

and must be a real date in the past. Shirt size is required for this in-person event. Validate the file with

andes --output json validate --stage acceptance --input /path/to/private-attendance.json

; the success response does not echo its contents. Resolve validation errors, then obtain a fresh Submit these private attendance details now? approval and run:

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

When

pictureSource

upload

, ask for the image's path on the participant's computer and add

--picture /that/path/image.png

to the confirm command. Do not copy image bytes into the JSON file or chat. The CLI accepts JPEG, PNG, and WebP files up to 5 MB, waits for the upload and verification to finish, and displays upload progress on stderr. Custom uploads are available only after acceptance and are limited to five attempts per 24 hours.

Delete the file immediately after the command completes. Run

status

again and verify that the requirements stage is

complete

before reporting that attendance confirmation is done.

录取详情包括参与者身份证件上的全名（必须完全一致）、出生日期、国民身份证或护照号码、紧急联系人、必需的头像确认，以及其他私密信息。参与者必须明确选择其 Clerk 头像、GitHub 头像或自定义上传；绝不能从现有图片推断。建议参与者自行在交互式终端运行以下命令，以免这些值进入 Agent 聊天：

andes confirm

如果参与者明确要求 Agent 代为提交，则使用

andes schema --stage acceptance

获取最新模板，收集所有必填值且不得猜测，将其存储在项目目录之外的 mode-600 临时文件中，并避免打印文件内容。

dateOfBirth

使用

YYYY-MM-DD

格式，并且必须是过去的真实日期。Shirt size 是这场线下活动的必填项。使用以下命令验证文件；成功响应不会回显其内容：

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

添加到 confirm 命令中。不要将图片字节复制到 JSON 文件或聊天中。CLI 接受不超过 5 MB 的 JPEG、PNG 和 WebP 文件，会等待上传及验证完成，并在 stderr 中显示上传进度。自定义上传仅在录取后可用，且每 24 小时最多尝试五次。

命令完成后立即删除文件。再次运行

status

，验证 requirements 阶段为

complete

后，才能报告出席确认完成。

Build with your team and publish updates

与团队构建并发布进展

During the event, read

andes project --help

and

andes team --help

before using these commands. Upgrade the CLI if the project commands are unavailable. Use

andes --output json team

and

andes --output json project

to learn the current team and submission. Use

andes --output json project updates

to read the update history. Any member can publish an update or edit the shared submission. Use the team name as the project name; rename it with

andes --output json team rename --name "New team name"

when requested. Never create another project name.

Help the team choose its next useful step. When direction is unclear, ask the questions that resolve the uncertainty, rather than running a fixed interview:

Who has this problem, and what do they do today?
What is the most important thing the product needs to do right now?
What is blocking the team, and what concrete help would unblock it?
Which decision did we make, what evidence supports it, and what did we leave out?
What can a person actually try in the next demo?

At a meaningful milestone, a change of direction, a working demo, or a blocker that mentors could help with, inspect the latest shared update and suggest sending another if there is new information. During an active work session, check again after substantial progress or roughly an hour without a useful update. Do not send repetitive updates or interrupt every code change. This skill runs during active sessions; it does not create a background timer.

If the participant says "send an update to the mentors/judges", that authorizes preparing and publishing a factual update. Do not ask for the same permission again. If the agent only suggests an update, offer the draft and obtain the participant's go-ahead before publishing. Standing authorization from the participant in this session to publish progress updates also applies. Base the content on the work inspected and the participant's statements. Distinguish verified results from plans and unknowns. Never invent user tests, performance numbers, impact, or completed features.

A useful Markdown update says what changed, why the team chose it, what works, what is blocked, what help is needed, what was deployed, which tools or services the team used, and what comes next. Omit sections that have no useful information. Include relevant public demo links. Exclude secrets, tokens, private user data and confidential material. The update is shared with the organization and can become public in the project gallery with the author's public name and timestamp. Publishing saves a log for review; it does not send email or promise an immediate mentor response.

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

Use direct text by default. For longer Markdown,

project update --file /path/to/update.md

is also supported; a file is optional. A successful update returns only the saved entry and the total. Use

project updates

to read the full history. Read the success envelope and verify the saved content before claiming it was published. If a write times out, inspect the history before retrying so that you do not append the same update twice.

The four event tracks are Clima y Territorio (

environmental

), Movilidad y Transporte (

transport

), Educación Escolar (

education

), and Seguridad (

security

). Mobility includes public transport within Lima and passenger transport, regional connections, freight and distribution in other regions. Each track allows 25% of the current team count, rounded up; the event has at most 36 teams overall. Existing track selections survive capacity reductions. Use

andes team

to read current availability and

andes team track

to select.

活动期间，在使用这些命令前，先阅读

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"

重命名。绝不能创建另一个项目名称。

帮助团队选择下一项有价值的行动。方向不明确时，应提出能够消除不确定性的问题，而不是执行固定访谈：

哪类人面临这个问题，他们今天如何处理？
产品现在最重要必须做到什么？
什么阻碍团队，需要什么具体帮助来解除？
我们做了什么决定，有哪些证据支持，遗漏了什么？
下次 demo 中人们实际可以尝试什么？

在重要里程碑、方向变化、demo 可运行，或出现导师可协助解决的阻塞时，检查最新的共享更新；如果有新信息，建议再发送一条。在活跃工作会话中，若取得了实质进展，或大约一小时没有有用更新，则再次检查。不要发送重复更新，也不要在每次代码变更后都打断。此 skill 在活跃会话中运行；它不会创建后台计时器。

如果参与者说“send an update to the mentors/judges”，即授权准备并发布事实性更新。不要再次询问同一权限。如果 Agent 只是建议发布更新，则提供草稿并获得参与者同意后再发布。参与者在本次会话中授予的持续发布进展更新授权同样有效。更新内容应基于已检查的工作和参与者的陈述。区分已验证结果、计划和未知事项。绝不能臆造用户测试、性能数字、影响或已完成的功能。

一份有用的 Markdown 更新应说明改了什么、团队为何这样选择、哪些内容可用、什么被阻塞、需要什么帮助、部署了什么、使用了哪些工具或服务，以及下一步是什么。省略没有有用信息的章节。包含相关的公开 demo 链接。排除 secrets、tokens、私密用户数据和机密材料。该更新会与组织共享，并可能以作者的公开姓名和时间戳出现在项目 gallery 中。发布会保存一条供审核的日志；它不会发送 email，也不会承诺导师立即回复。

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

；file 为可选项。成功更新只返回已保存条目和总数。使用

project updates

读取完整历史。声明已发布前，读取成功 envelope 并核对保存内容。如果写入超时，重试前先检查历史，避免重复追加同一条更新。

四个活动赛道是 Clima y Territorio（

environmental

）、Movilidad y Transporte（

transport

）、Educación Escolar（

education

）和 Seguridad（

security

）。Mobility 包括利马市内公共交通和客运、其他地区的区域连接，以及货运与配送。每条赛道最多容纳当前团队数的 25%，向上取整；整个活动最多有 36 支团队。现有赛道选择在容量缩减后仍然有效。使用

andes team

读取当前可用名额，使用

andes team track

进行选择。

Submit and maintain the event project

提交并维护活动项目

Read the participant guide at

https://hacktheandes.com/guide

and the delivery conditions at

https://hacktheandes.com/participation-terms

for current event instructions. These project submissions are separate from admission applications and challenge submissions.

A project submission needs exactly these deliverables, using the existing team name:

A live deployment URL for the working application.
A presentation URL, such as Canva, Google Slides or a coded presentation.
A GitHub repository URL, such as
```
https://github.com/team/project
```
. Read the Git remote to find it; confirm with the participant if the remote is ambiguous.
A Markdown description explaining the problem, intended users, working solution and known limitations.

Participants cannot connect their laptops to the event's presentation equipment. The organization opens the submitted links on its own computer. Check both URLs from a signed-out or private browser session when possible. Verify that there are no access requests, personal login dependencies or local files. Do not claim a link is accessible unless you checked it. If access cannot be verified, tell the participant what remains to check.

Encourage an early submission once the four deliverables are ready. The same submission can be edited later, including one field at a time. Ask only for missing deliverables. Inspect the repository and current deployment to prepare an accurate Markdown description. Do not invent deployment or presentation URLs. An explicit request to submit or update the project authorizes that action; otherwise show the prepared submission and ask whether to submit it.

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

Check the returned saved submission, including every changed field. Any teammate can edit it, so read fresh state before acting and coordinate conflicting edits. If the last member leaves or joins another team, the old team dissolves and releases its track and capacity. The organization retains its submission and update history in a private archive. That archive is not part of the public gallery and does not transfer to the new team.

The public gallery at

https://hacktheandes.com/projects

starts hidden and opens when the organization enables it. Do not promise a Sunday opening time. Once published, a submitted project's page includes its description, URLs and update history. Remind the team to exclude private data from all of these fields.

阅读参与者指南

https://hacktheandes.com/guide

和交付条件

https://hacktheandes.com/participation-terms

，了解当前活动说明。这些项目提交与录取申请和挑战提交相互独立。

项目提交需要使用现有团队名称，并恰好提供以下交付物：

可正常工作的应用的有效 deployment URL。
演示文稿 URL，例如 Canva、Google Slides 或代码制作的演示文稿。
GitHub 仓库 URL，例如
```
https://github.com/team/project
```
。读取 Git remote 以查找它；如果 remote 有歧义，则向参与者确认。
一份 Markdown 说明，解释问题、目标用户、可用的 solution 和已知限制。

参与者无法将笔记本电脑连接到活动的演示设备。组织方会在自己的电脑上打开提交的链接。应尽可能在已退出登录或无痕浏览器会话中检查两个 URL。验证不存在访问请求、个人登录依赖或本地文件。除非实际检查过，否则不要声称链接可访问。如果无法验证，告诉参与者还需检查什么。

四项交付物准备好后，鼓励尽早提交。同一提交之后可以编辑，包括一次只改一个字段。只询问缺失的交付物。检查仓库和当前部署，以准备准确的 Markdown 描述。绝不能臆造 deployment 或 presentation 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

检查返回的已保存提交，包括每个变更字段。任何队友都能编辑，因此操作前读取最新状态，并协调冲突编辑。如果最后一名成员离开或加入另一团队，旧团队会解散并释放其赛道和容量。组织方会在私有 archive 中保留其提交和更新历史。该 archive 不属于公开 gallery，也不会转移给新团队。

公开 gallery

https://hacktheandes.com/projects

初始隐藏，组织启用后开放。不得承诺周日的开放时间。发布后，项目页面包含描述、URL 和更新历史。提醒团队从所有这些字段中排除私密数据。

Failures

失败

ok: false

, report

error.code

error.message

, and

requestId

. Resolve local validation failures before showing the final summary. Correct mechanical issues directly when the participant's answers do not change; involve them when an answer or consent must change. For admission, attendance and challenge submissions, any payload change after final approval invalidates that approval: show the updated summary and ask again. Retry an unchanged failed request only when

retryable

is true. For admission, attendance and challenge submissions, obtain fresh submission approval before retrying. For authentication failures, return to Authenticate the participant. Preserve the request ID for support instead of claiming success or bypassing a failed state.

出现

ok: false

时，报告

error.code

、

error.message

和

requestId

。在显示最终摘要前解决本地验证失败。当参与者答案无需改变时，直接修正机械性问题；当答案或同意必须改变时，让参与者参与。对于录取、出席和挑战提交，最终批准后 payload 的任何变更都会使批准失效：显示更新后的摘要并再次询问。仅当

retryable

为 true 时，才重试未发生变化的失败请求。对于录取、出席和挑战提交，重试前重新获得提交批准。对于身份认证失败，返回对参与者进行身份认证。保留 request ID 以便支持处理，不要声称成功，也不要绕过失败状态。