# Remote Access Platform

Production-oriented Secure Access Fabric platform.

The project started as an RDP proxy, but the target architecture is broader:

- multi-tenant control plane
- direct realtime data plane
- service adapters for RDP now and VNC/SSH/VPN/file/video later
- native Access Clients
- future secure mesh / node-agent / updater / connector model
- shared Fabric Service Channel runtime for working service data so VPN,
  Remote Workspace, video, file, and future services request a common channel
  instead of reimplementing transport, routing, and failover

RDP is the first proven service baseline. RDP work is currently paused by
product decision while the project moves to the Secure Access Fabric
platform-core foundation: clusters, node enrollment, node-agent identity, role
assignments, and platform administration.

## Current Baseline

- Backend: Go control plane with PostgreSQL as source of truth and Redis for
  live coordination/routing only.
- Worker: active C++ RDP Adapter worker based on FreeRDP.
- Windows client: C# / WPF native Access Client.
- Data plane: direct worker WSS for realtime RDP when available, backend
  WebSocket gateway retained as fallback/debug.
- Current test Docker host: `docker-test` / `192.168.200.61`.
- Current test Docker deployment for Stage 5.2 proof:
  `rap-backend-smoke:stage5-2-download` and
  `rap-rdp-worker:stage5-2-download`.

See the current audit and baseline matrix before starting new work:

- `docs/audits/PROJECT_AUDIT_2026-04-26.md`
- `docs/audits/CURRENT_BASELINE_MATRIX.md`

## Proven RDP Capabilities

- real RDP connect through worker
- active/detach/reattach/takeover/terminate lifecycle
- takeover without remote session recreation
- worker-death/orphan-active-session recovery
- direct worker WSS data plane
- binary direct render frames
- backend gateway JSON/base64 fallback
- Windows client rendering and input
- text clipboard with policy enforcement
- client-to-server file upload into controlled worker storage
- restricted transfer-drive visibility through `RAP_Transfers`, runtime-proven
- server-to-client file download implementation through
  `RAP_Transfers\ToClient`; core direct/fallback data path is runtime-proven,
  lifecycle blocking is runtime-proven, and manual desktop UI acceptance remains
  pending

## Repository Structure

- `backend/` - Go control plane
- `workers/rdp-worker/` - active C++ RDP Adapter worker
- `workers/rdp-service-csharp/` - inactive research scaffold, not current runtime
- `clients/windows/` - Windows native Access Client
- `clients/android/` - Android VPN client
- `docs/architecture/` - target and staged architecture documents
- `docs/codex/` - current Codex status and next-step prompts
- `docs/audits/` - current audits and baseline matrices
- `scripts/` - smoke and helper scripts
- `deploy/` - deployment assets
- `web-admin/` - future/admin UI area

### Быстрый локальный билд Android APK после апдейта

```powershell
pwsh -ExecutionPolicy Bypass -File scripts\prepare-local-build-workstation.ps1 -SetEnvironment
pwsh -ExecutionPolicy Bypass -File scripts\android\prepare-android-build-environment.ps1 -SetEnvironment
pwsh -ExecutionPolicy Bypass -File scripts\android\rebuild-and-publish-android-apk.ps1
```

Для быстрого release (сборка + публикация + опциональная проверка манифеста):

```powershell
pwsh -ExecutionPolicy Bypass -File scripts\android\release-android-apk.ps1 `
  -InstallMissing `
  -PublishToTestDockerDownloads
```

Для одного шага «всё-в-одном»:

```powershell
pwsh -ExecutionPolicy Bypass -File scripts\android\fast-release-android-apk.ps1
```

Или через `.cmd` (Windows, двойной клик/ссылкой):

```text
scripts\android\fast-release-android-apk.cmd
```

После обновления Android-клиента выполните на машине сборки:

```powershell
pwsh -ExecutionPolicy Bypass -File scripts\android\rebuild-and-publish-android-apk.ps1 -InstallMissing -BuildType release
```

Скрипт сам проверит окружение, при необходимости поставит недостающие компоненты
SDK (флаг `-InstallMissing`) и соберет APK. После этого артефакт сразу окажется в
`web-admin/deploy/html/downloads` для скачивания из панели.

Важно по процессу релиза: каждый новый номер версии должен проходить полный цикл
`сборка → публикация → проверка manifest` и всегда попадать в `latest-release` +
`releases/<version>` на стороне дистрибутива, чтобы узлы и пользователи всегда
обновлялись с актуального билда.

## Read Order

1. `CODEX_CONTEXT.md`
2. `docs/audits/PROJECT_AUDIT_2026-04-26.md`
3. `docs/audits/CURRENT_BASELINE_MATRIX.md`
4. `docs/codex/CURRENT_STATUS.md`
5. `docs/codex/ARCHITECTURE_GUARDRAILS.md`
6. `docs/architecture/RDP_ADAPTER_RUNTIME.md`
7. `docs/architecture/DATA_PLANE_V1.md`
8. `docs/architecture/FABRIC_SERVICE_CHANNEL_RUNTIME.md`
9. `docs/architecture/CLUSTER_NODE_ADMIN_FOUNDATION.md`
10. `docs/codex/NEXT_STEP_PROMPT.md`

Do not use `docs/_legacy_v1` for implementation decisions. Legacy files are
historical reference only.

## Current Next Step

RDP work is paused. Platform-core stages C1-C9 are implemented and verified:
cluster/node model foundation, node enrollment hardening, native
`rap-node-agent` MVP, Platform Admin Console MVP, service workload supervision
contract, mesh control-plane preparation, Mesh MVP skeleton, multi-cluster
hardening, and organization admin foundation.

Planning baseline:

- `docs/architecture/CLUSTER_NODE_ADMIN_FOUNDATION.md`
- `artifacts/c1-cluster-node-foundation-report.md`
- `artifacts/c2-node-enrollment-hardening-report.md`
- `artifacts/c3-rap-node-agent-mvp-report.md`
- `artifacts/c4-platform-admin-console-report.md`
- `artifacts/c5-service-workload-supervision-contract-report.md`
- `artifacts/c6-mesh-control-plane-preparation-report.md`
- `artifacts/c7-mesh-mvp-skeleton-report.md`
- `artifacts/c8-multi-cluster-hardening-report.md`
- `artifacts/c9-organization-admin-foundation-report.md`

Stage C1 implemented the backend foundation for:

- explicit clusters
- cluster memberships
- node join tokens with hashed tokens only
- node join requests
- node identity/certificate metadata
- node role assignments
- node heartbeat/latest health
- cluster audit events
- safe migration/backfill of existing node data into a default cluster

Recommended next step is a decision between platform auth hardening for
web-admin, node PKI hardening, node-agent runtime hardening, mesh runtime DP-0,
or returning to paused RDP work.

Do not start all continuation paths at once.