acceptance: record SR-02 watcher cleanup test-green result

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

@@ -0,0 +1,95 @@
+# 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-SR04-portal-aios-visibility-gap.md

@@ -1,168 +0,0 @@
-# V1R4C4 SR-04: Portal AIOS Visibility Gap
-
-Status: visibility gap confirmed; activation decision required
-
-Priority: P1 / user-visible integration
-
-Risk: medium
-
-## User Report
-
-The authenticated user portal entry does not show the expected new AIOS features:
-
-```text
-/portal/me/
-```
-
-## Current Finding
-
-The current baseline is V1R4C3.
-
-V1R4C3 completed several backend and governance capabilities, but the Portal AIOS Integration Merge was explicitly deferred. Therefore, the user portal not showing new AIOS modules is consistent with the current deployment state.
-
-This is not primarily a browser cache issue. It is a merge/deploy visibility gap.
-
-## Evidence
-
-A related branch already contains portal integration work:
-
-```text
-patch/user-portal-me-route-diagnostics-20260709
-```
-
-Observed contents include:
-
-- `active-runtime/app/portal_aios_module_registry.py`
-- `active-runtime/app/portal_aios_navigation.py`
-- `active-runtime/app/portal_aios_dashboard_api.py`
-- `active-runtime/app/portal_aios_module_api.py`
-- `active-runtime/app/portal_integration_api.py`
-- `active-runtime/app/portal_integration_health.py`
-- `active-runtime/app/portal_system_health_adapter.py`
-- `config/portal-aios-frontend-contract.yaml`
-- `acceptance/portal-aios-integration-matrix.yaml`
-
-The branch defines expected portal APIs:
-
-```text
-/portal/me/aios/manifest
-/portal/me/aios/dashboard
-/portal/me/aios/health
-```
-
-It also defines role-visible AIOS modules, including:
-
-- Task Center
-- Operations
-- System Health
-- Search Governance
-- Agent Observability
-- Architecture Changes
-- Architect Research
-- Governance
-
-## Diagnosis
-
-Current state:
-
-```text
-AIOS backend/governance features exist or are staged
-        ↓
-Portal integration branch exists
-        ↓
-Portal integration is not in current baseline/main deployment
-        ↓
-/portal/me/ does not display new modules
-```
-
-Therefore, the missing portal feature is expected until SR-04 is integrated and deployed.
-
-## Required Fix
-
-Activate SR-04 as a controlled portal integration task after reliability guardrails are satisfied, or explicitly approve fast-track portal visibility integration if user-visible delivery is now higher priority.
-
-Minimum integration requirements:
-
-1. Backend route registration for:
-
-```text
-/portal/me/aios/manifest
-/portal/me/aios/dashboard
-/portal/me/aios/health
-```
-
-2. Portal frontend route/menu integration under:
-
-```text
-/portal/me/
-```
-
-3. API proxy configuration from user portal to AIOS backend routes.
-
-4. RBAC mapping:
-
-```text
-user -> task center / authorized modules only
-group_admin -> operations, health, search, agents
-owner -> governance, architecture, owner modules
-```
-
-5. Production deployment refresh.
-
-## Acceptance Criteria
-
-After login, the portal must show the expected modules by role.
-
-### User
-
-- sees authorized user modules;
-- does not see owner-only modules.
-
-### Group admin
-
-- sees task center;
-- sees operations;
-- sees system health;
-- sees search;
-- sees agents.
-
-### Owner
-
-- sees all AIOS modules;
-- sees governance and architecture modules;
-- sees owner gate / approval modules.
-
-### APIs
-
-The following must return valid data after authentication/proxy:
-
-```text
-/portal/me/aios/manifest
-/portal/me/aios/dashboard
-/portal/me/aios/health
-```
-
-## Safety Constraints
-
-- Do not combine SR-04 with SR-01 root-cause repair unless explicitly approved.
-- Do not bypass RBAC checks to make the UI visible.
-- Do not deploy portal integration without confirming auth callback and proxy routes.
-- Do not treat backend route existence as frontend visibility; both must be verified.
-
-## Recommended Path
-
-Because the user has now observed that new functionality is not visible, SR-04 should move from `deferred` to `activation-ready`.
-
-Recommended execution order:
-
-1. Complete or confirm SR-01 reliability guardrails.
-2. Integrate SR-02 watcher cleanup if already green.
-3. Start SR-04 portal visibility integration as P1 user-visible work.
-4. Validate portal modules after login.
-5. Include successful SR-04 in V1R4C4 or a follow-up V1R4C5 if reliability gating requires separation.
-
-## Current Decision Needed
-
-If user-visible portal delivery is required now, approve activation of SR-04.
-
-If reliability remains the only priority for V1R4C4, keep SR-04 deferred and record this report as expected-not-yet-deployed behavior.