feat: add ready-for-delivery kanban gate

SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: corp-v1-channel-kanban
-description: "Use when operating or synchronizing a Corp v1 project's Kanban channel. Maintains Board and Focus across Epic, Feature, and task state; correlates all seven same-project channels; and records human approval before tasks enter Delivery's executable InBacklog queue."
+description: "Use when operating or synchronizing a Corp v1 project's Kanban channel. Maintains Board and Focus across Epic, Feature, and task state; correlates all seven same-project channels; and records exact admission before tasks enter the READY_FOR_DELIVERY pickup queue."
-version: 1.5.0
+version: 1.6.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -16,7 +16,7 @@ metadata:
 
 This skill owns flow visibility and task-readiness coordination for a Corp v1 project's `kanban` channel. It monitors the seven same-project channels—`general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, and `releases`—and maintains the project documentation's top-level **Kanban** area.
 
-Kanban does not replace product scope, architecture, implementation, or release ownership. Scope owns Roadmap, Ideas, Epics, and Features; Architecture owns requirements, design, task decomposition, dependencies, implementation approval, and version allocation; Kanban exposes flow and obtains human approval for ready tasks to enter Focus `InBacklog`; Delivery executes those approved tasks; Releases owns release readiness and controlled release preparation.
+Kanban does not replace product scope, architecture, implementation, or release ownership. Scope owns Roadmap, Ideas, Epics, and Features; Architecture owns requirements, design, task decomposition, dependencies, implementation approval, and version allocation; Kanban exposes flow and records the exact admission that moves an eligible task to Focus `READY_FOR_DELIVERY`; Delivery claims that task and records `IN_PROGRESS`; Releases owns release readiness and controlled release preparation.
 
 Load the global `documentation-docusaurus` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus` before changing documentation structure, navigation, Markdown/MDX, Docusaurus configuration, or builds.
 
@@ -43,7 +43,7 @@ Use this skill when:
 - reconciling Epic, Feature, and task status across project channels;
 - identifying work that is blocked, stale, ready for prioritization, in progress, or awaiting release;
 - preparing a task-readiness proposal for a human team member;
-- recording a human decision that moves a task into Focus `InBacklog`.
+- recording a human decision that moves an exact task into Focus `READY_FOR_DELIVERY`.
 
 Do not use it to approve tasks autonomously, redesign architecture, implement code, merge, release, deploy, or alter another project's board.
 
@@ -87,9 +87,9 @@ Read enough mapped-channel history to avoid duplicates and only relevant new act
 
 ## Human Approval Gate
 
-A task may enter Focus `InBacklog` only after a human team member explicitly approves that exact task as ready for Focus. Hermes may assess readiness, identify dependencies, prepare a recommendation, and record the human decision; Hermes may not approve its own recommendation or infer approval from silence.
+A task may enter Focus `READY_FOR_DELIVERY` only after a human team member explicitly approves that exact task as ready for Delivery pickup. Hermes may assess readiness, identify dependencies, prepare a recommendation, and record the human decision; Hermes may not approve its own recommendation or infer approval from silence.
 
-Before proposing a task for Focus `InBacklog`, verify:
+Before proposing a task for Focus `READY_FOR_DELIVERY`, verify:
 
 - stable task ID and parent Feature/Epic;
 - the Feature has explicit human `Approved for Implementation` evidence;
@@ -99,7 +99,7 @@ Before proposing a task for Focus `InBacklog`, verify:
 - target version and sequencing constraints are documented;
 - no unresolved blocker makes the task non-executable.
 
-Record approver identity, decision evidence, date, resulting status, and any conditions. Delivery may start implementation only when both the Feature implementation gate and task Focus `InBacklog` gate are satisfied.
+Record approver identity, decision evidence, date, resulting `READY_FOR_DELIVERY` status, and any conditions. This status means the task is eligible to be claimed; it does not mean implementation has started. Delivery changes it to `IN_PROGRESS` only after a verified claim/start event. `IN_DELIVERY` remains a derived parent aggregate and is never a task pickup state.
 
 ## Kanban Documentation Contract
 
@@ -112,19 +112,21 @@ Focus
 
 ### Board
 
-Board provides a visual board of all unfinished Epics and Features grouped into exactly these flow columns:
+Board provides a visual board of all unfinished Epics and Features grouped into these flow columns. `ReadyForDelivery` is the presentation mapping of canonical delivery status `READY_FOR_DELIVERY`; do not create aliases such as `READY` or `QUEUED`:
 
 1. `InIdeation`
 2. `InBacklog`
-3. `InProgress`
+3. `ReadyForDelivery`
-4. `ToBeReleased`
+4. `InProgress`
+5. `ToBeReleased`
 
 Each card must link to its authoritative Scope record and show at least ID, title, type, status, owner when known, target version when known, and blocking dependency when material. Completed, Done, Released, Rejected, Cancelled, or otherwise terminal Epics and Features must not appear on Board. Preserve their history in authoritative registries; hiding terminal work from Board is not deletion.
 
 Board statuses mean:
 
 - `InIdeation` — proposed or being refined; not approved for executable backlog.
-- `InBacklog` — approved and eligible for prioritized work, subject to lower-level gates and dependencies.
+- `InBacklog` — retained and available for planning or design; not eligible for Delivery pickup.
+- `ReadyForDelivery` — all entry gates are evidenced and the exact task is admitted for Delivery pickup; implementation has not started.
 - `InProgress` — active solution or implementation work exists.
 - `ToBeReleased` — implementation is complete enough for release readiness; release approval and execution remain separate.
 
@@ -135,6 +137,7 @@ If source lifecycle states are more detailed, maintain an explicit deterministic
 Focus shows only current work at Epic, Feature, and task level whose flow state is:
 
 - `InBacklog`
+- `ReadyForDelivery`
 - `InProgress`
 - `ToBeReleased`
 
@@ -148,7 +151,7 @@ Epic
 
 Every item links to its authoritative record and shows ID, title, owner, dependency/blocker, target version, current evidence date, and status. A Feature or Epic may appear because descendant work is focused even when its own aggregate state is derived; label derived states clearly.
 
-Tasks appear in Focus `InBacklog` only with explicit human approval evidence from the Kanban channel or authoritative documentation. A task moves to `InProgress` from verified Delivery evidence and to `ToBeReleased` only when implementation evidence and release handoff criteria are satisfied. Kanban reflects evidence; it does not fabricate progress.
+Tasks may appear in Focus `InBacklog` while they are planned but not executable. A task appears in Focus `ReadyForDelivery` only with explicit exact-task admission evidence from the Kanban channel or authoritative documentation and all readiness checks satisfied. A task moves to `InProgress` from verified Delivery claim/start evidence and to `ToBeReleased` only when implementation evidence and release handoff criteria are satisfied. Kanban reflects evidence; it does not fabricate readiness or progress.
 
 ## React Flow visualization contract
 
@@ -161,7 +164,7 @@ When Kanban documentation contains relationship-dense execution data, deliberate
 - execution-to-governance contradictions, with links to both authoritative sources;
 - version and release dependency views supported by canonical allocation and release evidence.
 
-The four-column Board remains the primary governed representation and normally stays semantic HTML. A small, empty, or simple Focus dataset should remain a table or hierarchy. Render a graph only when validated canonical YAML contains the required identities, relationships, states, and evidence and the visualization materially improves comprehension. Do not infer approval, Focus admission, hierarchy, dependencies, sequencing, progress, version allocation, release readiness, or critical path.
+The governed Board remains the primary representation and normally stays semantic HTML. A small, empty, or simple Focus dataset should remain a table or hierarchy. Render a graph only when validated canonical YAML contains the required identities, relationships, states, and evidence and the visualization materially improves comprehension. Do not infer approval, Focus admission, `READY_FOR_DELIVERY`, hierarchy, dependencies, sequencing, progress, version allocation, release readiness, or critical path.
 
 Use one typed, deterministic adapter and the same selector to produce stable nodes, edges, legends, validation warnings, and an adjacent semantic table fallback. Generated graph data, coordinates, viewport state, and client state are derived presentation data, never a second source of truth. Preserve authority and relationship semantics: Scope identities, Architecture dependencies and implementation gates, Kanban Focus decisions, Delivery execution, and Releases evidence must remain distinguishable.
 
@@ -177,7 +180,7 @@ Use authoritative ownership:
 
 - Epic/Feature identity and product status → Scope;
 - requirements, architecture, task definitions/dependencies, implementation approval, version allocation → Architecture;
-- Focus admission decision → Kanban human decision;
+- exact `READY_FOR_DELIVERY` Focus admission decision → Kanban human decision;
 - task execution progress and completion evidence → Delivery;
 - release readiness, released state, and post-release outcome → Releases.
 
@@ -201,7 +204,7 @@ For frontend-affecting tasks, Kanban includes the approved UI/UX design-package
 4. Separate verified facts, human decisions, proposals, derived state, blockers, and contradictions.
 5. Reconcile Board and Focus while preserving ownership and links.
 6. Remove terminal Epic/Feature cards from Board and terminal items from Focus without deleting history.
-7. Prepare task-readiness proposals; move a task to Focus `InBacklog` only from explicit human approval evidence.
+7. Prepare task-readiness proposals; move a task to Focus `READY_FOR_DELIVERY` only from explicit exact-task human approval evidence after every entry gate passes.
 8. Validate menu order, dedicated sidebar, allowed states, exclusion rules, hierarchy, links, and documentation build.
 9. Push through the approved workflow and verify remote artifact and exact-SHA CI when configured.
 10. Post one concise update with changed artifacts, task-admission decisions or gates, and exact evidence.
@@ -222,7 +225,7 @@ May autonomously:
 
 Requires human approval for:
 
-- moving any task into Focus `InBacklog`;
+- moving any task into Focus `READY_FOR_DELIVERY`;
 - changing Epic/Feature approval or scope;
 - approving implementation or final version allocation;
 - overriding dependencies or blockers;
@@ -238,12 +241,12 @@ Include exact project documentation paths, item IDs, source links, human decisio
 ## Common Pitfalls
 
 1. Treating Kanban as a second source of truth for Scope or Architecture.
-2. Moving tasks to `InBacklog` without explicit human approval.
+2. Moving tasks to `READY_FOR_DELIVERY` without explicit exact-task human approval and complete readiness evidence.
 3. Showing completed or released Epics/Features on Board.
 4. Showing `InIdeation` or terminal work in Focus.
 5. Flattening Focus so task ancestry and dependencies are lost.
 6. Treating `ToBeReleased` as release authorization.
-7. Starting Delivery from Feature approval alone without task Focus admission.
+7. Starting Delivery from Feature approval, `IN_BACKLOG`, design completion, or parent `IN_DELIVERY` alone without exact-task `READY_FOR_DELIVERY` Focus admission.
 8. Hiding contradictions instead of routing them to the owning channel.
 9. Inspecting another project's channels.
 10. Posting passive status when safe Board/Focus maintenance is possible.
@@ -255,11 +258,11 @@ Include exact project documentation paths, item IDs, source links, human decisio
 - [ ] The session changed no project implementation repository; project-repository writes were limited to the dedicated Kanban documentation area and its minimum required wiring.
 - [ ] Any implementation request was represented in planning/Board/Focus and handed to Delivery rather than executed or delegated from Kanban.
 - [ ] Kanban appears immediately after Architecture and has its own Board/Focus sidebar.
-- [ ] Board uses only `InIdeation`, `InBacklog`, `InProgress`, and `ToBeReleased`.
+- [ ] Board uses only `InIdeation`, `InBacklog`, `ReadyForDelivery`, `InProgress`, and `ToBeReleased`.
 - [ ] Board contains only unfinished Epics and Features.
-- [ ] Focus contains only `InBacklog`, `InProgress`, and `ToBeReleased` Epic/Feature/task hierarchy.
+- [ ] Focus contains only `InBacklog`, `ReadyForDelivery`, `InProgress`, and `ToBeReleased` Epic/Feature/task hierarchy.
 - [ ] Every card/item links to an authoritative record and displays current status.
-- [ ] Every Focus `InBacklog` task has explicit human approval evidence.
+- [ ] Every Focus `READY_FOR_DELIVERY` task has explicit exact-task human approval and complete readiness evidence.
 - [ ] Feature implementation approval, task dependencies, and version constraints were verified.
 - [ ] Derived states are labeled and contradictions are escalated.
 - [ ] Documentation/navigation/link/build and remote readback checks passed.