Làn đường công nhân Kanban`Làn công nhân là một lớp quy trình mà người điều phối Kanban có thể định tuyến các nhiệm vụ tới. Mỗi làn đường có một danh tính (chuỗi được giao), cơ chế xuất hiện và hợp đồng về những gì nó phải làm với nhiệm vụ sau khi xuất hiện.

Trang này là hợp đồng. Nó tồn tại cho hai đối tượng:
Người vận hành chọn làn đường nào để đi dây vào bảng (cấu hình nào cần tạo, người được phân công sử dụng).
Các tác giả plugin / tích hợp muốn thêm hình dạng làn đường mới (nhân viên CLI bao bọc Codex / Claude Code / OpenCode, nhân viên đánh giá được đóng gói, một dịch vụ không phải của Hermes kéo các tác vụ thông qua API).
Nếu bạn đang tự viết mã công nhân — tác nhân chạy bên trong một làn đường — thì kỹ năng XPROTECTX1XPROTECTX là chi tiết quy trình sâu hơn.
Hệ thống phân cấp

Hermes Kanban  =  canonical task lifecycle + audit trail
Worker lane    =  implementation executor for one assigned card
Reviewer       =  human or human-proxy that gates "done"
GitHub PR      =  upstreamable artifact (optional, for code lanes)

`
``Hermes Kanban sở hữu sự thật về vòng đời — 
`ready
` → 
`running
` → 
`blocked
` / 
`done
` / 
`archived

. Làn đường công nhân thực hiện công việc nhưng không bao giờ sở hữu sự thật đó; mọi thứ họ làm đều quay trở lại qua nhân kanban thông qua các công cụ 
`kanban_*
` (hoặc, đối với các nhân viên bên ngoài không phải của Hermes, thông qua API). Người đánh giá chuyển đổi từ "viết thay đổi mã" sang "hoàn thành nhiệm vụ".

## Làn đường mang lại những gì

Để trở thành làn đường công nhân Kanban, việc tích hợp phải cung cấp ba điều:

### 1. Chuỗi được chuyển nhượng

Người điều phối khớp 
`task.assignee
` với tên hồ sơ Hermes (hình dạng làn đường mặc định) hoặc số nhận dạng không thể sinh ra đã đăng ký (hình dạng làn đường plugin - xem [Adding an external CLI worker lane](#adding-an-external-CLI-worker-lane) bên dưới). Các nhiệm vụ mà người được giao không giải quyết được để lại trên 
`ready
` kèm theo sự kiện 
`skipped_nonspawnable
` để người điều hành hội đồng có thể khắc phục chúng; chúng không bị loại bỏ một cách âm thầm hoặc được thực thi bởi một phương án dự phòng tùy ý.

### 2. Cơ chế sinh sản

Đối với các làn hồ sơ Hermes, 
`_default_spawn
` của người điều phối chạy 
`Hermes -p &lt;assignee chat -q &lt;prompt
` (hoặc dạng mô-đun tương đương khi miếng chêm 
`Hermes
` không có trên 

$PATH

) bên trong không gian làm việc được ghim của nhiệm vụ, với các biến env này được đặt:

| Biến | Mang theo |
|---|---|
| 
`Hermes_KANBAN_TASK
` | id nhiệm vụ mà nhân viên đang thực hiện |
| 
`Hermes_KANBAN_DB
` | đường dẫn tuyệt đối đến tệp SQLite trên mỗi bảng |
| 
`Hermes_KANBAN_BOARD
` | sên ván |
| 
`Hermes_KANBAN_WORKSPACES_ROOT
` | gốc cây không gian làm việc của bảng |
| 
`Hermes_KANBAN_WORKSPACE
` | đường dẫn tuyệt đối tới không gian làm việc của tác vụ *này* |
| 
`Hermes_KANBAN_RUN_ID
` | id của lần chạy hiện tại (đối với cổng vòng đời) |
| 
`Hermes_KANBAN_CLAIM_LOCK
` | chuỗi khóa yêu cầu (

&lt;host>:&lt;pid>:&lt;uuid>

) |
| 
`Hermes_PROFILE
` | tên hồ sơ riêng của công nhân (để ghi công tác giả 
`kanban_comment

) |
| 
`Hermes_TENANT
` | không gian tên đối tượng thuê, nếu tác vụ có |

Đối với các làn đường không phải của Hermes (được đăng ký qua plugin), plugin cung cấp 
`spawn_fn
` có thể gọi riêng để nhận 
`task

, 
`workspace
` và 
`board
` và trả về một pid tùy chọn để phát hiện sự cố.

### 3. Trình kết thúc vòng đời

Mọi khiếu nại phải kết thúc bằng chính xác một trong:
- 
`kanban_complete(summary=..., metadata=...)

 - nhiệm vụ thành công, trạng thái chuyển sang 
`done

.

- 
`kanban_block(reason=...)

 - nhiệm vụ chờ đầu vào của con người, trạng thái chuyển sang 
`blocked

. Người điều phối sẽ hồi sinh khi 
`kanban_unblock
` chạy.
- Quá trình công nhân thoát ra mà không có lệnh gọi công cụ. Hạt nhân thu thập nó và phát ra 
`crashed
` (PID đã chết) hoặc 
`gave_up
` (bộ ngắt lỗi liên tiếp bị ngắt) hoặc 
`timed_out
` (vượt quá max_runtime). Đây là con đường thất bại; những người lao động khỏe mạnh không kết thúc ở đây.

Hạt nhân kanban thực thi rằng chính xác một trong số này sẽ kết thúc mỗi lần chạy. Một công nhân không gọi và thoát ra bình thường được coi là bị hỏng.

## Đầu ra và quy ước cần xem xét

Đối với hầu hết các nhiệm vụ thay đổi mã, công việc không thực sự *hoàn thành* ngay khi nhân viên hoàn thành — công việc cần có người đánh giá. Nhân kanban không thực thi sự phân biệt này ("tác vụ thay đổi mã" không rõ ràng và việc buộc chặn thay vì hoàn thành đối với mọi nhân viên mã sẽ phá vỡ các luồng mà không cần xem xét). Đó là một quy ước được xếp lên trên:- **Chặn thay vì hoàn thành**, với 
`reason
` có tiền tố 
`review-required: 
` nên trang tổng quan / 
`Hermes kanban show
` hiển thị hàng đang chờ xem xét.
- **Thả siêu dữ liệu có cấu trúc vào 
`kanban_comment
` trước tiên** vì 
`kanban_block
` chỉ mang 
`reason
` mà con người có thể đọc được. Nhận xét là kênh chú thích lâu dài — mọi trường liên quan đến kiểm tra (changed_files, test_run, diff_path hoặc PR url, quyết định) đều thuộc về đó.
- **Người đánh giá phê duyệt và bỏ chặn**, việc này sẽ trả lại nhân viên bằng chuỗi nhận xét để theo dõi; hoặc yêu cầu thay đổi thông qua một nhận xét khác mà lần chạy tiếp theo của nhân viên sẽ coi là một phần trong bối cảnh của 
`kanban_show

.

Kỹ năng [XPROTECTX45XPROTECTX](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/devops/kanban-worker/SKILL.md) đã sử dụng các ví dụ cho cả 
`kanban_complete
` (các tác vụ thực sự đầu cuối - sửa lỗi chính tả, thay đổi tài liệu, ghi lại nghiên cứu) và mẫu khối 
`review-required

.

## Nhật ký và dấu vết kiểm tra

Người điều phối ghi stdout/stderr của nhân viên theo từng nhiệm vụ vào 

&lt;board-root>/logs/&lt;task_id>.log

. Nhật ký có thể được kiểm tra từ siêu dữ liệu Kanban:
- Các hàng 
`task_runs
` mang 
`log_path

, mã thoát (nếu có), tóm tắt và siêu dữ liệu.
- Các hàng 
`task_events
` thực hiện mọi chuyển đổi trạng thái (
`promoted

, 
`claimed

, 
`heartbeat

, 
`completed

, 
`blocked

, 
`gave_up

, 
`crashed

, 
`timed_out

, 
`reclaimed

, 
`claim_extended

).
- 
`kanban_show
` trả về cả hai, do đó người đánh giá (hoặc nhân viên tiếp theo) đọc tác vụ sẽ có được toàn bộ lịch sử mà không cần truy cập vào trang tổng quan.

Trang tổng quan hiển thị lịch sử chạy với các bản tóm tắt, khối siêu dữ liệu và huy hiệu trạng thái thoát. Người dùng CLI có thể chạy 
`Hermes kanban tail &lt;task_id>
` để theo dõi trực tiếp hoặc 
`Hermes kanban runs &lt;task_id>
` để biết danh sách lần thử lịch sử.

## Hình dạng làn đường hiện tại

### Làn đường hồ sơ Hermes (mặc định)

Hình dạng mà mọi nhân viên kanban ngày nay có: người được giao là tên hồ sơ, người điều phối sinh ra 
`Hermes -p &lt;profile

, nhân viên tự động tải kỹ năng [XPROTECTX66XPROTECTX](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/devops/kanban-worker/SKILL.md) cộng với khối nhắc hệ thống 
`KANBAN_GUIDANCE
` và sử dụng các công cụ 
`kanban_*
` để kết thúc quá trình chạy. Không có thiết lập nào ngoài việc xác định hồ sơ.

Khi bạn tạo hồ sơ cho nhóm của mình, hãy chọn tên khớp với *vai trò* mà bạn muốn người điều phối định tuyến tới. Người điều phối (khi có) phát hiện tên hồ sơ của bạn thông qua 
`Hermes profile list
` — hệ thống giả định không có danh sách cố định nào (xem kỹ năng [XPROTECTX70XPROTECTX](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/devops/kanban-orchestrator/SKILL.md) cho phía người điều phối của hợp đồng).

### Làn hồ sơ người soạn nhạc

Chuyên môn hóa của làn hồ sơ: người điều phối là hồ sơ Hermes có bộ công cụ bao gồm 
`kanban
` nhưng không bao gồm 
`terminal
` / 
`file
` / 
`code
` / 
`web
` để triển khai. Công việc của nó là phân tách mục tiêu cấp cao thành các nhiệm vụ con thông qua 
`kanban_create

 + 
`kanban_link
` và lùi lại. Kỹ năng dàn nhạc mã hóa các quy tắc chống cám dỗ.

## Thêm làn đường dành cho nhân viên CLI bên ngoài

Việc kết nối một công cụ CLI không phải của Hermes (Codex CLI, Claude Code CLI, OpenCode CLI, trình chạy mô hình mã hóa cục bộ, v.v.) làm làn đường công nhân kanban *chưa phải là con đường được trải nhựa*. Chức năng sinh ra của bộ điều phối có thể cắm được (
`spawn_fn
` là một tham số trên 
`dispatch_once

) và một plugin có thể đăng ký 
`spawn_fn
` của riêng nó cho người được chuyển nhượng không phải là Hermes, nhưng công việc tích hợp xung quanh — gói mã thoát của CLI vào các lệnh gọi 
`kanban_complete
` / 
`kanban_block

, ánh xạ các quy ước không gian làm việc/hộp cát của CLI vào env 
`Hermes_KANBAN_WORKSPACE
` của người điều phối, xử lý chính sách xác thực và mỗi CLI - vẫn là công việc thiết kế trên mỗi tích hợp.

Nếu bạn đang cân nhắc việc thêm làn CLI, hãy mở một vấn đề mô tả CLI cụ thể và quy trình làm việc mà bạn đang cố gắng kích hoạt. Hợp đồng ở trên là những ràng buộc mà bất kỳ làn đường nào như vậy phải đáp ứng; hình thức triển khai (một plugin cho mỗi CLI so với một plugin CLI-runner chung được tham số hóa theo cấu hình) đang mở.

Vấn đề lịch sử của vấn đề này là [#19931](https://GitHub.com/NousResearch/Hermes-agent/issues/19931) và PR [#19924](https://GitHub.com/NousResearch/Hermes-agent/pull/19924) dành riêng cho Codex đóng, không hợp nhất - những mô tả này mô tả đề xuất kiến ​​trúc ban đầu nhưng không giành được người chạy.

## Các chế độ lỗi mà người điều phối xử lý

Vì vậy, tác giả làn đường không phải thực hiện lại những điều này:- **Xác nhận quyền sở hữu TTL cũ** — một công nhân xác nhận quyền sở hữu và sau đó không bao giờ đập / hoàn thành / khối được lấy lại sau 
`DEFAULT_CLAIM_TTL_SECONDS
` (mặc định 15 phút) — nhưng chỉ khi quy trình công nhân thực sự đã chết. Một nhân viên trực tiếp (mô hình chậm dành hơn 20 phút cho một cuộc gọi LLM không có công cụ) nhận được yêu cầu *mở rộng* thay vì bị giết; chỉ có một PID chết được lấy lại.
- **Công nhân gặp sự cố** — một công nhân có PID cục bộ trên máy chủ đã biến mất được 
`detect_crashed_workers
` phát hiện và thu thập; nhiệm vụ tăng lên 
`consecutive_failures
` và có thể tự động chặn khi cầu dao ngắt.
- **Thử lại ở cấp độ chạy** — khi một tác vụ được thử lại (sau khối, sau sự cố, sau lấy lại), nhân viên có thể sử dụng tham số 
`expected_run_id
` trên các công cụ chấm dứt để nhanh chóng thất bại nếu lần chạy của chính tác vụ đó đã được thay thế.
- **Thời gian chạy tối đa trên mỗi tác vụ** — 
`task.max_runtime_seconds
` thời gian đồng hồ treo tường giới hạn cứng trên mỗi lần chạy, bất kể hoạt động của PID. Bắt các công nhân thực sự bị bế tắc mà tiện ích mở rộng PID trực tiếp sẽ tiếp tục chạy.
- **Phát hiện nhiệm vụ bị mắc kẹt** — một nhiệm vụ đã sẵn sàng mà người được giao không bao giờ đưa ra xác nhận quyền sở hữu trong 
`kanban.stranded_threshold_seconds
` (mặc định là 30 phút) hiển thị trong 
`Hermes kanban diagnostics
` dưới dạng cảnh báo 
`stranded_in_ready

. Mức độ nghiêm trọng tăng lên đến mức lỗi gấp 2 lần ngưỡng và nghiêm trọng ở mức 6 lần. Phát hiện những người được giao lỗi đánh máy, hồ sơ đã xóa và truy cập nhóm nhân viên bên ngoài bằng một tín hiệu — không phân biệt danh tính, không có danh sách cho phép trên mỗi bảng để quản lý.

## Liên quan
- [Kanban overview](./kanban) — phần giới thiệu hướng tới người dùng.
- [Kanban tutorial](./kanban-tutorial) — hướng dẫn khi mở bảng điều khiển.
- [XPROTECTX92XPROTECTX](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/devops/kanban-worker/SKILL.md) — kỹ năng mà quy trình công nhân tải lên.
- [XPROTECTX93XPROTECTX](https://GitHub.com/NousResearch/Hermes-agent/blob/main/skills/devops/kanban-orchestrator/SKILL.md) — phía người điều phối.
Hệ thống phân cấp​

Hệ thống phân cấp
