docs: prefer PR CI for heavy validation

Board authorization: Discord message 1541394858005110784.

Co-Authored-By: Hermes Agent <noreply@nousresearch.com>

SKILL.md

@@ -1,13 +1,13 @@
 ---
 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 six same-project channels; proactively improves evidence-based product scope; and records human approval before work enters Architecture solution design."
-version: 1.4.0
+version: 1.5.1
 author: Hermes Agent
 license: MIT
 metadata:
   hermes:
     tags: [corp-v1, discord, channel, scope, roadmap, epics, features, discovery]
-    related_skills: [corp-v1--main, home-v1-discord, documentation-docusaurus]
+    related_skills: [corp-v1--main, home-v1-discord, documentation-docusaurus, corp-v1--glossary]
 ---
 
 # Corp v1 Scope Channel
@@ -20,6 +20,8 @@ Scope owns Overview, Roadmap, Epics, Features, canonical Task records/reader pag
 
 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.
+
 ## When to Use
 
 Use this skill when:
@@ -257,8 +259,10 @@ Use evidence from all six same-project channels. Delivery and release outcomes m
 4. Inspect Overview, Roadmap, Ideas, Questions, the exact Epics → Epic → Features → Feature → Tasks hierarchy, every separate Task reader page, links, IDs, unified delivery statuses, required-child roll-ups, and approval evidence.
 5. Reconcile architecture feasibility, Kanban flow, delivery progress, and release outcomes against scope.
 6. Add or materially improve at least one useful evidence-based artifact, or document the exact evidence/approval blocker.
-7. Load `documentation-docusaurus`, validate menu order, dedicated sidebar, hierarchy, links, and documentation build, then verify remote state.
+7. Load `documentation-docusaurus` and the project CI/CD skill. Run only fast, dependency-free local preflight checks such as schema/parity scripts, targeted tests already available, `git diff --check`, and secret scanning. Do not spend the working session installing dependencies or repeatedly running the full documentation build locally when PR-triggered Gitea Actions can provide the authoritative environment.
-8. Post a concise Scope update with changed artifacts, implications, human gate, and exact evidence. Stay silent when no substantive result exists.
+8. Push the smallest coherent reviewable branch early and open or refresh its PR. The PR workflow must install dependencies and run the complete canonical-data validation, tests, typecheck, strict production build, and built-site assertions without publishing. Wait for the run attached to the exact pushed SHA; inspect failed job steps and logs, fix only evidenced defects, push, and repeat until that exact head is green.
+9. Review the exact CI-green head, merge through the repository workflow, then require default-head CI/publication success and deployed remote readback before reporting completion. Never treat a local build, a stale run, or CI for another SHA as acceptance evidence.
+10. Post a concise Scope update with changed artifacts, implications, human gate, exact PR/head/run evidence, and deployed readback. Stay silent when no substantive result exists.
 
 ## Authority and Escalation
 
@@ -290,13 +294,15 @@ Requires human approval for:
 8. Inspecting another project's channels.
 9. Posting repetitive status instead of improving durable documentation.
 10. Claiming completion without build and remote readback evidence.
-11. Treating approval names as delivery statuses instead of separate gates.
+11. Keeping a complete documentation build local by default instead of delegating dependency installation, full validation, typecheck, tests, and production build to PR-triggered Gitea Actions.
-12. Marking an Idea `DONE` merely because it was promoted, rather than rolling up its governed resulting items.
+12. Reading only a PR badge or latest run without proving the run's `head_sha` equals the pushed candidate SHA.
-13. Deriving a parent from an incomplete, duplicated, or unvalidated child set.
+13. Treating approval names as delivery statuses instead of separate gates.
-14. Counting a cancelled child as done or silently excluding it without an explicit scope decision.
+14. Marking an Idea `DONE` merely because it was promoted, rather than rolling up its governed resulting items.
-15. Moving a parent to `TO_BE_RELEASED` while any required child remains in backlog, design, active delivery, or progress.
+15. Deriving a parent from an incomplete, duplicated, or unvalidated child set.
-16. Flattening the reader hierarchy by placing Features directly under an Epic or Tasks outside their owning Feature's `Tasks` group.
+16. Counting a cancelled child as done or silently excluding it without an explicit scope decision.
-17. Rewriting historic canonical identities, evidence, or append-only hashes solely to adopt `<UPPERCASE_PROJECT_CODE>-TS-<NUMBER>` display IDs.
+17. Moving a parent to `TO_BE_RELEASED` while any required child remains in backlog, design, active delivery, or progress.
+18. Flattening the reader hierarchy by placing Features directly under an Epic or Tasks outside their owning Feature's `Tasks` group.
+19. Rewriting historic canonical identities, evidence, or append-only hashes solely to adopt `<UPPERCASE_PROJECT_CODE>-TS-<NUMBER>` display IDs.
 
 ## Verification Checklist