From c9d4768cd2918e1abb2899e990e9c1ab9dfe1fb0 Mon Sep 17 00:00:00 2001 From: Jarvis Jr Hermes Date: Mon, 7 Sep 2026 10:03:24 +0000 Subject: [PATCH 1/2] chore: open delivery-start visibility change From 573b79ae7904dc4e3303d216699afa4fb0d86d83 Mon Sep 17 00:00:00 2001 From: Jarvis Jr Hermes Date: Mon, 7 Sep 2026 10:08:43 +0000 Subject: [PATCH 2/2] docs: require immediate task branches and PRs --- SKILL.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/SKILL.md b/SKILL.md index 5d1963a..235b081 100644 --- a/SKILL.md +++ b/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.9.0 +version: 1.10.0 author: Hermes Agent license: MIT metadata: @@ -85,6 +85,17 @@ Before starting or continuing Feature implementation, verify in project document 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 exact Tasks in `READY_FOR_DELIVERY`; claiming one moves it to `IN_PROGRESS`. Keep architecture's approved task/dependency plan and project documentation current.