docs: require immediate task branches and PRs

fix: enforce canonical Scope status vocabulary

SKILL.md

@@ -1,26 +1,61 @@
 ---
 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.5.1
+version: 1.10.0
 author: Hermes Agent
 license: MIT
 metadata:
   hermes:
     tags: [corp-v1, discord, channel, delivery, coding, testing, ci]
-    related_skills: [corp-v1--main, home-v1-discord, documentation-docusaurus, corp-v1--glossary]
+    related_skills: [corp-v1-main, home-v1-discord, documentation-docusaurus, corp-v1-glossary]
 ---
 
 # Corp v1 Delivery Channel
 
 ## 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.
 
 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.
 
-Load the global `corp-v1--glossary` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1--glossary` whenever project documentation needs to define or explain a reusable term. Maintain one canonical definition in the project's final top-level **Glossary** area and link to it from the owning domain page; do not duplicate glossary-style explanations across channel documentation.
+Load the global `corp-v1-glossary` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1-glossary` whenever project documentation needs to define or explain a reusable term. Maintain one canonical definition in the project's final top-level **Glossary** area and link to it from the owning domain page; do not duplicate glossary-style explanations across channel documentation.
+
+## Shared Corp v1 System Login
+
+When an authorized task requires login to a Corp v1 system being built or operated, follow the shared policy in `corp-v1-main` and use only the Bitwarden-injected runtime secrets named:
+
+```text
+HL_V1_SSO_EMAIL
+HL_V1_SSO_PASSWORD
+```
+
+Secret availability is capability, not authorization. Verify the destination origin and task purpose before login. Never print, inspect, log, hash, serialize, paste, screenshot, or persist either value; never place a value in a command line, URL, file, repository, prompt, Discord message, browser console, test fixture, CI output, or generated artifact. Never ask a human to paste a value into chat. If a variable is unavailable, report only its missing name and request Bitwarden/gateway injection. Login does not authorize account recovery, MFA or credential changes, permission changes, billing, spending, destructive operations, or access outside the approved project task.
 
 ## When to Use
 
@@ -46,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
 
@@ -103,6 +149,29 @@ Monitor local builds and Gitea Actions for:
 
 A green local build is not proof that CI or delivery succeeded. Verify the actual remote branch and matching CI task/run.
 
+### Per-project reusable CI base images
+
+Each Corp v1 project should own `corp-v1-<code>/corp-v1-<code>-base-images` when stable runtimes or operating-system tools would otherwise be downloaded repeatedly in application CI.
+
+- Keep one folder per image, with its Dockerfile, machine-readable version/platform metadata, usage documentation, build helper, and smoke contract.
+- Pin the upstream base by digest and assert exact runtime/tool versions, architecture, numeric non-root identity, writable workspace, CA trust, Git, shell, and other required tools.
+- Build and smoke-test without registry credentials on pull requests. Publish only from the trusted integration branch using a narrowly scoped Harbor robot secret.
+- Publish immutable full-source-SHA tags, read back the Harbor artifact digest, and consume the image from project workflows by digest—not `latest`, a mutable version tag, or an unverified local name.
+- Extend fail-closed tests to reject broad publication triggers, mutable tags, secret access from candidate/PR paths, shell interpolation, wrong digests, and reintroduced runtime setup actions.
+- Prefer the verified job image over repeated runtime or package-manager setup actions. Keep lockfile-frozen application dependency installation in the application repository; do not bake project dependencies into a generic base image.
+- Treat the first real Gitea build, runtime smoke test, Harbor publication, digest readback, and a consumer workflow at the exact candidate SHA as separate acceptance layers.
+- Repair image or publication failures forward only. Preserve the last known-good digest for consumers until the replacement image and consuming workflow pass exact-head CI.
+
+### Runtime-resource placement
+
+CI jobs and developer workstations must not provision databases, queues, object stores, caches, brokers, or other application runtime services. When implementation or validation needs such a resource, provision it under the owning application on the approved shared runtime platform through that project's GitOps repository, then consume it through a governed application or test interface.
+
+- Keep every non-production environment—including development, integration, test, staging, and preview—and all of its resources isolated from production and from other non-production environments. Destructive or concurrent validation requires a per-run database/schema/role or explicit serialization; it must not reset shared data.
+- CI may orchestrate exact-head validation, but it must not start application runtime-resource service containers or receive application-resource credentials. Harmless process-local test doubles and build tools are not runtime resources. Prefer a narrowly governed in-platform Job/Workflow trigger so a private resource does not need public, NodePort, or runner-network exposure.
+- Persistent storage must follow the project's named platform storage operations skill; load that skill before designing or mutating storage. If the project instead names an approved storage procedure, read that exact procedure and verify its current provenance before acting. If neither an approved skill nor an approved procedure is identified, stop and route the missing decision to Architecture/platform operations; do not infer a provider or provisioning method. Never accept a dynamically provisioned volume whose reclaim policy can delete durable data when the PVC is removed.
+- Secrets come from the approved external secret store; never commit connection strings or credentials.
+- Provision and verify required runtime resources before treating dependent application work as deployable. Missing infrastructure blocks deployment, not safe code-only work whose tests do not require that resource.
+
 ## Failure-Repair Workflow
 
 When a build or CI failure is observed:
@@ -156,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.
@@ -206,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.