decision: gate SR-04 behind V1R4C4 reliability freeze

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/proposals/V1R4C4-reliability-freeze-before-SR04.md

@@ -0,0 +1,116 @@
+# V1R4C4 Reliability Freeze Before SR-04
+
+Status: accepted
+
+Decision date: 2026-07-10
+
+Current baseline: V1R4C3
+
+## Decision
+
+V1R4C4 will complete reliability freeze before merging Portal AIOS Integration.
+
+SR-04 remains `activation-ready`, but it must not be merged or deployed before SR-01 and SR-02 are complete and accepted.
+
+## Scope Ordering
+
+```text
+SR-01 Gitea Branch Sync Fix
+        ↓
+SR-02 Watcher State Cleanup
+        ↓
+SR-04 Portal AIOS Integration Merge
+```
+
+## SR-01 Gate
+
+SR-01 must complete the P0 reliability work for Gitea branch sync and metadata drift.
+
+Required outcomes:
+
+1. branch_sync remains independent of Gitea branch API pagination.
+2. bare repository refs, Gitea DB branch metadata, and Gitea API visible state are checked for consistency.
+3. branch metadata drift triggers autonomous safe mode.
+4. recovery procedure favors minimal repair over default restart.
+5. runtime acceptance passes.
+
+Acceptance sequence:
+
+```text
+getRuntimeStatus
+    ->
+getBaseline
+    ->
+createBranch
+    ->
+createPatch
+```
+
+## SR-02 Gate
+
+SR-02 must complete watcher state cleanup integration.
+
+Current known test signal:
+
+```text
+11 / 11 tests pass
+```
+
+Required outcomes:
+
+1. stuck command detection reads parsed timestamps correctly.
+2. `.json` command state files are handled correctly.
+3. `.md` command state files are handled correctly.
+4. file mtime semantics are aligned with stored stuck timestamps in tests.
+5. watcher cleanup is integrated behind the reliability assumptions introduced by SR-01.
+
+## SR-04 Status
+
+SR-04 remains:
+
+```text
+activation-ready
+```
+
+But SR-04 is explicitly blocked from merge/deploy until SR-01 and SR-02 gates are green.
+
+SR-04 may continue with planning, diff review, and acceptance design, but may not perform production portal deployment.
+
+## Reason
+
+The user-visible portal feature gap is real, but the system recently experienced a stop-the-line reliability incident involving Gitea branch metadata drift. Reliability freeze must complete first to avoid combining production portal changes with unresolved GitOps/Gitea consistency risk.
+
+## Allowed During Freeze
+
+Allowed:
+
+- SR-04 planning;
+- SR-04 diff review;
+- frontend/backend contract review;
+- RBAC acceptance design;
+- non-production validation;
+- documentation updates.
+
+Not allowed before SR-01/SR-02 acceptance:
+
+- merging SR-04 to main;
+- deploying SR-04 to production;
+- bypassing RBAC to expose modules;
+- combining portal integration with Gitea DB repair;
+- bulk merging old portal branches.
+
+## SR-04 Release Gate
+
+SR-04 may enter merge/deploy only after:
+
+1. SR-01 acceptance is green.
+2. SR-02 acceptance is green.
+3. GitOps runtime acceptance is green.
+4. Gitea consistency sentinel is deployed or explicitly deferred with owner approval.
+5. Portal RBAC acceptance plan is approved.
+
+## Final Rule
+
+V1R4C4 is reliability-first.
+
+Portal AIOS Integration remains prepared but gated until reliability freeze is complete.