release: record owner approval to continue V1R4C5 gates

docs/proposals/V1R4C4-SR02-watcher-state-cleanup-acceptance.md

@@ -1,95 +0,0 @@
-# V1R4C4 SR-02: Watcher State Cleanup Acceptance
-
-Status: implementation test green
-
-Priority: P1a
-
-Risk: low
-
-Baseline dependency: V1R4C3; should be integrated after SR-01 reliability acceptance or behind SR-01 gate.
-
-## Summary
-
-SR-02 watcher/stuck command cleanup now has a passing test signal:
-
-```text
-11 / 11 tests pass
-```
-
-The fix validates stuck command detection across both `.json` and `.md` command state formats.
-
-## Fix Summary
-
-### 1. Stuck command detection logic
-
-The controller logic in `autonomous_controller.py` was corrected.
-
-Previous failure mode:
-
-- parsed JSON was accessed through `.string('ts')`, which is empty for parsed JSON;
-- stuck threshold comparison against `stale_start` was incorrect;
-- stale/stuck state could be missed even when command metadata was old enough.
-
-Correct behavior:
-
-```python
-ts = data.get('ts', 0)
-```
-
-The command timestamp is now read from parsed data and compared using the correct time-based stale/stuck threshold.
-
-### 2. Test fixture mtime alignment
-
-The test fixture now sets the filesystem modification time of generated `.md` files to match the stored stuck timestamp.
-
-This is required because stuck detection uses both command metadata and file age semantics.
-
-Corrective test fixture behavior:
-
-```python
-os.utime(path, (ts, ts))
-```
-
-This ensures `.md` command files with a timestamp older than the stuck threshold are actually visible to `h_stuck()` as stuck.
-
-## Coverage
-
-Validated formats:
-
-- `.json` command state files;
-- `.md` command state files.
-
-Validated behavior:
-
-- old command timestamps are recognized as stuck;
-- current/non-stale command timestamps are not falsely marked stuck;
-- `.md` fixtures behave consistently with stored `ts` metadata;
-- detection behavior is consistent across file formats.
-
-## Acceptance Result
-
-```text
-all tests: pass
-count: 11
-```
-
-## Integration Guidance
-
-SR-02 is eligible for V1R4C4 integration after SR-01 confirms GitOps/Gitea reliability guardrails are stable.
-
-SR-02 must not bypass SR-01 because watcher cleanup changes autonomous controller behavior. It should be integrated behind the same safe-mode assumptions introduced by SR-01.
-
-## Remaining Checks Before Merge
-
-1. Confirm the exact implementation commit containing `autonomous_controller.py` and test fixture changes.
-2. Run SR-01 runtime acceptance first.
-3. Re-run the SR-02 test suite after rebasing/integrating with V1R4C4 reliability branch.
-4. Run global runtime acceptance:
-
-```text
-getRuntimeStatus -> getBaseline -> createBranch -> createPatch
-```
-
-## Decision
-
-Treat SR-02 as test-green and ready for controlled integration, not as independently deployable before SR-01.

docs/releases/V1R4C5-owner-approval.md

@@ -0,0 +1,84 @@
+# V1R4C5 Owner Approval
+
+Date: 2026-07-11
+
+Status: approved to continue under controlled gates
+
+## Owner Decision
+
+Approved to continue under the V1R4C5 scope:
+
+```text
+允许无 force-push 的分支 reconcile
+memory search 保持关闭
+先完成 SR-01/SR-02/数据隔离验收
+再进入 merge/deploy/tag owner gate
+```
+
+## Approved Scope
+
+V1R4C5 may continue with:
+
+1. SR-01 Gitea reliability and branch consistency guardrails.
+2. SR-02 watcher/stuck command cleanup.
+3. User Data Isolation redline and enforcement gates.
+4. SR-04 admin workbench read-only visibility preparation only.
+
+## Explicit Constraints
+
+### No force push
+
+The release process must not use:
+
+```text
+git push --force
+```
+
+Allowed reconciliation:
+
+```text
+fetch remote
+merge or rebase without rewriting remote history
+resolve conflicts normally
+push fast-forward or normal merge result
+```
+
+### Memory search remains disabled
+
+Memory search must remain off until:
+
+1. isolation audit is healthy;
+2. provider gate is active;
+3. activation gate returns allowed;
+4. owner explicitly approves activation.
+
+### SR-04 remains limited
+
+SR-04 may proceed only as read-only/admin visibility preparation until reliability and isolation gates are green.
+
+No full portal production rollout is approved by this decision.
+
+## Required Acceptance Before Merge/Deploy/Tag
+
+```text
+getRuntimeStatus
+getBaseline
+createBranch
+createPatch
+Gitea sentinel healthy
+SR-02 tests pass
+user-data-isolation acceptance pass
+admin workbench RBAC read-only check
+```
+
+## Owner Gate Still Required Later
+
+This approval allows continued implementation and reconciliation only.
+
+Separate owner approval is still required for:
+
+- merge to main;
+- production deployment;
+- V1R4C5 tag creation;
+- V1R4C5 baseline promotion;
+- memory search activation.

patches/v1r4c5-release-candidate-20260711.json

@@ -0,0 +1,9 @@
+{
+  "id": "patch-1783705738676-fd428165",
+  "patch_name": "v1r4c5-release-candidate-20260711",
+  "branch": "release/v1r4c5-c5-20260711",
+  "risk": "high",
+  "description": "V1R4C5 release candidate: integrate reliability, watcher stability, user data isolation gates, and controlled admin workbench visibility preparation.",
+  "created_by": "chatgpt-gitops-bot",
+  "created_at": "2026-07-10T17:48:58Z"
+}