# 🎯 Taskr 實際上是如何運作的？

## 3.3 任務 (Tasks) - 核心積木

### 了解任務階層

任務的組織方式就像是論文的大綱：

```
1.0 建立使用者身分驗證 (父任務 / parent task)
  1.1 設定資料庫資料表 (子任務 / subtask)
    1.1.1 建立 users 資料表 (次級子任務 / sub-subtask)
    1.1.2 加入密碼雜湊 (password hashing) 功能
  1.2 建立登入頁面
    1.2.1 設計登入表單
    1.2.2 加入表單驗證
  1.3 實作登出功能
```

**最聰明的地方在於：** 當 1.1.1 和 1.1.2 都完成時，1.1 會自動標記為完成。當 1.1、1.2 和 1.3 都完成時，1.0 也會自動完成！

### 任務類型說明

每個任務都有一個類型 (Type)，用來告訴您的 AI 這是哪種性質的工作：

  - **setup (設定)** 🔧 - 準備工作（安裝套件、建立資料夾）
  - **analysis (分析)** 🔍 - 釐清問題（研究 API、規劃實作方法）
  - **implementation (實作)** 💻 - 實際動手開發（寫程式碼、建立功能）
  - **validation (驗證)** ✓ - 確保它能運作（檢查邏輯、Code Review）
  - **testing (測試)** 🧪 - 證明它能運作（撰寫測試、執行測試案例）

### 任務狀態流轉

任務會像輸送帶一樣經歷不同的狀態：

1.  **open (待處理)** ⭕ - 等待被開始
2.  **wip (進行中)** 🔄 - 目前正在處理中 (work in progress)
3.  **done (已完成)** ✅ - 已成功完成
4.  **skipped (已略過)** ⏭️ - 刻意略過（不需要執行）

### 單一任務法則 (The One-Task Rule)

這裡有一件非常重要的事：**您的 AI 一次只能處理一個任務**。

為什麼？因為多工處理 (multitasking) 會導致混亂！當您的 AI 將一個任務標記為 "wip" 時，它會透過 `wip_agent_id` 欄位取得該任務的獨佔所有權。沒有其他 Agent 可以碰這個任務，而且這個 Agent 在完成這個任務之前，不能開始另一個任務。

這個規則是在資料庫層級透過 PostgreSQL 觸發器 (triggers) 以及 MCP 處理程式碼來強制執行的！

### 建立新任務

您的 AI 使用 `create_task` 工具來建立任務：

```
您的 AI：「我需要把這個工作拆解成更小的部分」
建立動作：在目前的任務下建立子任務，或是建立一個全新的任務清單
速度：即時
控制權：您的 AI 會根據您的需求自行決定架構
```

**提示：** 對於較大型的專案，請先將您的需求貼到 AI 的聊天視窗中 —— 它將會建立一個更詳盡、結構更完整的任務階層。

### `get_task` 的魔法

當您的 AI 呼叫 `get_task` 時，幕後會發生這些事：

1.  **檢查現有的 WIP** - 「我已經有正在處理的工作了嗎？」
2.  **尋找下一個符合邏輯的任務** - 「按照順序，下一個『待處理 (open)』的任務是什麼？」
3.  **將其標記為 WIP** - 「這個任務現在歸我管了！」
4.  **回傳完整情境** - 任務細節 + 筆記 + 指引規則
5.  **防止衝突** - 沒有其他 Agent 可以認領這個任務

資料庫中的 `get_task_for_agent` 函式會以原子操作 (atomically) 的方式處理這一切！

-----
