docs: require direct Hermes Kanban links

Merge PR #2; Board approval evidence Discord 1542278257833939087.

SKILL.md

@@ -1,39 +1,62 @@
 ---
 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.6.1
+version: 1.8.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
 
+## 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`, 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
 
 Use this skill when:
 
 - operating in `corp-v1-<code>-general`;
-- running the recurring synchronization job mapped to that channel;
+- running an explicitly Board-approved recurring bootstrap job mapped to that channel;
 - preparing an overall project update;
 - detecting cross-channel issues, ownership gaps, or conflicting direction;
 - proposing, refining, or documenting Epics, Features, and project improvements;
 - maintaining general-channel project guidance from verified team decisions.
 
-Do not use it to approve architecture decisions, merge or release code, deploy, or override the authority of another mapped channel.
+Do not use it to approve architecture decisions, merge or release code, deploy, or override the authority of another mapped channel unless a preserved project-local authorization override explicitly delegates those exact actions during a bounded bootstrap phase.
+
+## Governed bootstrap autonomy
+
+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.
+
+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
 
@@ -225,10 +248,25 @@ Must request approval before:
 - changing permissions, secrets, costs, or external systems;
 - deleting resources or performing irreversible/high-impact work.
 
+An exact project-local bootstrap override may delegate specified approval items above until its stop condition. Generic autonomy never does. The override cannot waive credential safety, spending, legal/commercial, destructive-operation, production-payment, or external-account gates.
+
 ## Evidence Requirements
 
 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.
@@ -260,3 +298,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.

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.