FlyPython
Sign inStart a challenge

Hands-on with ZCode · Challenge 05 · 中文版

Lesson 5: Take the workflow to your own project

Checkpoint l0510 ptsself-reported — code from verify.pyZCode desktop app

The pattern generalizes: contract as goal, task list, bounded execution, Git-state review — run the same loop on a project you actually own.

Six agent-tool courses share this challenge. ZCode desktop app-specific steps are still being written — until they land and pass review, this page defers its canonical to the primary course's copy.

Doing this with your agent? One sentence starts the whole course:

Read https://flypython.com/skills/flypython/SKILL.md and start the FlyPython course `hands-on-with-zcode`.

Lesson 5: Take the workflow to your own project

Objective

You apply the whole loop — contract, goal, task list, bounded execution, Git-state review, written verification — to a script or project you actually own, and record what happened.

Why this lesson exists

A course folder is a safe sandbox; your own codebase is not. The point of the last four lessons was never the report tool — it was a repeatable way to drive an agent that keeps you in charge of what ships. This checkpoint exists to prove the transfer happened. It is self-attested: only you know whether the loop actually ran.

The lesson

Pick a real script you own — one with a bug you have been putting off, or a behavior you want but have not written. Then run the same five moves:

  1. Contract. Write the task contract first: inputs, outputs, error cases, and “done means <command> exits 0”. One short paragraph, every sentence testable.
  2. Goal. Open the project as a ZCode workspace and give the agent a goal built from that contract — including the boundaries: which files may change, which are read-only, the dependency policy.
  3. Bounded execution. Read the task list before it runs; check the Git state after each task; recover instead of stacking fixes.
  4. Verify. Run the verification command, then do the review the suite cannot do — walk one real input end-to-end and check the output by hand.
  5. Record. Write the three lines: verified / not verified / known limits.

On long tasks, remote control lets you read status and send instructions from your phone while the desktop stays the runtime — useful for checking in, not a substitute for reviewing the diff when it lands.

If the loop fought you — the task was too small to need a contract, or too vague to test — that is a finding too. Write down where the shape did not fit; that judgment is the actual skill.

Exercise

If your project has more than one boundary worth pinning, draft the next contract line now — you will want it when you set the next goal.

Checkpoint

This checkpoint is self-attested: claim it when you can answer:

  1. What was your contract’s “done means” command?
  2. Which task did you push back on or recover?
  3. What is on your “not verified” list that a stranger would assume was covered?

Expected evidence

Your contract paragraph, the goal statement you set, and the three-line verification record. These are yours — they are the proof the workflow transferred.

Hints

Stuck? Open one at a time.

Hint 1 — What this checkpoint tests

Self-attested: you confirm you applied the loop to your own project. The evidence is your contract, your task list, your reviewed diff — not a code we can check.

Hint 2 — Carry the shape, not the code

What transfers is the loop: contract first, goal decomposed into checkable tasks, boundaries watched in Git state, verification written down. Long tasks can even be monitored remotely — the desktop remains the runtime.

Hint 3 — When you are done

Your own project has a contract, one bounded change you can explain, and a verified/not-verified/known-limits record — or a documented reason the loop did not fit.

Submit

Done? Record it.

The 8-character code verify.py progress printed for this checkpoint — from the browser, or straight from your agent.

Youbrowser

Submit the claim code

Your agentauto-submit

Let the agent solve and submit

Hand it this checkpoint (copy button on hover) — it solves, verifies, and submits on its own:

Work on the FlyPython challenge "Hands-on with ZCode" (course id course-zcode), checkpoint l05.
Machine-readable brief: https://flypython.com/api/challenges/hands-on-with-zcode
Open the course folder and read TASK.md first — it is the contract.
Rules: smallest change, no new dependencies, never edit tests/ or solution/.
Check with python verify.py until its gates pass, then report each claim code to me.
Target: solve only checkpoint l05, and submit it as soon as it passes.

With a token from your agent page (env FLYPYTHON_TOKEN), it records the result directly:

curl -X POST https://flypython.com/api/claims \
  -H "Authorization: Bearer $FLYPYTHON_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"claims":[{"course":"hands-on-with-zcode","checkpoint":"l05","code":"<8-char code>"}]}'

Or install the full FlyPython agent skill once and skip the paste.

Files

The starter and verifier

Solving runs on your machine — your agent fetches the course files itself via /api/challenges/hands-on-with-zcode/files; you download nothing by hand. Prefer reading the source? Browse the folder on GitHub ↗