交付：首错、改动和健康检查结果
场景：本节验收。实验机上的服务被做了一处手脚，起不来。 任务：找出首个错误、修掉它、重新启动、用健康检查验证。跑好运行 ~/check。 （判分只看你在受控容器里做出的真机产物：找东西类到 ~/对照表.txt 查标记填进题里；改状态类改完运
一次部署算不算完成，看什么
判断一次部署"真的完成了"，最硬的依据是【0】。
服务真的能干活吗
健康检查通了之后，再请求一次真正的业务接口： 返回的列表里有几条任务？ $ curl -s http://127.0.0.1:8000/tasks {"ok": true, "data": [{&qu
拿到一台空机器，先摸清情况
场景：最终挑战第一步：一台空机器和一个仓库地址 ~/origin.git，没有分步提示。 任务：自己判断该先做什么，把这次部署要用到的四类交付物（代码、依赖、配置、数据）都找齐；顺便数清仓库里有几个版本标签，到 ~/对照表.txt 里查那个
取到指定版本
场景：情况摸清了，可以动手了。要部署的版本在 ~/说明.txt 里。 任务：把 ~/origin.git 取下来放到 ~/svc，切到指定版本，确认 HEAD 对得上。改好运行 ~/check。 （判分只看你在受控容器里做出的真机产物：找东
配置、依赖、数据都备齐
场景：~/svc 已是要部署的版本；端口在 ~/说明.txt 里。 任务：按仓库里的 README，把依赖、配置和数据目录都准备好，让 python3 app.py --check 通过。⚠️ 真配置不在仓库里，得你自己生成。改好运行 ~/
启动，并从网络端访问它
场景：四类交付物都齐了。 任务：把服务启动起来，从网络端请求 /tasks（curl），拿到任务列表。跑好运行 ~/check。 （判分只看你在受控容器里做出的真机产物：找东西类到 ~/对照表.txt 查标记填进题里；改状态类改完运行 ~/
故意弄坏一次，再自己恢复
场景：服务已经能跑（依赖/配置/数据齐全，还没启动），现在演一次事故。 任务：先把服务弄成起不来的状态（比如挪走数据文件）并启动一次让它在日志里留下 FATAL；然后只靠日志把它恢复回可用，重新启动，用 /healthz 证明恢复成功。跑好
演一次回滚
场景：服务跑的是新版本（已部署、还没启动）；数据文件里有一条本次实验现写的任务，回滚不能把它弄丢。上一个版本在 ~/说明.txt 里。 任务：把版本切回上一个，重新走一遍启动和验证（/healthz 200、/version 是旧版本）；确
交付：从代码到可访问服务的完整证明
场景：最终作品：一台全新的机器，仓库 ~/origin.git，要部署的版本和端口在 ~/说明.txt 里，全程没有分步提示。 任务：独立完成从取代码到服务可访问的全过程（取代码 → 切版本 → 依赖/配置/数据 → 启动 → /healt