docs: formalize release workflow and frontend layout guardrails

rules.md

@@ -239,3 +239,57 @@ class BaseCollector:
   - Python-side post-filtering
   - repeated summary queries that can be merged
   - repeated per-request recomputation that should be cached or aggregated once
+
+---
+
+## Release Workflow - MANDATORY
+
+- When the user asks to `发版`, `bump version`, `release`, or `推送发布类改动`, treat it as a release workflow, not a plain commit
+- Apply repository versioning rules consistently:
+  - `feature` -> `+0.1.0`
+  - `bugfix` -> `+0.0.1`
+  - `docs / maintenance / refactor` do **NOT** bump version unless the user explicitly wants a release anyway
+- A release bump **MUST** update all version-bearing files together:
+  - `VERSION`
+  - `frontend/package.json`
+  - `pyproject.toml`
+  - `uv.lock`
+- A release bump **MUST** update release records together:
+  - `docs/CHANGELOG.md`
+  - `docs/version-history.md`
+- Before committing a release, verify the target version appears consistently in all required files
+- Before pushing a release, run the smallest relevant validation available for the changed scope and report what was or was not validated
+- If runtime output directories are part of the feature flow, confirm they are ignored appropriately so release commits do not accidentally include generated artifacts
+- If asked to commit/push release work, do **NOT** skip changelog or version-history updates just because the code changes are small
+- Use the repo skill at `/home/ray/dev/linkong/planet/.codex/skills/release-workflow/SKILL.md` whenever performing a release workflow for this repository
+
+---
+
+## Frontend Layout - MANDATORY
+
+- Backend/admin pages must be designed as a `single-screen workspace` first, not as a long vertically stacked document
+- In common desktop viewports, users should be able to see:
+  - page header
+  - summary/controls
+  - the main work area
+- The main work area must get the majority of the available height; secondary cards must not crowd it out
+- If a card or panel would be compressed until text, controls, or tables become unreadable, stop shrinking it and give that region an internal scrollbar instead
+- On small screens, high browser zoom, or reduced viewport height, switch to a compact mode or horizontal summary scrolling before allowing important content to be crushed
+- Overflow ownership must be explicit:
+  - parent height chain must be valid
+  - height-constrained flex parents need `min-height: 0`
+  - only the intended scroll node should own `overflow: auto`
+- Do **NOT** rely on `overflow: hidden` as the final fix for a crowded layout unless another child container is explicitly responsible for scrolling
+- For tabs:
+  - hidden tab panes must stay hidden
+  - do not override library hidden-pane selectors in a way that makes inactive content visible
+  - each tab must define its own scroll strategy instead of inheriting a one-size-fits-all table layout
+- For long-form content such as AI briefs, logs, markdown, raw JSON, or help text:
+  - prefer normal document flow inside the content block
+  - if height is constrained, use a stable minimum readable height plus scrolling
+  - do not let flex compression collapse the readable area into a thin strip
+- Avoid brittle viewport sizing:
+  - prefer `height: 100%` chains over naive `100vh/100vw` usage in embedded/admin shells
+  - verify layouts under browser zoom `125%` and `150%`
+- Avoid using wrapper components with implicit layout behavior, such as `Space`, for height-critical scroll regions unless their generated DOM is fully accounted for
+- Any UI state that hides data or a layer must also reconcile related hover/lock/tooltip/selection state so hidden content is not still “active” in the UI