docs: require immediate task branches and PRs

fix: enforce canonical Scope status vocabulary

SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: corp-v1-channel-delivery
 description: "Use when operating or synchronizing a Corp v1 project's delivery channel. Drives coding, unit testing, build and continuous-integration health, attempts safe evidence-based fixes, escalates requirement or architecture contradictions, and maintains Ways of Working and Engineering documentation."
-version: 1.7.0
+version: 1.10.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -14,7 +14,31 @@ metadata:
 
 ## Overview
 
-This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, and `releases` channels and implements only tasks whose parent Feature has explicit human `Approved for Implementation` evidence and which a human team member separately admitted to Kanban Focus `InBacklog`.
+## Canonical Scope Status Vocabulary
+
+Before reporting or changing any lifecycle status, read the project's current Ways of Working Scope page. Use only the canonical values defined there.
+
+Ideas, Epics, and Features:
+
+```text
+IN_BACKLOG → IN_DESIGN → READY_FOR_DELIVERY → IN_DELIVERY → TO_BE_RELEASED → DONE
+```
+
+Tasks:
+
+```text
+IN_BACKLOG → READY_FOR_DELIVERY → IN_PROGRESS → TO_BE_RELEASED → DONE
+```
+
+`READY_FOR_DELIVERY` is the exact Task's Focus-admitted, pickup-ready state. It means Architecture, dependencies, implementation boundaries, verification steps, and Kanban selection are complete; implementation has not started. Delivery claims that Task by moving it directly to `IN_PROGRESS`. Never require or invent a second Focus-admission decision after `READY_FOR_DELIVERY`.
+
+`CANCELLED` is an exceptional terminal status. `BLOCKED` is a separate flag with a reason and evidence; it never replaces the lifecycle status.
+
+Never invent, abbreviate, or substitute lifecycle values such as `Ready`, `Active`, `Delivered`, `Complete`, `Awaiting CI`, or `Overrun`. Those phrases may describe activity only when clearly separated from the canonical status field. If the canonical status cannot be verified, report `status unverified` and inspect the source record rather than guessing.
+
+A merge or successful CI does not automatically mean `DONE`. Releasable application Tasks normally move from `IN_PROGRESS` to `TO_BE_RELEASED`; `DONE` requires the applicable release or completion evidence. Status reports must show the exact canonical value even when a separate plain-language action is also included.
+
+This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, and `releases` channels and implements only tasks whose parent Feature has explicit human `Approved for Implementation` evidence and whose exact Task status is `READY_FOR_DELIVERY`. That status is the Focus-admitted pickup handoff; no separate post-status admission gate exists.
 
 Its scope includes coding, unit testing, builds, continuous integration, review readiness, delivery blockers, and maintenance of the project documentation's `Ways of Working` and `Engineering` areas.
 
@@ -57,13 +81,24 @@ Before starting or continuing Feature implementation, verify in project document
 - task breakdown and dependencies;
 - target version and status;
 - acceptance evidence expected from delivery.
-- explicit human Kanban approval admitting the exact task to Focus `InBacklog`.
+- exact Task `READY_FOR_DELIVERY` evidence, which itself records human Kanban Focus admission.
 
-Hermes cannot approve a Feature for implementation or admit a task to Focus `InBacklog`. If the gate is incomplete, improve safe delivery-readiness documentation or raise the exact missing decision in `architecture`; do not start code.
+Hermes cannot approve a Feature for implementation or move a Task to `READY_FOR_DELIVERY`. Once that exact state exists, Hermes must not require a second Focus-admission decision; Delivery claims the Task by moving it to `IN_PROGRESS`.
+
+## Immediate Wave-Start Visibility Gate
+
+Before implementation begins on a newly claimed delivery wave, establish these Gitea checkpoints for **every Task** in that wave:
+
+1. Create a dedicated branch whose name includes the exact Task ID and concise purpose, and push it immediately.
+2. Open a pull request from that branch to the governed integration branch immediately after the branch exists. Do not wait for implementation, tests, review, or a finished diff.
+3. Put the Task ID, wave, planned scope, and current delivery state in the PR so the human owner and team can monitor progress from the beginning.
+4. Read back and record the branch ref, PR URL/number, exact head SHA, and base branch before substantive coding starts. Keep the same PR updated as commits are pushed.
+
+One Task requires one dedicated branch and one visible PR unless Architecture or the human owner explicitly approves a different grouping. Do not hide several independently deliverable Tasks behind a shared wave branch. If Gitea refuses a no-diff PR, create and push an empty kickoff commit—never a filler file change—then open the PR. A locally created worktree or unpushed branch does not satisfy this gate.
 
 ## Proactive Iteration Requirement
 
-Every delivery iteration must complete at least one useful, safe activity for an implementation-approved Feature or delivery-health need: implement an unblocked task, add tests, diagnose/fix CI, improve build tooling, update real Ways of Working/Engineering guidance, verify dependency readiness, or document a concrete blocker with evidence. Never create filler changes. Select work only from Kanban Focus `InBacklog`, backed by architecture's approved task/dependency plan, and update progress in project documentation.
+Every delivery iteration must complete at least one useful, safe activity for an implementation-approved Feature or delivery-health need: implement an unblocked task, add tests, diagnose/fix CI, improve build tooling, update real Ways of Working/Engineering guidance, verify dependency readiness, or document a concrete blocker with evidence. Never create filler changes. Select work only from exact Tasks in `READY_FOR_DELIVERY`; claiming one moves it to `IN_PROGRESS`. Keep architecture's approved task/dependency plan and project documentation current.
 
 ## Approved Information Boundary
 
@@ -190,7 +225,7 @@ For frontend-affecting work, Delivery requires the approved UI/UX design package
 ## Synchronization Workflow
 
 1. Read new same-project activity and enough delivery history to avoid duplicates.
-2. Verify human `Approved for Implementation` evidence, explicit human Kanban Focus `InBacklog` admission, task dependencies, and target version before task work.
+2. Verify human `Approved for Implementation` evidence, exact Task `READY_FOR_DELIVERY` state, task dependencies, and target version before task work.
 3. Identify executable tasks, CI failures, blockers, requirements/ADR implications, and documentation drift.
 4. Load all applicable project engineering skills.
 5. Complete at least one useful safe activity when an authorized path exists; otherwise document and route the exact blocker.
@@ -240,7 +275,7 @@ Include repository, branch, commit SHA, changed paths, commands, local results,
 - [ ] Only same-project channels and repositories were used.
 - [ ] Work maps to approved requirements/architecture.
 - [ ] Feature has explicit human `Approved for Implementation` evidence and a documented target version.
-- [ ] Selected tasks respect documented dependencies and have explicit human Focus `InBacklog` admission.
+- [ ] Selected tasks respect documented dependencies and carry exact Task `READY_FOR_DELIVERY` evidence.
 - [ ] At least one useful delivery activity was completed, or a concrete blocker was documented and routed.
 - [ ] Applicable project skills were loaded.
 - [ ] Tests and builds were actually run.