Compare commits

..
Author SHA1 Message Date
openclaw 12d09b1dea proposal: start V1R4C4 SR-01 Gitea branch sync fix 2026-07-10 01:42:12 +08:00
2 changed files with 131 additions and 212 deletions
@@ -0,0 +1,131 @@
# V1R4C4 SR-01: Gitea Branch Sync Fix
Status: started
Priority: P0
Risk: medium
Baseline dependency: V1R4C3
## Decision
Start V1R4C4 with SR-01 only.
SR-04 Portal AIOS Integration Merge remains deferred and is not part of this execution scope.
## Background
V1R4C3 completed the immediate branch_sync mitigation by changing branch synchronization to use `git ls-remote` instead of depending on the Gitea branch API pagination path.
That mitigation avoids the user-visible failure path, but it does not fully certify or eliminate the root reliability issue:
```text
bare repository refs
!=
Gitea branch metadata / DB index
!=
Gitea branch API visible state
```
SR-01 exists to validate and fix the root problem category: Gitea branch metadata/index drift from the bare repository state.
## Scope
SR-01 includes:
1. Confirm current branch_sync no longer depends on Gitea API pagination.
2. Validate that Gitea DB branch metadata is consistent with bare repository refs.
3. Add or activate consistency verification around branch metadata drift.
4. Ensure autonomous operations do not continue mutating state when drift is detected.
5. Produce a repeatable acceptance test for future incidents.
SR-01 excludes:
- Portal AIOS Integration Merge.
- Search Gateway real provider binding.
- Broad P1 capability merges.
- Bulk patch merge or branch deletion.
## Required Checks
### Branch sync path
Verify branch_sync source of truth:
```text
git ls-remote / bare repository refs
```
The Gitea branch API must not be the mandatory source of truth for synchronization.
### Gitea consistency path
Verify equality between:
```text
bare repository refs count
Gitea branch live metadata count
Gitea branch API paginated visible count
```
Any mismatch must be treated as reliability drift.
### Safe-mode behavior
When drift is detected:
1. Stop autonomous mutations.
2. Preserve read-only diagnostics.
3. Emit safe-mode marker.
4. Require controlled recovery before mutation resumes.
## Acceptance Criteria
SR-01 is complete when all of the following are true:
1. branch_sync continues to work without Gitea branch API pagination dependency.
2. Gitea branch metadata drift can be detected deterministically.
3. Drift causes autonomous safe mode instead of continued mutation.
4. Recovery procedure includes minimal repair, not default restart.
5. Runtime acceptance passes:
```text
getRuntimeStatus
->
getBaseline
->
createBranch
->
createPatch
```
Expected results:
- runtime status is active;
- baseline reads V1R4C3 or later;
- createBranch returns commit/rev/sync status;
- createPatch returns commit/rev/sync status.
## Execution Order
1. Open SR-01 patch branch.
2. Review V1R4C3 branch_sync behavior.
3. Integrate Gitea branch consistency sentinel and safe-mode gate.
4. Run runtime acceptance.
5. If clean, prepare V1R4C4 reliability baseline proposal.
## Follow-on Gates
SR-02 Watcher State Cleanup may start after SR-01 acceptance is green.
SR-03 Search Gateway Real Provider Binding may start after SR-01 confirms GitOps/Gitea reliability is stable enough for non-P0 work.
SR-04 Portal AIOS Integration Merge remains deferred pending explicit approval.
## Safety Rules
- Do not bulk merge old patches.
- Do not delete remote branches during SR-01 unless the branch consistency sentinel is already deployed and healthy.
- Do not restart Gitea unless process-level failure is proven.
- Do not modify Gitea DB without backup and owner/admin approval.
-212
View File
@@ -1,212 +0,0 @@
# V1R4C5 Acceptance Evidence
Date: 2026-07-11
Status: release candidate evidence in progress
Current active baseline: V1R4C3
V1R4C5 has not been promoted yet.
## Owner Decision
Owner approved continued V1R4C5 work under the following constraints:
```text
允许无 force-push 的分支 reconcile
memory search 保持关闭
先完成 SR-01/SR-02/数据隔离验收
再进入 merge/deploy/tag owner gate
```
## Scope
V1R4C5 release candidate scope:
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.
Explicitly excluded from V1R4C5 activation:
- memory search activation;
- full SR-04 portal production rollout;
- bulk merge of old test/smoke/auth branches;
- force push reconciliation;
- Gitea DB mutation without owner/admin approval.
## Runtime Acceptance Evidence
### Runtime status
Observed:
```json
{
"service": "aios-gitops-model-api",
"status": "active",
"workspace_branch": "patch/v1r4c5-runtime-acceptance-clean-20260711-01"
}
```
### Baseline
Observed:
```json
{
"current_baseline": "V1R4C3",
"previous_baseline": "V1R3C1",
"promoted_by": "openclaw"
}
```
### Clean createBranch acceptance
Branch:
```text
test/v1r4c5-runtime-acceptance-clean-20260711-01
```
Result:
```text
status: ok
commit: 6ae7058
sync: synced
```
### Clean createPatch acceptance
Patch:
```text
patch/v1r4c5-runtime-acceptance-clean-20260711-01
```
Patch id:
```text
patch-1783706123789-f5ca8b69
```
Commit:
```text
ba0391e
```
Result:
```text
synced
```
## SR-01 Evidence
Known accepted evidence:
- Gitea branch consistency sentinel deployed.
- Sentinel reports:
```json
{
"status": "healthy",
"unhealthy_checks": []
}
```
- systemd timer runs every 5 minutes.
- service runs with:
```text
--emit-safe-mode --json
```
- broken symlink issue resolved by replacing the external reliability symlink with workspace-local files.
Required before final promotion:
- confirm latest sentinel report remains healthy after acceptance writes.
## SR-02 Evidence
Known accepted evidence:
```text
11 / 11 tests pass
```
Fix summary:
- stuck command detection reads parsed timestamps through `data.get('ts', 0)`;
- `.md` fixture mtime is aligned with stored stuck timestamp via `os.utime(path, (ts, ts))`;
- behavior is consistent across `.json` and `.md` state formats.
Required before final promotion:
- re-run SR-02 tests on the final integration candidate.
## User Data Isolation Evidence
Implemented controls:
- user data isolation redline;
- memory scope guard;
- provider gate;
- activation gate;
- audit service/timer;
- CI acceptance scripts;
- memory search activation check.
Required safety state:
```text
AIOS_MEMORY_ENABLED=false
```
Required before memory/search activation:
- isolation audit healthy;
- no denied records;
- no invalid records;
- provider filters by scope before ranking;
- provenance required;
- global index disabled;
- activation gate returns allowed;
- explicit owner approval.
V1R4C5 does not approve memory search activation.
## SR-04 Admin Workbench Evidence
Current user-visible gap is confirmed:
- administrator cannot yet see task progress;
- administrator cannot yet see flow/process diagrams;
- SR-04 remains activation-ready but gated.
V1R4C5 scope allows only read-only visibility preparation and acceptance design, not full production rollout.
Required before SR-04 deployment:
- SR-01 green;
- SR-02 green;
- user data isolation gate accepted;
- admin RBAC read-only check green.
## Remaining Required Gates Before Promotion
- [ ] Latest Gitea sentinel report remains healthy.
- [ ] SR-02 watcher tests pass on final candidate.
- [ ] User data isolation acceptance passes.
- [ ] Admin workbench read-only RBAC acceptance passes or remains explicitly deferred.
- [ ] No force-push was used.
- [ ] Memory search remains disabled.
- [ ] Owner approves merge/deploy/tag/promotion.
## Promotion Rule
V1R4C5 may not be promoted until all required gates are green or explicitly deferred with owner approval.