feat: mine reusable AeroSim channel lessons

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 exact admission before tasks enter the READY_FOR_DELIVERY pickup queue."
-version: 1.6.0
+version: 1.7.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -238,6 +238,21 @@ The Kanban-channel implementation prohibition above is a channel boundary, not a
 
 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.
 
+
+## Mined Project-Adoption Improvements
+
+## Dedicated Project Channel Workspace
+
+Every project adoption must bind this channel to a dedicated local workspace under the active working root. Keep clones, worktrees, plans, reports, screenshots, generated artifacts, retained logs, and channel inputs inside that channel root. Use run-unique or task-specific children under `workspace/`; keep durable project truth in approved repositories. A local folder boundary organizes execution only—it neither broadens authority nor replaces remote evidence. Delivery adoptions should additionally use a channel-level `cache/` for reusable pinned toolchains and dependencies, while keeping Task evidence isolated by Task.
+
+## Project-Adoption Kanban Lessons
+
+Assess **structural readiness** and **evidence readiness** independently. A valid route, sidebar, validator, and production build do not prove that embedded PR heads, CI tasks, blockers, or “pending/open” claims are current. Query every mutable record, reconcile Board and Focus together, preserve human gates, and rerun validation/readback after evidence changes.
+
+Use two-pass channel evidence collection, distinguish substantive messages from boilerplate high-watermarks, and resolve mutable PR/CI facts from authenticated repository readback. Do not embed the Kanban PR's own mutable head as durable current evidence. Adopt an existing same-purpose writer branch rather than racing it; re-check remote parent equality before commit and push; and if a review merges during the run, branch any required follow-up from the verified integration head. Follow [references/recurring-refresh-and-publication.md](references/recurring-refresh-and-publication.md).
+
+When bootstrapping or structurally repairing Kanban documentation, preserve dedicated Board/Focus information architecture, semantic empty states, fail-closed validators, exact-head CI, and authenticated artifact readback. Follow [references/kanban-bootstrap-and-validation.md](references/kanban-bootstrap-and-validation.md).
+
 ## Common Pitfalls
 
 1. Treating Kanban as a second source of truth for Scope or Architecture.