feat: enforce proactive feature lifecycle

SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: corp-v1-channel-architecture
 description: "Use when operating or synchronizing a Corp v1 project's architecture channel. Maintains C4-based architecture documentation, Draw.io diagrams, architecture decisions, and functional/non-functional requirement registries while correlating verified activity across the project's four channels."
-version: 1.0.0
+version: 1.1.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -14,7 +14,7 @@ metadata:
 
 ## Overview
 
-This skill owns architecture coherence for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels, identifies architectural implications, and maintains the Architecture section of the project documentation.
+This skill owns the solution phase and architecture coherence for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels, transforms human-approved Features into requirements and solution artifacts, breaks them into dependency-aware implementation tasks, assigns approved Features to versions, and maintains the Architecture section of the project documentation.
 
 The default architecture model is C4. Architecture diagrams must be authored and validated using the global `drawio-main` skill from:
 
@@ -33,10 +33,20 @@ Use this skill when:
 - designing or reviewing project architecture;
 - maintaining C4 views and Draw.io sources;
 - recording architecture decisions;
-- maintaining functional and non-functional requirement registries;
+- transitioning human-approved Epics and Features into functional/non-functional requirements and solution design;
+- creating dependency-aware task breakdowns and proposing version allocation;
 - detecting implementation or release activity that changes architectural truth.
 
-Do not use it to approve architecture decisions without the team's authority, or to treat speculative discussion as an accepted design.
+Only Features explicitly marked `Approved for Solution` by a human team member may enter solution work. Do not use this skill to approve its own Feature, move an unapproved Feature into solution, authorize implementation, or treat speculative discussion as accepted design.
+
+## Human Approval Gates
+
+Hermes participates proactively in analysis and artifact creation but cannot satisfy either gate:
+
+1. **General → Solution:** a human team member explicitly approves an Epic/Feature for solution work.
+2. **Solution → Implementation:** after requirements, architecture, tasks, dependencies, and version allocation are reviewable, a human team member explicitly approves the Feature for implementation.
+
+Record approver identity, decision message or documentation reference, date, and resulting status. Silence, an agent statement, CI success, or an old informal discussion is not approval.
 
 ## Approved Information Boundary
 
@@ -63,6 +73,21 @@ Maintain the project documentation's `Architecture` area with at least:
 
 Documentation must reflect approved/current truth. Proposed designs and requirements must be visibly marked as proposed until approved.
 
+## Epic and Feature Transition
+
+For each human-approved Feature from the General documentation registry:
+
+1. verify its stable ID, parent Epic, scope, value, acceptance outcomes, status, and human approval evidence;
+2. set solution status to `In Solution` without changing product approval history;
+3. derive traceable FRs and NFRs;
+4. update C4 views and draft/maintain ADRs as needed;
+5. break the Feature into implementation tasks with dependencies and acceptance evidence;
+6. assess sequencing, risks, cross-feature dependencies, and release constraints;
+7. propose and document the target version;
+8. prepare a review package for the human implementation-approval decision.
+
+Do not perform solution work for merely `Proposed`, `Deferred`, or `Rejected` Features.
+
 ## C4 Model
 
 Use C4 consistently:
@@ -120,15 +145,34 @@ ID | quality attribute/constraint | measurable target | scope | status | verific
 
 Use stable IDs such as `FR-0001` and `NFR-0001`. Requirements must be unambiguous, testable, traceable, and preserved historically when superseded. Contradictions are raised for team resolution; they are not silently reconciled.
 
+## Task and Dependency Breakdown
+
+Maintain a task registry in project documentation:
+
+```text
+ID | feature | outcome | scope | dependencies | owner | status | acceptance evidence | affected repository/component
+```
+
+Use stable IDs such as `TASK-0001`. Model Feature→Task and Task→Task dependencies explicitly, identify critical sequencing and blocked work, and keep tasks small enough to implement and verify. Tasks may be drafted proactively, but only tasks belonging to a human-approved `Approved for Implementation` Feature may enter delivery execution.
+
+## Version Allocation
+
+Maintain a version allocation registry linking Features to intended versions. Record target version, rationale, dependencies, readiness constraints, status, and human decision evidence. Hermes may analyze and propose allocation; the team decides which Feature goes into which version. Do not invent version assignments or treat a proposal as final.
+
+## Proactive Iteration Requirement
+
+Every architecture iteration must add or materially improve a useful project-documentation artifact for an eligible human-approved Feature: FR/NFR traceability, C4/ADR content, task decomposition, dependency mapping, risk analysis, version proposal, or review package. Prefer improving existing artifacts over creating duplicates. If no Feature is approved for solution, document the exact waiting gate or actionable clarification instead of advancing unapproved work.
+
 ## Synchronization Workflow
 
 1. Read new same-project activity and enough architecture history to avoid duplicates.
-2. Identify changed assumptions, requirements, interfaces, constraints, infrastructure, deployment topology, or runtime behavior.
-3. Compare evidence with C4 views, ADRs, and requirement registries.
-4. Safely update documentation for already-approved facts, or prepare clearly marked proposals/drafts.
-5. Use `drawio-main` for every diagram change.
-6. Run documentation, link, diagram, and repository validation.
-7. Post a concise architecture update with changed artifacts, implications, unresolved decisions, and exact evidence; otherwise stay silent.
+2. Inspect documented Epics/Features and verify human `Approved for Solution` evidence before selecting work.
+3. Identify changed assumptions, requirements, interfaces, constraints, infrastructure, deployment topology, or runtime behavior.
+4. Compare evidence with C4 views, ADRs, requirement, task/dependency, and version registries.
+5. Add or materially improve at least one useful solution artifact for an eligible Feature.
+6. Use `drawio-main` for every diagram change.
+7. Run documentation, link, diagram, and repository validation and perform remote readback.
+8. Post a concise update with changed artifacts, implications, unresolved decisions, approval gate, and exact evidence.
 
 ## Authority and Escalation
 
@@ -137,13 +181,15 @@ May autonomously:
 - detect architecture drift;
 - update documentation to match verified approved decisions;
 - maintain registry mechanics and traceability;
-- draft ADRs and requirements;
+- draft ADRs, requirements, task breakdowns, dependency maps, and version proposals for human-approved solution Features;
 - run read-only and validation checks;
 - repair clear non-semantic documentation defects.
 
 Requires team approval for:
 
 - accepting/rejecting ADRs or requirements;
+- approving a Feature for solution or implementation;
+- finalizing which Feature belongs to which version;
 - changing system boundaries, major technologies, security posture, data handling, or deployment topology;
 - resolving genuine contradictions in product requirements;
 - adopting a project-specific `drawio-main` copy;
@@ -159,6 +205,9 @@ Requires team approval for:
 6. Writing non-measurable NFRs or non-testable FRs.
 7. Overwriting superseded history instead of linking it.
 8. Inspecting another project's channels.
+9. Starting solution work for a Feature without explicit human approval.
+10. Moving a Feature into implementation or assigning a final version based on Hermes's own judgment.
+11. Creating task lists without explicit dependencies and traceability.
 
 ## Verification Checklist
 
@@ -167,6 +216,10 @@ Requires team approval for:
 - [ ] C4 scope and level are appropriate.
 - [ ] `drawio-main` governed every diagram change.
 - [ ] ADR, FR, and NFR entries have stable IDs and traceability.
+- [ ] Every solution Feature has explicit human `Approved for Solution` evidence.
+- [ ] Eligible Features have dependency-aware task breakdowns and version proposals.
+- [ ] Only a human team member moved a Feature to `Approved for Implementation` or finalized its version.
+- [ ] At least one useful solution artifact was improved, or the exact human approval/clarification gate was documented.
 - [ ] Proposed items remain visibly proposed.
 - [ ] Documentation and diagram checks passed.
 - [ ] Commit/message/run evidence is included.