Phase 57: Local server multi-backend permissions concept #1

Correction

This issue is about the local server architecture, not about doing repository work locally.

Phase 57 starts with one central VDR-Suite server in the local or private network. That server manages multiple VDR backends and enforces backend-specific permissions.

Local server target

• Central VDR-Suite server
  • vdr-suite-daemon
  • REST API
  • backend registry
  • local access policy
  • later Web frontend
• VDR backend A
  • managed through VDR-Suite
  • read-write from the VDR-Suite view
• VDR backend B
  • managed through VDR-Suite
  • read-only from the VDR-Suite view

Clients should use VDR-Suite as the central access point. VDR-Suite is the policy gatekeeper.

In scope for Phase 57

• local/private server deployment model
• multiple locally or privately reachable VDR backends
• backend identity
• backend display name and location metadata
• backend access mode: read-only or read-write
• backend capability state
• server-side write blocking for read-only backends
• frontend-ready JSON for backend selection and access state

Out of scope for this issue

• public remote access
• reverse proxy deployment
• VPN or tunnel deployment
• OIDC, LDAP, passkeys or full identity provider integration
• full Web UI implementation
• streaming implementation

Required source review before implementation

Inspect existing code and docs for:

• BackendNode
• BackendRegistry
• BackendRegistryService
• capability model
• existing permission and policy concepts
• read-only recording-action policy
• timer action policy
• SearchTimer write gates
• REST controllers exposing backend or capability state

Do not design Phase 57 from scratch if existing objects already cover part of the model.

Project rules for Phase 57

• Inspect the real repository state before changing code.
• Do not introduce classes before checking existing architecture.
• Do not introduce methods before checking existing interfaces.
• Do not bypass adapter boundaries.
• Keep backend-specific code behind backend adapters.
• Keep domain objects backend-neutral.
• Prefer capability checks before exposing backend-specific behavior.
• Prefer small architecture steps over large rewrites.
• Documentation is part of done for architecture work.
• New documentation must be linked and reachable.
• GitHub Actions must be green before a phase/reset block is complete.

Additional working rules agreed in chat:

• nano only for manual edits.
• no here-doc commands.
• complete files or patch scripts, not partial snippets.
• prefer short Python patch commands for local edits.
• run focused tests before commit.
• show git diff before commit when relevant.
• commit, push, verify git status and CI.

Phase 57 first cut

Phase 57.1:

Backend Identity + Local Server Permission Model

Expected first implementation target:

• central server knows configured backends
• each backend has stable ID, display name, location and adapter config
• each backend has local access mode
• API returns frontend-ready backend access state
• write operations are blocked server-side on read-only backends
• no public remote-access scope is mixed into this cut

Definition of done for this issue

• local server architecture is agreed
• existing backend/capability/policy code is reviewed
• Phase 57.1 implementation boundary is agreed
• public remote-access scope stays out of Phase 57.1
• docs and phase marker tests stay green
• focused VDR/backend tests are selected before code changes