docs: design Go management backend

[FenjuFu]

Summary

The current HTTP local agent does not cover the complete resource editing, review, publication and team-data lifecycle available through Git. Add the two design documents requested by #341 for a Go management backend, covering Git-free onboarding, multiple projects, enterprise identity, versioned synchronization and reviewed publication.

This is the issue's design-only first phase. It adds no backend service, Web console, CLI behavior change or usage-guide update.

Type of Change

• Documentation only

Test Plan

• Upstream CI passed on contribution head c130ab2d8d8a95ee6e74b4f7d4dc1c16a14e4428, including all four Node 20/22 Ubuntu/macOS matrices and Build with OpenCode recall E2E. Tencent CodeCC also passed.
• Fork CI run 34448480375 passed: Node 20/22 on Ubuntu/macOS, including type checks and the full unit suite with coverage. The Node 20 Ubuntu log reports 213 files and 2,954 tests passed.
• Build passed, including the existing OpenCode recall E2E test (1 test passed).
• Bilingual validation: 12 corresponding sections, 20 capability mappings, 34 API paths, 8 CLI command mappings, 6 phases and 13 acceptance criteria.
• JSON examples and state machines match; relative links and cited source-code paths resolve.
• Local build, CLI version check and git diff --check passed.

The validation commit 28e85c3f080332c2abe840bddb4998342c8dcfdd derives from PR head c130ab2d8d8a95ee6e74b4f7d4dc1c16a14e4428. Only the existing CI push branch filter differs; source, tests, jobs and permissions are unchanged.

The separate GitHub-provider full-surface E2E job was skipped in both the fork and upstream runs; it is not included in the passing E2E coverage above. The fork has no configured fixture repository variable.

Related Issues

Refs #341

Notes for Reviewers

The design separates role/project resource selection from authorization and the current ClawPro protocol from the proposed API. It defines exact-digest review, conditional/idempotent writes, atomic cross-project publication, ownership-safe cleanup, revocation/offline bounds and staged acceptance.

Downloaded and applied revisions are distinct. A durable per-target journal and visible PARTIAL state cover interrupted application. Client-generated operation IDs support reconciliation beyond response-cache expiry; telemetry has a separate deduplication retention contract. The bilingual examples and acceptance criteria include these rules.

Storage, policy and operational limits remain proposed decisions for maintainer review. The documented API and backend acceptance scenarios are design requirements, not implemented backend tests.

[jeff-r2026]

Thanks for the detailed design and the bilingual write-up. This is a large change of scope (Git-free onboarding, multi-project, identity, versioned sync, reviewed publication, and recovery/idempotency), so we need a careful review and that will take more time than a typical docs PR.