docs: restrict kanban sessions to planning

SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: corp-v1-channel-kanban
 description: "Use when operating or synchronizing a Corp v1 project's Kanban channel. Maintains Board and Focus across Epic, Feature, and task state; correlates all seven same-project channels; and records human approval before tasks enter Delivery's executable InBacklog queue."
-version: 1.4.2
+version: 1.5.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -47,6 +47,28 @@ Use this skill when:
 
 Do not use it to approve tasks autonomously, redesign architecture, implement code, merge, release, deploy, or alter another project's board.
 
+## Kanban-channel execution boundary
+
+A session running in a project's mapped `kanban` channel is a governance, planning, and Kanban-documentation session—not an implementation session. This boundary applies to direct tool use and delegated or spawned work initiated by that session.
+
+It may:
+
+- inspect project repositories read-only when needed to verify current evidence;
+- plan and decompose work, identify dependencies and blockers, prepare task-readiness packages, and update the governed Board or Focus;
+- change only the project documentation's dedicated top-level **Kanban** area and the wiring, tests, or validators strictly required to publish and verify that area;
+- maintain the mapped project Kanban channel skill and this central Kanban reference skill when separately authorized.
+
+It must not:
+
+- implement application, service, package, infrastructure, deployment, or architecture changes in a project repository;
+- change project documentation outside the dedicated Kanban area except the minimum navigation/sidebar wiring required for that area;
+- create or continue an implementation branch, worktree, commit, pull request, deployment, or implementation subagent from the Kanban-channel session;
+- treat task admission, an implementation approval, or a human request to plan as authority to execute the task.
+
+When a request includes implementation, stop at an evidence-backed plan and Board/Focus update, then hand the admitted task to the project's Delivery channel for execution under the Delivery skill. Do not execute the implementation from the Kanban channel even when it appears small or already approved. Skill-repository changes explicitly authorized to maintain this channel boundary are governance maintenance, not project implementation.
+
+This execution boundary was approved by RootAtSkic (`discord:1518725627845283888`) in Discord message `1544730750660907057` on 2026-09-02.
+
 ## Approved Information Boundary
 
 Inspect only:
@@ -195,6 +217,8 @@ May autonomously:
 - prepare task-readiness recommendations;
 - record explicit human decisions;
 - run read-only and documentation-validation checks.
+- modify and publish only the dedicated Kanban documentation area and its minimum required navigation/sidebar wiring;
+- maintain the mapped Kanban channel skill or central Kanban reference skill when separately authorized.
 
 Requires human approval for:
 
@@ -205,6 +229,8 @@ Requires human approval for:
 - merging, releasing, deploying, or changing architecture;
 - secrets, permissions, costs, destructive, irreversible, or external actions.
 
+The Kanban-channel implementation prohibition above is a channel boundary, not an additional approval gate; implementation approval does not waive it.
+
 ## Evidence Requirements
 
 Include exact project documentation paths, item IDs, source links, human decision message IDs or records, commits, remote readback, CI task/run IDs when configured, and any unresolved contradiction. Clearly label derived board state and proposals.
@@ -221,10 +247,13 @@ Include exact project documentation paths, item IDs, source links, human decisio
 8. Hiding contradictions instead of routing them to the owning channel.
 9. Inspecting another project's channels.
 10. Posting passive status when safe Board/Focus maintenance is possible.
+11. Implementing project work, opening an implementation PR, or spawning an implementation worker from a Kanban-channel session instead of planning it and handing it to Delivery.
 
 ## Verification Checklist
 
 - [ ] Only the seven same-project channels were inspected.
+- [ ] The session changed no project implementation repository; project-repository writes were limited to the dedicated Kanban documentation area and its minimum required wiring.
+- [ ] Any implementation request was represented in planning/Board/Focus and handed to Delivery rather than executed or delegated from Kanban.
 - [ ] Kanban appears immediately after Architecture and has its own Board/Focus sidebar.
 - [ ] Board uses only `InIdeation`, `InBacklog`, `InProgress`, and `ToBeReleased`.
 - [ ] Board contains only unfinished Epics and Features.