docs: record release governance decision

docs/reference/arch.md

@@ -89,6 +89,12 @@
     - All UniDesk agent changes must be developed on `master` and pushed to `origin master`. Agents must not create, switch to, or push feature/fix branches for UniDesk work.
     - Live deployment should run from a known commit or from a change set that is immediately committed and pushed; local-only hotfixes must not become the implicit dependency for later tasks.
     - Secrets, tokens, generated runtime state, and node-local env files stay outside Git, but their required contract, storage location, and recovery path must be documented so pushing source changes is not blocked by runtime-only data.
+  - Release And CI/CD Governance
+    - Release-line governance is owned by `docs/reference/release-governance.md` and [GitHub issue #6](https://github.com/pikasTech/unidesk/issues/6).
+    - `master` remains the integration branch for normal agent work and high-risk architecture development. A future `release/v1` line is an explicit stable maintenance/runtime line, not a general-purpose feature or fix branch.
+    - Production and stable-dev runtime must be commit-pinned through `deploy.json` and verified with runtime metadata. They must not float with the latest `master`, a local worktree, copied files, or copied images.
+    - CI/CD server and control-plane services follow the same commit-pinned runtime rule. A CLI built from `master` is allowed only when it remains compatible with the pinned server and obeys server-reported capabilities.
+    - Feature flags are short-lived risk controls. Long-lived architecture divergence must be expressed with release lines, service boundaries, or deployment boundaries instead of permanent in-process flag paths.
   - Critical Task Deployment Principles
     - Single-point components such as the database, core scheduler logic, and API gateway are deployed on the main server
     - The high-availability environment of the main server ensures the critical scheduling path never breaks