第三题改为数独挑战，开发材料集中管理并改为当面考察

README.md

@@ -11,7 +11,7 @@
 | --- | --- | --- | --- |
 | [第一题：出门检查器](tasks/01-basics.md) · 必做 | 学习 Swift 基础，独立编写并运行一个清单检查程序 | `main.swift`、真实运行截图 | 仅可辅助学习和讲解基础知识；解题、编码与排错须独立完成 |
 | [第二题：为一个小麻烦设计 App](tasks/02-design.md) · 必做 | 形成自己的方案，用草图和操作示例说明 | 一份 `design.pdf` | 仅可辅助润色、排版和制图等表达工作；构思与设计由本人完成 |
-| [第三题：把想法做成 App](tasks/03-development.md) · 选做 | 开发第二题方案，或统一题目“出门前” | 个人 Fork 中的项目、需求说明、实际运行展示 | 允许使用 AI 辅助开发，须亲自检查和说明 |
+| [第三题：把想法做成 App](tasks/03-development.md) · 选做 | 开发第二题方案，或数独游戏 | 个人 Fork 自行开发；无需提交，当面展示与考察 | 允许使用 AI 辅助开发，须亲自检查和说明 |
 
 第二题不需要编程基础，可以独立于第一题完成。第三题未选做不扣共同题成绩，挑战完成情况单独记录。
 
@@ -24,7 +24,7 @@
 ## 提交安排
 
 - **第一、二题**：整理到同一个以“年级＋姓名”命名的个人文件夹，例如 `25刁泓宁`，放在原仓库的 `submissions/` 下。通过本仓库的个人分支提交，再发起指向 `main` 的 PR，由干部审核合并。具体目录和步骤见[前两题提交说明](submissions/README.md)。
-- **第三题：**完整项目保留在个人 Fork，在原仓库提交 Fork 链接及用于验收的提交版本。作品入口的提交步骤及 Fork 可见性安排待发布时说明。
+- **第三题**：Fork 后自行开发，无需向原仓库提交材料、PR 或作品入口，也不要求录屏。有做的同学当面展示与交流；最好提前告知负责人仓库链接和项目位置，方便先看代码，并确认仓库可访问。
 - 截止日期与时刻、材料可见范围、环境说明、求助渠道：**待公布**。
 
 源码、截图和录屏应对应实际完成的版本。允许如实提交未完成的部分，不得拼造运行结果或编造经历。遇到环境或提交问题时，保留当前文件与现象，按正式通知的渠道求助。
@@ -38,10 +38,10 @@
 ## 仓库目录
 
 ```text
-tasks/                 三道题的题面与需求说明
+tasks/                 三道题的题面
 templates/             第二题简版设计说明书模板
 submissions/           前两题个人提交文件夹与提交说明
-development/           第三题个人 Fork 的开发目录
+development/           第三题详细需求、辅助材料与个人 Fork 开发目录
 README.md              考核入口与统一说明
 .gitignore             Swift/Xcode 常见临时文件忽略规则
 ```

development/README.md

@@ -1,25 +1,15 @@
 # 第三题开发目录
 
-选做第三题时，先 Fork 本仓库，再在个人 Fork 的这个目录中放置项目。完整要求见[第三题题面](../tasks/03-development.md)。本目录目前只有说明，没有 App 成品或解题代码。
+先阅读[第三题简要题面](../tasks/03-development.md)，再 Fork 仓库，在个人 Fork 的本目录中开发。无需向原仓库提交材料或 PR；最好在面谈前提前告知负责人仓库链接和项目位置，方便预先看代码。
 
-建议按下面的方式组织；可以按自己的项目需要调整：
+## 开发材料
 
-```text
-development/
-├── README.md          改写为自己的作品说明与运行方法
-├── requirements.md    简短需求、路线选择与完成情况
-├── App/               Swift 项目和必要资源
-└── demo/              实际运行录屏，或录屏访问说明
-```
+- [开发需求](requirements.md)：两条路线共用标准、路线 A 说明、路线 B 数独的基础需求与验收示例。
+- [数独题库](sudoku-puzzles.json)：3 道固定的标准 9×9 数独；每题具有唯一解，不含答案与求解代码。
+- [作品说明模板](project-notes.md)：在个人 Fork 中填写，帮助负责人打开项目、了解完成情况。
 
-在个人 Fork 中，请将这份 README 改为自己的作品入口，至少说明：
+题库采用 JSON：`id` 为题目标识，`name` 为显示名称，`grid` 为按行排列的 9×9 整数数组，`0` 表示空格，`1`–`9` 为不能修改的初始数字。数组下标从 0 开始。可以读取该文件，也可以将数据转成适合自己项目的结构；不限定存储或界面实现方式。
 
-1. 作品名称、选择路线 A 还是 B、核心用途。
-2. 怎样打开与运行项目，以及实际使用的工具版本和运行设备或模拟器。
-3. 已完成、未完成和已知问题；路线 B 可对照 R1–R5 逐项说明。
-4. 需求说明和真实演示的位置，演示应覆盖核心操作、边界情形与重启恢复。
-5. AI 使用方式、本人怎样检查结果，以及一次真实问题的处理或验证、调整。
+建议保留本目录材料，将 Swift 项目及所需资源放在 `App/` 下，并填写 `project-notes.md`。不要把构建产物或账号凭据放进仓库。设备与运行环境安排之后再统一说明。
 
-提交时，将个人 Fork 地址和验收用的提交版本通过原仓库后续公布的入口提交。无需将完整 App 合并回原题仓库。保留题面和模板文件，避免把构建产物、个人账号凭据或设备专属文件提交到仓库。
-
-设备环境、录屏提交方式及大小限制会在正式发布时补充。
+不要求提交录屏、制作汇报 PPT 或上架应用。面谈以真实运行、代码和交流为准；工具或 AI 生成的结果需要自己检查。

development/project-notes.md

@@ -0,0 +1,12 @@
+# 作品说明
+
+在个人 Fork 中简要填写，供负责人提前看代码和当面交流使用。无需提交到原仓库。
+
+- **作品名称与路线**：[路线 A / 路线 B]
+- **项目位置与运行方法**：[打开哪个文件，怎样运行；实际使用的工具版本与设备或模拟器]
+- **需求与完成情况**：[路线 A 简述核心流程、保存的数据、两种边界情况及设计调整；路线 B 对照 R1–R6 写明已完成和未完成项]
+- **已知问题**：[如实写明；尚未验证的功能请注明]
+- **运行与检查经历**：[简述自己实际验证了什么，以及遇到的问题或一次调整]
+- **AI 使用情况**：[用了哪些工具，具体帮助完成了什么，自己完成了什么；未使用则写“未使用”。仅用于了解工作过程，不单独评分]
+
+面谈前最好提前告知负责人仓库链接和项目位置，并确认能够访问；不要求另外准备录屏或汇报材料。

development/requirements.md

@@ -0,0 +1,53 @@
+# 第三题开发需求
+
+## 两条路线共用标准
+
+1. 用 Swift 做出可交互的 App，界面优先采用 SwiftUI；能从开始到结束完成一条核心流程。
+2. 用户输入或选择会改变应用内容，并获得明确反馈。
+3. 核心用户数据保存在本地，彻底退出并重新启动后仍可恢复。
+4. 处理与本场景相关的异常或边界情况，不能只展示静态页面。
+5. 在[作品说明](project-notes.md)写清运行方法、实际完成情况与已知问题，能当面演示并讲解。
+
+不要求登录、服务器、云同步、复杂架构或应用商店上架。额外功能不能代替核心流程。
+
+## 路线 A：开发第二题方案
+
+选择第二题中一个可完成的小版本。简要说明用户、核心操作、要保存的数据、至少两种边界情况的预期行为，以及与第二题设计不同的地方；可以引用第二题 PDF，不必重写长文。实现上述共同标准，功能应自然服务于自己的用途。
+
+## 路线 B：数独游戏
+
+### 游戏规则与范围
+
+棋盘由 9 行、9 列组成，分为 9 个 3×3 宫。将空格填入 1–9，使每行、每列、每宫中的数字均不重复。初始数字不可修改。只有全部填满且满足规则才算完成；填满但有冲突不能判胜。
+
+使用提供的[固定题库](sudoku-puzzles.json)即可，不要求随机生成数独或编写求解器。题库中的 0 表示空格，不能作为玩家填写的数字。
+
+### 必须实现的功能
+
+| 编号 | 需求 | 可以检查的结果 |
+| --- | --- | --- |
+| R1 | 选择题目并开始游戏 | 能选择题库中的不同题目，正确显示 9×9 棋盘和 3×3 宫边界，能区分初始数字与玩家填写的数字 |
+| R2 | 选格、填数、修改与擦除 | 仅空白起始格可编辑；可输入 1–9、替换已填数字或擦除；初始数字始终不可修改 |
+| R3 | 冲突检查 | 对玩家数字与同行、同列或同宫数字重复的情况给出明确反馈；可实时检查或通过“检查”按钮触发；修改或擦除后能更新结果 |
+| R4 | 判断完成 | 全部填满且无冲突时明确提示完成；有空格或存在冲突时不能判胜 |
+| R5 | 重新开始与换题 | 重新开始当前题、换题都需确认；确认后清除当前玩家填写，载入对应初始棋盘；取消则保留当前题与进度 |
+| R6 | 保存当前进度 | 保存当前题目及玩家填写；彻底退出、重新启动后恢复。修改、擦除、重新开始和换题的结果也要保存 |
+
+只需保留当前一局，不要求保存每道题的独立进度。重新打开 App 不应自动清空棋盘；完成后重新打开仍应显示已完成的棋盘或完成状态。
+
+### 边界行为
+
+- 没有选中格子或选中初始数字时，输入与擦除不改变棋盘。
+- 只允许填写 1–9；采用数字键盘或屏幕按钮均可，其他输入不得造成非法数据或崩溃。
+- 检查重复时忽略空格，并排除格子自身；不能把“不重复但尚未证明正确”直接当成完成。
+- 首次启动无保存记录时能正常选题或进入默认题；重新开始、换题与继续当前局应有清楚区分。
+
+### 当面演示参考
+
+选一题 → 尝试修改初始数字（应无效）→ 填入一个会重复的数字并检查 → 修改或擦除，反馈随之更新 → 退出并重新启动，题目及填写恢复 → 重新开始但取消，进度保留 → 确认重新开始，只保留初始数字 → 换题并重启，恢复新题。
+
+另外准备展示一次合法完成，并验证“填满但有冲突”不会误判完成。可以提前准备接近完成的真实游戏进度；不要用固定成功页面代替判断逻辑。
+
+### 可选扩展
+
+计时、笔记候选数、撤销、提示、难度分级、随机出题、动画等均不要求。先完成基础需求，再按兴趣扩展。

development/sudoku-puzzles.json

@@ -0,0 +1,47 @@
+[
+  {
+    "id": "sudoku-01",
+    "name": "练习 1",
+    "grid": [
+      [0, 4, 0, 0, 0, 7, 0, 0, 0],
+      [9, 0, 7, 5, 0, 2, 0, 0, 0],
+      [5, 6, 0, 0, 0, 3, 0, 1, 7],
+      [1, 0, 5, 0, 2, 8, 0, 0, 9],
+      [6, 2, 0, 0, 3, 9, 0, 7, 5],
+      [4, 0, 0, 1, 0, 5, 6, 0, 0],
+      [0, 0, 6, 2, 0, 4, 0, 9, 1],
+      [3, 0, 1, 7, 0, 0, 2, 0, 0],
+      [0, 0, 0, 0, 9, 1, 0, 5, 0]
+    ]
+  },
+  {
+    "id": "sudoku-02",
+    "name": "练习 2",
+    "grid": [
+      [0, 0, 0, 5, 4, 0, 7, 1, 8],
+      [0, 0, 0, 7, 0, 0, 0, 9, 6],
+      [0, 0, 8, 0, 0, 0, 0, 0, 3],
+      [0, 6, 5, 4, 0, 7, 1, 0, 0],
+      [0, 0, 2, 9, 0, 0, 0, 3, 7],
+      [0, 0, 7, 1, 8, 2, 0, 0, 5],
+      [3, 7, 0, 0, 2, 9, 0, 0, 0],
+      [6, 5, 4, 0, 7, 1, 0, 0, 0],
+      [8, 0, 9, 6, 0, 4, 0, 0, 1]
+    ]
+  },
+  {
+    "id": "sudoku-03",
+    "name": "练习 3",
+    "grid": [
+      [3, 6, 0, 0, 0, 0, 0, 1, 0],
+      [0, 1, 9, 3, 0, 4, 7, 2, 5],
+      [0, 0, 0, 8, 1, 9, 3, 6, 4],
+      [0, 0, 2, 5, 0, 0, 0, 0, 6],
+      [5, 8, 1, 0, 3, 0, 0, 7, 0],
+      [0, 0, 0, 4, 7, 0, 0, 0, 1],
+      [0, 0, 0, 0, 0, 7, 2, 0, 0],
+      [0, 5, 0, 1, 0, 3, 0, 4, 7],
+      [6, 0, 7, 0, 0, 0, 1, 9, 0]
+    ]
+  }
+]

tasks/03-development.md

@@ -2,89 +2,26 @@
 
 - **类型**：开发挑战（选做）
 - **基础要求**：使用 Swift 开发可交互的 App，界面优先采用 SwiftUI
-- **提交材料**：个人 Fork 中的项目、需求说明与实际运行展示
-- **AI 规则**：允许辅助开发及生成主要代码，作品须亲自运行、检查，并在二面展示和说明
+- **参与方式**：Fork 仓库自行开发，无需向原仓库提交；面谈前请提前告知负责人仓库位置
+- **AI 规则**：允许辅助开发及生成主要代码，作品须亲自运行、检查，并能当面展示和说明
 
 ## 两条题目路线
 
-### 路线 A 开发第二题的设计
+- **路线 A：开发第二题的设计。** 从自己的方案中选择一个范围可控的版本实现，可以在开发时调整，并简述与原设计的不同。
+- **路线 B：开发数独游戏。** 制作一个可以选择题目、填写与擦除数字、检查冲突、判断完成并保存进度的数独 App。提供固定题库，不要求编写出题算法。
 
-从第二题方案中选择一个范围可控的版本实现。可以在开发时调整方案，简述调整原因。
+详细开发要求、题库和作品说明模板均放在 [development/](../development/README.md)。两条路线都以完成可实际操作的核心流程为目标，不以堆叠功能或复杂架构为要求。
 
-在项目中放一份简短需求说明：主要用户、要完成的操作、首版功能、重要数据、正常与异常情形的预期结果，以及与原设计不同的地方。第二题的 PDF 可以引用，不必重新写成长文。
+## 怎样参与与当面考察
 
-### 路线 B 完成统一题目 出门前
+先 Fork 本仓库，在个人 Fork 的 `development/` 中开发并保留题目材料。代码保存在自己的仓库即可，**无需向原仓库提交材料、发起 PR 或登记作品入口**，也不要求录屏。
 
-开发一个可反复使用的出门清单 App，帮助用户建立物品清单、检查是否准备齐全，并在下次使用时保留自己的内容。
+有做这道题的同学，最好在面谈前提前告知负责人个人仓库的链接和项目位置，并确认负责人能够访问，方便先看代码。具体联系与面谈安排后续通知。面谈时展示实际运行的作品，交流实现、验证过程和遇到的问题；未完成的部分也可以如实展示。
 
-下面的需求说明就是路线 B 的实现依据。你可以自行决定布局、视觉和代码组织。
+## AI 与考察重点
 
-## 两条路线共用的完成标准
+可以让 AI 帮助拆分开发任务、生成主要代码、解释、排错和修改。你需要亲自运行和检查结果，并能结合自己的作品说明核心操作怎样实现、数据怎样变化和保存，以及怎样发现和处理问题。现场可能讨论一个小变化及如何实现、验证，实践环节允许继续使用 AI，不要求背诵全部代码或按手写代码比例评判。
 
-1. 有一个可以真正操作的界面，能够完成需求说明中的一条完整核心流程。
-2. 用户能够输入或选择信息，操作会改变应用内容，并看到相应结果或反馈；不能只是几个静态页面互相跳转。
-3. 至少一类与核心用途相关的用户数据能够本地保存，并在彻底退出、重新启动 App 后恢复。例如清单内容、收藏、当前进度或用户配置。
-4. 能处理至少两种与自身场景相关的空白、无结果、取消、重复或操作失败情形，且行为与需求说明一致。
-5. 明确列出已完成、未完成和已知问题，提交足以复现的项目与运行说明。
+路线 A 中作为第二题提交的设计文档仍遵守[第二题的 AI 使用范围](02-design.md)，开发阶段按本题规则使用 AI。作品说明中的 AI 使用情况仅用于了解工作过程，不单独评分。
 
-自选题不按功能数量堆难度。共同标准应自然服务于你的用途，不能为了凑项塞入无关功能。如果第二题方案过大，可先实现满足这些标准的小版本。统一题仍需完整实现下方明确列出的基础需求。
-
-## 统一题需求说明 出门前
-
-### 用户与目标
-
-用户想在出门前逐项检查要带的东西，并在第二天继续使用同一份清单。只需维护一张本地清单。
-
-### 必须实现的功能
-
-| 编号 | 需求 | 可检查的结果 |
-| --- | --- | --- |
-| R1 | 新增、修改名称、删除物品 | 操作后列表中出现对应变化；新增项默认未准备 |
-| R2 | 勾选为已准备，或取消勾选 | 每项状态独立变化，可以改回未准备 |
-| R3 | 显示准备进度 | 显示已准备数与总数；全部准备后给出提示；空清单显示创建提示 |
-| R4 | 开始新一轮检查 | 用户确认后，保留全部物品名称，将勾选全部清除；取消时不改变任何数据 |
-| R5 | 本地保存 | 名称、列表内容与准备状态在彻底退出、重新启动后恢复；新增、改名、删除和重置结果同样保存 |
-
-### 统一题的边界规则
-
-- 空名称或只有空白的名称不能保存，并向用户说明原因；名称首尾空白在保存前去掉。
-- 同名物品可以存在；修改、删除或勾选其中一项不能误改另一项。
-- 删除物品、取消勾选或开始新一轮后，进度及时更新。
-- 清单为空时不显示“全部准备好了”，而是引导新增物品。
-- 确认开始新一轮和正常继续检查是不同操作，重新打开 App 不应自动清除状态。
-
-### 一次验收示例
-
-从空清单开始 → 添加“校园卡”和两条“水杯” → 只勾选其中一条水杯，进度为 1/3 → 将另一条改为“钥匙”，三条仍独立 → 删除未勾选的“钥匙”，进度为 1/2 → 退出并重新启动，内容及进度恢复 → 发起新一轮但取消，仍为 1/2 → 再次发起并确认，保留两条名称，进度变为 0/2 → 再次重启仍为 0/2。
-
-另外验证空白名称被拒绝，以及最后一条物品删除后出现空清单提示。
-
-### 范围限制
-
-不要求账号登录、服务器、云同步、通知、地图、多平台适配、应用商店上架或复杂架构。额外功能可以展示，但不能替代基础需求。只有一两个页面也可以是合格的完整作品。
-
-## Fork 与提交
-
-Fork 本次考核仓库，在个人 Fork 的 [development/](../development/README.md) 目录完成项目，保留原题文件。两条路线都采用这一方式，不要求把完整 App 合并回原题仓库。
-
-提交内容包括：
-
-- 完整源码和打开、运行项目的方法；
-- 路线选择与需求说明。路线 B 可引用本题 R1–R5，补充自己的完成情况；
-- 实际运行录屏，覆盖核心操作、至少两种边界情形，以及退出重启后的恢复；
-- AI 使用方式、本人如何检查结果、一个遇到的问题与处理过程。没有遇到明显故障可说明一次验证或调整，不必编造经历；
-- 个人 Fork 地址及用于验收的提交版本，在原题仓库提交作品入口。
-
-开发目录已预留，见 [开发目录说明](../development/README.md)。截止时刻、作品入口的提交步骤、Fork 可见性和具体设备操作将在正式发布时统一说明。
-
-## AI 与二面
-
-可以让 AI 协助需求拆分、写代码、解释、排错和修改，甚至由 AI 生成主要代码；你需要负责判断它是否符合要求，并亲自操作验证。选择路线 A 时，第二题的设计文档仍须遵守[第二题的 AI 使用范围](02-design.md)：构思与设计由本人完成，AI 仅辅助润色、排版和制图等表达工作；附带的 AI 使用说明仅作过程采样，不参与评分。
-
-二面重点看：能否演示完整流程；是否知道重要信息在哪里变化和保存；如何发现结果不符合需求；为什么保留某个实现或调整。必要时会讨论一个小变化以及怎样实现、验证，实践环节允许继续使用 AI。
-
-不要求背诵全部代码，也不按手写代码比例评判。能使用 AI 把作品做成、检查清楚并说明关键选择，同样是有效能力。
-
-## 挑战完成标记
-
-记录为“未选做”“已尝试”“作品完成待二面确认”或“挑战通过”。挑战通过需要符合路线需求与共同完成标准，并经真实运行和二面确认。未选做不扣共同题成绩。
+选做与否不影响前两题成绩。挑战完成标记根据实际作品与当面考察确认，记录为“未选做”“已尝试”“作品完成待面谈确认”或“挑战通过”。