feat: mine reusable AeroSim channel lessons

2026-09-10 11:41:24 +00:00
parent ef46b74bb0
commit 3fad2179c4
7 changed files with 484 additions and 1 deletions
@@ -1,7 +1,7 @@
 ---
 name: corp-v1-channel-scope
 description: "Use when operating or synchronizing a Corp v1 project's Scope channel. Owns Roadmap, Epics, Features, and Ideas; correlates all seven same-project channels; proactively improves evidence-based product scope; and records human approval before work enters Architecture solution design."
-version: 1.6.0
+version: 1.7.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -306,6 +306,23 @@ Requires human approval for:
 - changing governance, architecture, implementation, version, or release decisions;
 - permissions, credentials, spending, external contact, or irreversible/high-impact work.

+
+## 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 Scope Lessons
+
+Use a stable, idempotent channel-handoff packet only after the source-owned outcome is complete and verified. The destination validates evidence and its own entry gates, processes each handoff ID at most once, and returns an incomplete packet without inferring approval. Follow [references/channel-handoff.md](references/channel-handoff.md).
+
+When unresolved product questions affect approval, make the boundary reviewable: distinguish unconditional readiness from conditional approval allowed by the active project authority contract; place exact open-question IDs on the Roadmap and the affected Epic/Feature pages; preserve conditions as Architecture risks; and never let Epic approval imply child-Feature approval. Use [references/decision-readiness.md](references/decision-readiness.md) and [references/data-backed-scope-integrity.md](references/data-backed-scope-integrity.md).
+
+When a human asks whether an Epic contains all Features required for its outcome, test the full user journey, distinguish shared acceptance expectations from independently valuable Features, preserve exclusions, and keep the result a proposal until approved. Use [references/feature-set-completeness.md](references/feature-set-completeness.md).
+
+Refine experiential requests into observable loops: entry/start, continuous user control, meaningful state change, visible feedback, outcome/failure, and replay/recovery. Keep feasibility research separate from solution selection. For Epic-wide constraints, create one canonical cross-cutting question, link it reciprocally to every affected Feature, validate both directions, and search for stale count/range assertions. Use [references/roadmap-multidimensional-state.md](references/roadmap-multidimensional-state.md) and [references/react-flow-governed-state.md](references/react-flow-governed-state.md) when the project uses data-backed readers or graphs.
+
 ## Common Pitfalls

 1. Treating General as the authoritative owner of Scope records.