Skip to content

COURSE.md

Latest commit

 

History

History
108 lines (87 loc) · 5.38 KB

COURSE.md

File metadata and controls

108 lines (87 loc) · 5.38 KB
Raw
id course-verify-ship
type course
title From "it runs" to "it ships": verifying AI-generated code
summary Build the release-evidence machine your AI-written project is missing — a ship check that runs the tests, parses what actually ran, refuses zero-test projects, and writes an honest delivery record.
lang en-US
content_version 4
status reviewed
reviewed_on 2026-11-07
badge
id name_en name_zh requires
course-verify-ship
It runs is not evidence
能跑不是证据
All five checkpoints claimed (L01–L05)
course_id course-verify-ship

From "it runs" to "it ships": verifying AI-generated code

Coach P — guided learning

When the learner asks to start a lesson or requests guided help, act as Coach P. At your first introduction in that session, say:

I'm Coach P, an AI coach running inside your own agent, using your model. I'll help you reason through the task; verify.py checks the objective gates. Reflection checkpoints still need your own answers and explicit confirmation.

Ask what the learner tried and what they expect before suggesting a change. Give the smallest useful hint, then wait for their answer. Name the failing test and explain which contract it checks; do not paste a solution or edit solution/. Follow this course's lesson order and file boundaries. If the learner cannot explain a result, return to that test and ask them to predict the next run. Before --attest or a claim submission, obtain the learner's own answers and confirmation for those checkpoints; never answer or attest on their behalf. The Skill's authorization and human-confirmation gates still apply. For a verification-only or progress request, perform that workflow without forcing a lesson. Coach P is an AI teaching style, not a human teacher or a certification; do not promise learning or career outcomes. FlyPython does not run the model or receive the chat conversation through this workflow; course-file, account, and claim requests are separate API data.

TL;DR: install the FlyPython Skill in your coding agent and let it fetch this course, then say "start lesson 1". (Lesson files arrive via the Skill — you download nothing by hand.) You finish with ship_check.py: one command that turns "the demo worked" into a written delivery record — command, exit code, parsed test count, a verdict that refuses projects with no tests, and an explicit unverified list. Tool-agnostic; Python standard library only.

What you build

A release-evidence builder for small AI-written Python projects. Given a project directory with a ship.json, it runs the configured check command, parses how many tests actually ran and whether they passed, and writes an atomic SHIP-RECORD.json with an honest verdict:

Skin State Data
scenario/green-project/ two passing tests + declared unverified items ship.json, calc.py, tests/
scenario/red-project/ one deliberately wrong expectation the regression under study
scenario/no-tests/ zero tests — the state that must never pass empty tests/

Teaching contract (read this first, agent)

  • Audience: a project owner shipping AI-written Python who cannot yet answer "what proves this release?" with a file instead of a memory.
  • Prerequisites: Python 3.11+ on PATH and any coding agent (taught and reviewed with Claude Code 2.x and Codex CLI 0.x; reviewed 2026-09-12). Standard library only.
  • Lesson order: L01 → L05; never skip the checkpoint.
  • Teaching style: work from the files in this folder; quote the contract line you satisfy; smallest change per failing test; no new dependencies; never edit solution/ or the scenario projects; ask before touching unnamed files.
  • When to stop: a lesson is done when its checkpoint command runs and the learner can explain what failed and why.
  • verify.py: python verify.py starter --expect-failure reproduces the seven listed failures; python verify.py solution passes 10/10.
  • Honesty rules: the record's "unverified" list is the point — never present a passing record as proof of more than it contains.

What this course does NOT cover

Deployment platforms, CI services, performance testing, or staging environments. The product-quality guide on flypython.com covers the wider release checklist; this course builds the evidence core.

Badge contract

  • Badge: It runs is not evidence Badge (badge id course-verify-ship) - earned by claiming all five checkpoints.
  • Challenges: L01-L05 checkpoints, 10 points each; +50 course-badge bonus when all five are claimed on flypython.com.
  • Evidence: python verify.py - L03 (bounded change) and L04 (verify & review) are objectively gated by the suite; L01/L02/L05 are learner-attested.
  • Submission: each test-passed checkpoint prints a deterministic claim code; a reflection checkpoint prints one only after you answer its questions and run python verify.py --attest ID; record it on flypython.com against your account. Self-reported evidence, never a certificate.

Folder map

COURSE.md/COURSE_cn.md, bilingual lessons/, scenario/ projects, TASK.md/TASK_cn.md (the code contract), starter/, solution/, tests/ (10 tests), verify.py, REVIEW.md.

Evidence and licensing

REVIEW.md records the run-through state. Code is MIT; prose is CC BY 4.0 (see repository LICENSE). Teaching drift goes to the course-feedback issue form.