feat: enforce proactive feature lifecycle

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.0.0
+version: 1.1.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -14,7 +14,7 @@ metadata:
 
 ## Overview
 
-This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels and turns approved requirements and architecture into implemented, tested, integrated, documented work.
+This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels and implements only Features that architecture documentation marks `Approved for Implementation` through an explicit human team-member decision.
 
 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.
 
@@ -32,6 +32,23 @@ Use this skill when:
 
 Do not use it to silently choose between contradictory requirements or architecture decisions, approve releases, or bypass review and branch protections.
 
+## Implementation Entry Gate
+
+Before starting or continuing Feature implementation, verify in project documentation:
+
+- Feature ID and parent Epic;
+- explicit human `Approved for Implementation` evidence;
+- linked FRs/NFRs and accepted solution/ADR context;
+- task breakdown and dependencies;
+- target version and status;
+- acceptance evidence expected from delivery.
+
+Hermes cannot approve a Feature for implementation. If the gate is incomplete, improve safe delivery-readiness documentation or raise the exact missing decision in `architecture`; do not start code.
+
+## 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 from architecture's approved task/dependency plan and update progress in project documentation.
+
 ## Approved Information Boundary
 
 Inspect only the project's four channels:
@@ -49,7 +66,7 @@ Use enough delivery history to avoid duplicate work and only relevant new activi
 
 ### Coding
 
-- implement only approved/authorized scope;
+- implement only human-approved Features and their authorized tasks;
 - load applicable project engineering skills before changing code;
 - preserve project structure, conventions, and environment namespace;
 - keep changes small, reviewable, and traceable to requirements/issues;
@@ -127,13 +144,14 @@ Update these pages from verified project practice. Do not document a planned pro
 ## Synchronization Workflow
 
 1. Read new same-project activity and enough delivery history to avoid duplicates.
-2. Identify executable work, CI failures, blockers, requirements/ADR implications, and documentation drift.
+2. Verify human `Approved for Implementation` evidence, task dependencies, and target version before Feature work.
-3. Load all applicable project engineering skills.
+3. Identify executable tasks, CI failures, blockers, requirements/ADR implications, and documentation drift.
-4. Perform safe authorized work when scope and expected outcome are clear.
+4. Load all applicable project engineering skills.
-5. Escalate uncertainty or contradiction rather than selecting direction.
+5. Complete at least one useful safe activity when an authorized path exists; otherwise document and route the exact blocker.
-6. Verify local and remote results.
+6. Escalate uncertainty or contradiction rather than selecting direction.
-7. Maintain Ways of Working and Engineering pages when durable practice changed.
+7. Verify local and remote results and update task/Feature progress in project documentation.
-8. Post a concise update with work completed, evidence, blockers, and required decisions; otherwise stay silent.
+8. Maintain Ways of Working and Engineering pages when durable practice changed.
+9. Post a concise update with work completed, evidence, blockers, and required decisions.
 
 ## Authority and Escalation
 
@@ -167,11 +185,17 @@ Include repository, branch, commit SHA, changed paths, commands, local results,
 6. Updating documentation with aspirational rather than actual practice.
 7. Repeatedly posting unchanged failure summaries.
 8. Inspecting another project.
+9. Starting implementation because requirements exist but human implementation approval is absent.
+10. Ignoring architecture task dependencies or target-version allocation.
+11. Posting passive status when safe implementation, testing, diagnosis, or documentation work is available.
 
 ## Verification Checklist
 
 - [ ] 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.
+- [ ] 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.
 - [ ] Remote branch and matching CI head SHA were verified.