Describe how changes land and ship, and hold human commits to the standard

The transparency page told evaluators that routine changes may merge
without line-by-line review, but not what governs a landing or a
release, so the commit stream was the only evidence and it read badly
(discussion #1539, the release-reliability ledger entry). The page now
states the delivery contract in public terms: every writer lands through
a pull request that auto-merges on green required checks with no bypass,
the maintainer's pull requests carry outcome, reason, and validation, and
releases run on a train with a soaked, exact-content candidate, with the
rules in RELEASE_PROMOTION_POLICY.md. The shipped docs mirror is updated
with it.

The maintainer's candidate preflight already refuses a commit without a
body or with a subject over 72 characters. The new husky commit-msg hook
holds human and interactive-agent commits in this checkout to the same
standard, exempting merge, fixup, squash, and revert messages.

.husky/commit-msg

@@ -0,0 +1,29 @@
+#!/usr/bin/env sh
+# Every commit that can reach main states what changed in a subject a reader
+# can scan and why in a body (delivery contract, rule 3). The maintainer's
+# candidate preflight enforces the same standard for its own commits; this
+# hook enforces it for human and interactive-agent commits made here.
+set -eu
+
+msg_file="$1"
+# Strip comment lines and the scissors block so only the message is judged.
+message=$(sed -e '/^#/d' -e '/^------------------------ >8 ------------------------$/,$d' "$msg_file")
+subject=$(printf '%s\n' "$message" | sed -n '1p')
+
+case "$subject" in
+  ""|"Merge "*|"fixup! "*|"squash! "*|"Revert \""*) exit 0 ;;
+esac
+
+if [ "${#subject}" -gt 72 ]; then
+  echo "commit-msg: the subject is ${#subject} characters; keep it at 72 or fewer." >&2
+  exit 1
+fi
+
+body_lines=$(printf '%s\n' "$message" | sed '1d' \
+  | grep -v -E '^(Change-source|Contract-Neutral|Signed-off-by|Co-authored-by|Fixes|Closes|Resolves|Refs|Reviewed-by|Cc|See-also): ' \
+  | grep -c '[^[:space:]]' || true)
+if [ "$body_lines" -eq 0 ]; then
+  echo "commit-msg: add a body that says why the change is needed, not only what it does." >&2
+  echo "commit-msg: git commit -m \"<subject>\" -m \"<why>\" is enough." >&2
+  exit 1
+fi

docs/AI_TRANSPARENCY.md

@@ -43,6 +43,25 @@ process discoverable without turning every technical exchange into a banner
 about how the work was produced. Individual commits, fixes, and release notes
 are not given tool-specific labels.
 
+## How changes land and ship
+
+Every change reaches `main` the same way, whoever or whatever wrote it: a
+pull request that auto-merges when the repository's required checks pass.
+The `main` branch ruleset requires that for every writer, with no bypass, so
+a red check blocks the maintainer and me alike. The maintainer's pull
+requests are opened by `pulse-triage[bot]` and state what changed, why it
+was needed, which reports or demand-ledger entries it answers, and what
+validation was used, so the record on GitHub is the record of the decision.
+
+Releases run on a train rather than on demand. A release candidate is cut
+from `main` into a `release/vX.Y` branch on a fixed schedule, soaks on the
+opt-in preview channel, takes only backports of regression and security
+fixes while it soaks, and is promoted to stable as the exact candidate
+content. The promotion resolver in the release pipeline enforces the soak
+and the exact-content rule for every dispatcher. The full rules are in
+[RELEASE_PROMOTION_POLICY.md](release-control/v6/internal/RELEASE_PROMOTION_POLICY.md),
+under "Release Train".
+
 ## Authority and responsibility
 
 The automation can operate continuously, but it is not the project owner and

frontend-modern/public/docs/AI_TRANSPARENCY.md

@@ -43,6 +43,25 @@ process discoverable without turning every technical exchange into a banner
 about how the work was produced. Individual commits, fixes, and release notes
 are not given tool-specific labels.
 
+## How changes land and ship
+
+Every change reaches `main` the same way, whoever or whatever wrote it: a
+pull request that auto-merges when the repository's required checks pass.
+The `main` branch ruleset requires that for every writer, with no bypass, so
+a red check blocks the maintainer and me alike. The maintainer's pull
+requests are opened by `pulse-triage[bot]` and state what changed, why it
+was needed, which reports or demand-ledger entries it answers, and what
+validation was used, so the record on GitHub is the record of the decision.
+
+Releases run on a train rather than on demand. A release candidate is cut
+from `main` into a `release/vX.Y` branch on a fixed schedule, soaks on the
+opt-in preview channel, takes only backports of regression and security
+fixes while it soaks, and is promoted to stable as the exact candidate
+content. The promotion resolver in the release pipeline enforces the soak
+and the exact-content rule for every dispatcher. The full rules are in
+[RELEASE_PROMOTION_POLICY.md](release-control/v6/internal/RELEASE_PROMOTION_POLICY.md),
+under "Release Train".
+
 ## Authority and responsibility
 
 The automation can operate continuously, but it is not the project owner and