docs: promote reusable AeroSim channel lessons

Merge PR #2; Board approval evidence Discord 1542278257833939087.

SKILL.md

@@ -1,26 +1,41 @@
 ---
 name: corp-v1-channel-general
 description: "Use when operating or synchronizing a Corp v1 project's general channel. Correlates verified activity across the project's general, scope, architecture, kanban, delivery, and releases channels; reports overall status, surfaces issues, and maintains project-level guidance."
-version: 1.7.0
+version: 1.9.0
 author: Hermes Agent
 license: MIT
 metadata:
   hermes:
     tags: [corp-v1, discord, channel, general, coordination, synchronization]
-    related_skills: [corp-v1--main, home-v1-discord, documentation-docusaurus, corp-v1--glossary]
+    related_skills: [corp-v1-main, home-v1-discord, documentation-docusaurus, corp-v1-glossary]
 ---
 
 # Corp v1 General Channel
 
 ## Overview
 
-This skill owns project-level awareness and coordination for a Corp v1 project's `general` channel. It monitors the complete same-project channel set—`general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, and `releases`—and turns verified activity into concise overall updates, issue visibility, and maintained guidance. Scope owns the authoritative Roadmap, Ideas, Epics, and Features; General may propose improvements and routes them to Scope instead of duplicating records.
+## Hermes Kanban direct-link contract
+
+Whenever a response mentions a Hermes Kanban board, initiative, card, or task, it must include a direct dashboard link in the form `[descriptive board label](<dashboard-public-url>/kanban?board=<board-slug>)`. Resolve the dashboard public URL and exact board slug before reporting; never provide only a board name, slug, card count, “visible cards,” or “available in the dashboard.” If no task-specific deep link exists, link the board and include the exact task ID or title in the same statement. Project-adopted skills must replace this generic form with their verified project board URL.
+
+This skill owns project-level awareness and coordination for a Corp v1 project's `general` channel. It monitors the complete same-project channel set—`general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, `uat`, and `releases`—and turns verified activity into concise overall updates, issue visibility, and maintained guidance. Scope owns the authoritative Roadmap, Ideas, Epics, and Features; General may propose improvements and routes them to Scope instead of duplicating records.
 
 It is not a replacement for architecture, delivery, or release ownership. It connects those workstreams, makes their implications visible to the whole project, and routes specialized work to the corresponding channel.
 
 Load the global `documentation-docusaurus` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus` before changing documentation structure, navigation, Markdown/MDX, Docusaurus configuration, or builds.
 
-Load the global `corp-v1--glossary` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1--glossary` whenever project documentation needs to define or explain a reusable term. Maintain one canonical definition in the project's final top-level **Glossary** area and link to it from the owning domain page; do not duplicate glossary-style explanations across channel documentation.
+Load the global `corp-v1-glossary` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1-glossary` whenever project documentation needs to define or explain a reusable term. Maintain one canonical definition in the project's final top-level **Glossary** area and link to it from the owning domain page; do not duplicate glossary-style explanations across channel documentation.
+
+## Shared Corp v1 System Login
+
+When an authorized task requires login to a Corp v1 system being built or operated, follow the shared policy in `corp-v1-main` and use only the Bitwarden-injected runtime secrets named:
+
+```text
+HL_V1_SSO_EMAIL
+HL_V1_SSO_PASSWORD
+```
+
+Secret availability is capability, not authorization. Verify the destination origin and task purpose before login. Never print, inspect, log, hash, serialize, paste, screenshot, or persist either value; never place a value in a command line, URL, file, repository, prompt, Discord message, browser console, test fixture, CI output, or generated artifact. Never ask a human to paste a value into chat. If a variable is unavailable, report only its missing name and request Bitwarden/gateway injection. Login does not authorize account recovery, MFA or credential changes, permission changes, billing, spending, destructive operations, or access outside the approved project task.
 
 ## When to Use
 
@@ -39,13 +54,17 @@ Do not use it to approve architecture decisions, merge or release code, deploy,
 
 The Corp v1 default is no project scheduler. One 30-minute General-channel bootstrap job is permitted only when the project's approved kickoff decision and adopted General skill contain the same preserved project-local authorization override.
 
-The override must identify the Board evidence, project, delegator, delegate, exact seven channels, autonomous actions, safety exclusions, and a **first-human-message stop condition**. Before every mutation, the job must scan all seven project channels after its frozen high-watermarks and distinguish human authors from bots, webhooks, and Hermes. If any human-authored project-channel message exists after bootstrap began, the job must make no further autonomous mutation, cite the message and channel, post one stop report in General, and pause or remove itself.
+The override must identify the Board evidence, project, delegator, delegate, exact recorded channel IDs, autonomous actions, safety exclusions, and a **first-human-message stop condition**. Before every mutation, the job must scan all channels recorded in the override after its frozen high-watermarks and distinguish human authors from bots, webhooks, and Hermes. If any human-authored project-channel message exists after bootstrap began, the job must make no further autonomous mutation, cite the message and channel, post one stop report in General, and pause or remove itself.
+
+Historical seven-channel overrides remain limited to those recorded channels unless separately reauthorized; new or explicitly reauthorized overrides use the current eight-channel boundary. The topology update alone does not expand autonomous scope.
 
 During an active approved bootstrap phase, the job may load the mapped project channel and engineering skills and advance approved MVP artifacts across Scope, Architecture, UI/UX, Kanban, Delivery, and Releases. It must preserve canonical ownership, exact-head validation, remote readback, and review evidence. It may not expose or change secret values, spend money, purchase goods, enable production payments, alter vendor accounts, make legal/commercial commitments, perform unrelated infrastructure work, or execute destructive/irreversible actions.
 
 ## Approved Information Boundary
 
-Read only the seven channels belonging to the same project:
+Follow the eight-channel topology in `corp-v1-main`, approved by Board message `1552966246591365123`; include UAT between Delivery and Releases. Verify mapped IDs and effective access before reading.
+
+Read only the eight channels belonging to the same project:
 
 ```text
 corp-v1-<code>-general
@@ -54,10 +73,11 @@ corp-v1-<code>-architecture
 corp-v1-<code>-ui-ux
 corp-v1-<code>-kanban
 corp-v1-<code>-delivery
+corp-v1-<code>-uat
 corp-v1-<code>-releases
 ```
 
-Read enough mapped-channel history to avoid duplicate updates and only new relevant messages from the other six channels since the previous useful synchronization. Never correlate another project's channels.
+Read enough mapped-channel history to avoid duplicate updates and only new relevant messages from the other seven channels since the previous useful synchronization. Never correlate another project's channels.
 
 ## Core Responsibilities
 
@@ -115,55 +135,15 @@ Every proposal must state:
 - proposed owner and destination channel;
 - whether team approval is required.
 
-Use lifecycle states `Proposed`, `Approved for Solution`, `Rejected`, or `Deferred`. Only a human team member may move an Epic or Feature to `Approved for Solution`. Hermes may propose and refine items, but must never approve its own proposal or imply approval from silence.
+Keep proposal disposition and approval gates separate from the Scope-owned delivery status. Record `Proposed`, `Approved for Solution`, `Rejected`, or `Deferred` as decision/disposition evidence, not delivery states. Only a human team member may move an Epic or Feature to `Approved for Solution`. Hermes may propose and refine items, but must never approve its own proposal or imply approval from silence.
 
 ## Project Documentation Ownership
 
 The project documentation repository is authoritative for Roadmap, Epics, Features, Ideas, overall project status, issues, and durable general-channel decisions. Discord announces and discusses changes; it does not replace documentation.
 
-### Mandatory Scope information architecture
+### Scope-owned documentation contract
 
-Every project documentation site must expose **Scope** as a top-level navigation item immediately **before Architecture**. Scope must be a dedicated documentation area with its own sidebar—not a category inside another area's sidebar.
-
-The Scope sidebar order and hierarchy are mandatory:
-
-```text
-Roadmap
-Epics
-  <CODE>-EP-1
-    <CODE>-FT-1
-    <CODE>-FT-2
-  <CODE>-EP-2
-    ...
-Ideas
-```
-
-The pages and navigation must satisfy this contract:
-
-1. **Roadmap** always reflects both the verified current situation and the predicted upcoming plan at Epic and Feature level. Distinguish actual/approved state from forecasts and proposals; include status, sequence or horizon, dependencies, material blockers, and last evidence/update date. Refresh it whenever an Epic or Feature changes materially.
-2. **Epics** is the ordered registry and hierarchy for all Epic records. Each Epic has its own page titled with its stable `<CODE>-EP-N` ID and human-readable title.
-3. Each **Epic page** contains at least the Epic title, description, and a Features section with a table linking every child Feature and showing its current status. The table must not contain unlinked or nonexistent Feature IDs.
-4. Each **Feature** is nested under its parent Epic in the sidebar and has its own page titled with its stable `<CODE>-FT-N` ID and human-readable title.
-5. Each **Feature page** contains at least the Feature title, description, and a Tasks section with a table linking every architecture-owned implementation task and showing its current status. Preserve the task identifiers established by the Architecture channel; do not create duplicate General-channel task records.
-6. **Ideas** tracks early opportunities that are not yet accepted as Epics or Features. Each Idea records a stable local reference, title, description, evidence/source, owner when known, status, and any resulting Epic/Feature link. Promotion preserves provenance rather than deleting the Idea.
-
-Minimum Epic Features table:
-
-```markdown
-| Feature | Title | Status |
-|---|---|---|
-| [XYZ-FT-1](./xyz-ft-1) | Example feature | Proposed |
-```
-
-Minimum Feature Tasks table:
-
-```markdown
-| Task | Title | Status |
-|---|---|---|
-| [authoritative task ID](task-record-link) | Example task | Planned |
-```
-
-Validate top-menu order, Scope's dedicated sidebar, hierarchy, unique IDs, parent-child relationships, and every Epic→Feature and Feature→Task link during documentation builds. Empty registries require useful empty-state pages; they do not justify omitting Scope, Roadmap, Epics, or Ideas.
+Load the mapped Scope skill and validate its current documentation contract rather than maintaining a competing General hierarchy. Scope owns navigation, canonical records, delivery statuses and roll-up; Architecture retains task derivation and readiness. Check stable IDs, reciprocal parent/child links, current Roadmap evidence and distinct forecasts. Route semantic corrections through Scope; do not duplicate Task records or infer approval from a flow view.
 
 Each useful iteration must add or materially improve at least one evidence-based artifact—for example a grounded proposal, better value/scope/acceptance outcomes, deduplication, status from an explicit human decision, cross-links, or a concrete unanswered product question. Never create filler merely to satisfy cadence. If evidence is insufficient, document and raise the specific blocker/question.
 
@@ -204,16 +184,19 @@ UI/UX owns frontend experience and interface-design work. General routes user-fa
 
 ## Synchronization Workflow
 
-1. Confirm the exact project code and seven approved channel IDs.
-2. Read new messages from the other six channels and enough `general` history to avoid duplicates.
+1. Confirm the exact project code and eight approved channel IDs for ordinary synchronization. For a bootstrap run, every scan and action below instead uses only the override's recorded IDs; never widen a historical boundary through this workflow.
+2. Read new messages from the other seven channels and enough `general` history to avoid duplicates.
 3. Separate facts, approved decisions, proposals, unresolved questions, and failed work.
-4. Correlate impact across architecture, Kanban, delivery, and releases.
+4. Correlate impact across architecture, Kanban, delivery, UAT, and releases.
 5. Inspect Scope navigation, Roadmap, Epics, Features, Ideas, task links, and lifecycle status.
 6. Reconcile the Roadmap whenever current or predicted Epic/Feature state changed.
 7. Add or materially improve at least one useful evidence-based documentation artifact; never create filler solely to satisfy cadence.
 8. Perform other safe, reversible coordination work when useful.
 9. Validate Scope menu order, dedicated sidebar hierarchy, identifiers, relationships, links, and the documentation build; verify changes through remote readback.
-10. Post one concise update with documentation path and commit evidence, or state the concrete blocker that prevented a useful change.
+10. After CI/readback, scan only the approved channels after this run's per-channel high-watermarks. Keep polling watermarks separate from substantive evidence IDs; read required continuations in full. Reconcile material late decisions against repository state before reporting; boilerplate or a status question alone does not require a new commit.
+11. Return one concise update with documentation path and commit evidence, or the concrete blocker. If the execution context automatically delivers the final response, do not also send a channel message. Use `[SILENT]` only when that context requests it and no substantive result exists. Claim message delivery/readback only when separately performed and verified; repository readback is not message delivery.
+
+Source comparison and exclusions: [AeroSim lessons review](references/aerosim-lessons-review.md).
 
 ## Authority and Escalation
 
@@ -239,6 +222,19 @@ An exact project-local bootstrap override may delegate specified approval items
 
 For completed work include exact evidence such as Discord message IDs, repository URLs, branch names, commit SHAs, documentation paths, CI run IDs, or check output. Mark uncertain conclusions as 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 Evidence Lessons
+
+Treat governance wording in an open documentation PR as **pending review evidence**, never as current default-branch policy. Verify default-branch wording and the review head separately, preserve the established authority boundary while review is open, and after merge refresh every affected Roadmap, Kanban, Delivery, and release-readiness artifact. Cross-channel adoption, green CI, bot summaries, silence, or repeated proposals are not governance approval.
+
+When a shared coordination PR is refreshed, explicitly fetch its exact source ref, reconcile concurrent writers without force-pushing, avoid embedding the PR's own mutable head as durable “current” evidence, and perform a final exact-head/CI/readback check immediately before reporting. Follow [references/shared-coordination-pr-refresh.md](references/shared-coordination-pr-refresh.md).
+
 ## Common Pitfalls
 
 1. Posting repetitive “nothing changed” updates instead of contributing useful documentation.
@@ -255,12 +251,12 @@ For completed work include exact evidence such as Discord message IDs, repositor
 
 ## Verification Checklist
 
-- [ ] Only the seven same-project channels were inspected.
+- [ ] Only the eight same-project channels were inspected.
 - [ ] The update is new, substantive, and deduplicated.
 - [ ] Overall status, issues, and cross-channel implications are accurate.
 - [ ] Proposals are clearly labeled and routed.
 - [ ] Scope appears immediately before Architecture in the top menu and uses its own sidebar.
-- [ ] Scope sidebar order is Roadmap, Epics with nested Features, then Ideas.
+- [ ] Scope navigation and hierarchy match the current mapped Scope contract, not a duplicate General specification.
 - [ ] Roadmap shows current evidence and predicted Epic/Feature plans distinctly and is current.
 - [ ] Epics and Features use stable `<CODE>-EP-N` and `<CODE>-FT-N` IDs and lifecycle state.
 - [ ] Every Epic links all child Features with statuses; every Feature links all authoritative tasks with statuses.
@@ -270,4 +266,4 @@ For completed work include exact evidence such as Discord message IDs, repositor
 - [ ] Guidance changes derive from verified team decisions.
 - [ ] Completed activities include exact evidence.
 - [ ] Approval-required actions remain proposals.
-- [ ] When a bootstrap job is active, its override, seven-channel boundary, frozen high-watermarks, human-message check, General delivery target, and scheduler state are verified.
+- [ ] When a bootstrap job is active, its override, recorded channel boundary, frozen high-watermarks, human-message check, General delivery target, and scheduler state are verified.

references/aerosim-lessons-review.md

@@ -0,0 +1,30 @@
+# AeroSim lessons review — general
+
+## Evidence boundary
+
+Source repository: [corp-v1-aerosim-skills-code-agent/corp-v1-channel-general-aerosim](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/corp-v1-channel-general-aerosim)
+
+Source commit: `f97a4e8bbc1e107ddff0fac02a6730a32afed56e` (branch `test`, pinned clone; not the earlier adoption-base SHA).
+
+Central baseline: `e291ea3af85f7656d9293fad510c217ca495df0f`. Reviewed the full source package: `SKILL.md`, `ADOPTION.md`, and `references/shared-coordination-pr-refresh.md`. All existing source reference files were byte-identical to central at baseline; changes below address omissions or contradictions, not wholesale copying.
+
+The installed `corp-v1-channel-general-aerosim/SKILL.md` was also compared read-only. Runtime SHA-256: `5944a1ba8198f90bca29c186bec8dc173bac006c7cf412dedce9ae0eda53ef58`. Runtime differs from the pinned repository and has no verified source commit for its local-only changes; it is observation, not remote or Board approval evidence. This delegated review did not change any installed package or AeroSim/other project copy. The coordinating session owns authorized central publication and central runtime refresh.
+
+Review authority: Board-owner request message `1562171939961966693` authorizes central reference improvement and remote publication; the coordinating session also owns the authorized central runtime refresh. Central source publication must be verified before refreshing its installed package. No project adoption, project permission/authority expansion or naming migration is authorized.
+
+## Adopted lessons
+
+- `SKILL.md` → **Synchronization Workflow**, steps 6–12 (especially 11–12), and `references/shared-coordination-pr-refresh.md` → **6. Close the channel-activity race** / **7. Scheduled-delivery boundary**: make the existing reference's final convergence and single-delivery checks explicit at the point of execution. Polling watermarks are not substantive evidence. Material late changes require reconciliation, not a stale success report.
+- `SKILL.md` → **Overview**, **Pending ownership and governance corrections**, and **Kanban Handoff**: preserve domain ownership. Remove the central General copy of Scope navigation/table rules and approval-shaped delivery vocabulary; the pinned central Scope contract already has a different hierarchy and separates gates from delivery. This is conflict removal, not adoption of AeroSim's navigation.
+
+## Exclusions
+
+No roster/contact data, named owner assignments, standing merge delegation, blocker-execution authority, board migration, project-local topology overrides or scheduler authorization is imported. Runtime-only **Current AeroSim human roster and work emails — skill-only record**, **Hermes owns blocker resolution**, and **Standing AeroSim PR merge authority** were inspected but not adopted or reproduced. Runtime also differs in board routing and UAT wording; neither is proof of central policy. Existing central bootstrap stop conditions and human gates remain intact.
+
+## Central topology authority
+
+The coordinating review record `GUILD-IMP-20261020-aerosim-reference-lessons` confirms central-only maintenance. `corp-v1-main` v4.5.0, **Board Authority** / **Naming Model** / **Hermes access and Corp project automation policy**, records Board message `1552966246591365123` approving eight lifecycle channels, with UAT between Delivery and Releases. Align ordinary synchronization and references to that existing policy. Historical seven-channel bootstrap overrides are not widened; only separately reauthorized overrides may add UAT. Runtime seven-channel wording is stale, not promoted authority.
+
+## Verification
+
+Run `python3 -B -m unittest discover -s tests -v` from this repository and `git diff --check`. Tests validate normative documentation contracts and linked files offline; they do not claim live workflow, CI, deployment or remote publication verification.

references/shared-coordination-pr-refresh.md

@@ -0,0 +1,85 @@
+# Refreshing a shared coordination PR safely
+
+Use this procedure when General, Scope, Kanban, Delivery, or Releases may update the same documentation review branch.
+
+## 1. Establish authoritative remote state
+
+Before editing, read back:
+
+- the documentation repository's current default branch and exact SHA;
+- every relevant PR's state (`open`, `merged`, or closed), head SHA, base ref/SHA, and mergeability;
+- CI tasks matched to each exact PR head SHA;
+- the latest substantive messages from only the authorized project channels.
+
+Treat channel reports as leads, not repository truth. Replace stale PR states, heads, task IDs, base SHAs, and channel-message evidence together.
+
+## 2. Synchronize the shared branch explicitly
+
+Fetch both refs by their full names rather than relying on a generic prune:
+
+```bash
+git fetch origin \
+  refs/heads/<default>:refs/remotes/origin/<default> \
+  refs/heads/<coordination-branch>:refs/remotes/origin/<coordination-branch>
+```
+
+Then:
+
+1. require a clean worktree;
+2. compare local and remote SHAs;
+3. verify local `HEAD` is an ancestor of the remote coordination head;
+4. fast-forward with `git merge --ff-only`;
+5. stop and reconcile manually if histories diverged—never force-push over another channel's update.
+
+Fetch the exact coordination ref again immediately before committing or pushing. If it advanced, fast-forward and reapply/reconcile the pending edit before publication.
+
+## 3. Make one coherent evidence refresh
+
+Update the durable artifact in one pass:
+
+- latest substantive channel message IDs;
+- current PR states and exact heads;
+- exact-head CI task IDs and outcomes;
+- review ordering and stacked dependencies;
+- default-branch/base SHA;
+- lifecycle state separately from Kanban flow state;
+- approval, implementation, and release gates.
+
+When owner-channel jobs advance their review branches during the same synchronization window, treat their reports as leads and immediately re-read each PR plus its latest exact-head task. Refresh the coordination artifact at the row or item level rather than only updating a summary paragraph: roll Scope evidence into Epic/Feature rows, Kanban evidence into flow/Focus fields, Delivery evidence into implementation gates, and Releases evidence into release-readiness blockers. A bot-authored owner-channel report can prove that coordination work completed, but it cannot supply a human approval or authorization.
+
+Remove superseded head/task pairs rather than accumulating a history of stale values. Do not convert `InIdeation`, empty Focus, merged documentation, successful CI, or repeated bot summaries into lifecycle approval.
+
+## 4. Handle the self-referential head problem
+
+A commit cannot reliably embed its own final SHA in the content it creates. For the coordination PR's own row:
+
+- identify the previous exact head/task explicitly as **prior evidence**;
+- state that the current refresh supersedes it and requires new exact-head CI;
+- after pushing, put the new exact head and matching CI task in the synchronization report and remote verification record.
+
+Never label the prior head as the current PR head after the push. Do not amend repeatedly to chase a self-referential SHA.
+
+## 5. Validate and publish
+
+Before publication, run the repository's structural validators, typecheck, strict-link production build, and `git diff --check`. Commit and push only the intended files.
+
+After publication:
+
+1. fetch the exact remote branch ref and assert it equals the pushed SHA;
+2. read the changed artifact from that remote ref;
+3. verify required new markers are present and superseded markers are absent;
+4. read PR metadata back and verify open/merged state, mergeability, head SHA, base ref, and base SHA;
+5. wait for a terminal CI task whose `head_sha` exactly equals the pushed SHA;
+6. report success only when that exact task succeeds.
+
+Base-branch success, a prior PR task, or another coordination PR's task is not evidence for the pushed head.
+
+## 6. Close the channel-activity race
+
+After remote artifact readback and exact-head CI succeed, scan only the authorized project channels again. Query each channel starting after the per-channel high-watermark captured during the initial synchronization, not from an older fixed window. Keep the newest message ID as the next synchronization boundary, but cite the newest substantive message separately; continuation-only verifier warnings, delivery footers, and job-management boilerplate do not replace the message carrying the project fact.
+
+If the final scan finds a new human decision, approval, release request, blocker, or owner-channel coordination result, reassess the repository and PR state and refresh affected durable evidence before reporting. A successful push does not justify sending a summary that became stale while CI ran.
+
+## 7. Scheduled-delivery boundary
+
+When the scheduler automatically delivers the final response, return the concise report as the final response. Do not post through Discord APIs, and do not claim message delivery or readback. Repository push/readback proves publication of the artifact only.

tests/test_contracts.py

@@ -0,0 +1,41 @@
+"""Offline regression tests for normative skill-package contracts, not runtime behavior."""
+from pathlib import Path
+import re
+import unittest
+ROOT = Path(__file__).resolve().parents[1]
+SKILL = (ROOT / 'SKILL.md').read_text()
+def ref(name):
+    return (ROOT / 'references' / name).read_text()
+class Contracts(unittest.TestCase):
+    def test_evidence_and_links(self):
+        self.assertIn('(references/aerosim-lessons-review.md)', SKILL)
+        evidence = ref('aerosim-lessons-review.md')
+        self.assertRegex(evidence, r'Source commit: `[0-9a-f]{40}`')
+        self.assertIn('## Exclusions', evidence)
+        for path in re.findall(r'\]\((references/[^)#]+)(?:#[^)]*)?\)', SKILL):
+            self.assertTrue((ROOT / path).is_file(), path)
+    def test_scope_is_single_contract(self):
+        self.assertIn('Load the mapped Scope skill', SKILL)
+        self.assertNotIn('Minimum Epic Features table', SKILL)
+        self.assertNotIn('Use lifecycle states `Proposed`', SKILL)
+        self.assertIn('not delivery states', SKILL)
+    def test_convergence_precedes_report(self):
+        workflow = SKILL.split('## Synchronization Workflow')[1].split('## Authority')[0]
+        self.assertLess(workflow.index('After CI/readback'), workflow.index('Return one concise update'))
+        for term in ['per-channel high-watermarks', 'substantive evidence IDs', 'continuations in full', 'do not also send a channel message', 'repository readback is not message delivery']:
+            self.assertIn(term, workflow)
+    def test_approval_and_bootstrap_preserved(self):
+        for term in ['Only a human team member', 'first-human-message stop condition', 'no project scheduler', 'eight same-project channels']:
+            self.assertIn(term, SKILL)
+
+    def test_eight_channel_boundary(self):
+        boundary = SKILL.split('## Approved Information Boundary')[1].split('## ', 1)[0]
+        channels = re.findall(r'^corp-v1-<code>-(.+)$', boundary, re.M)
+        self.assertEqual(channels, ['general', 'scope', 'architecture', 'ui-ux', 'kanban', 'delivery', 'uat', 'releases'])
+        self.assertIn('1552966246591365123', boundary)
+        bootstrap = SKILL.split('## Governed bootstrap autonomy')[1].split('## Approved Information Boundary')[0]
+        self.assertIn('Historical seven-channel overrides remain limited', bootstrap)
+        self.assertIn('topology update alone does not expand autonomous scope', bootstrap)
+
+if __name__ == '__main__':
+    unittest.main()