crank/TASKS.md

# TASKS

## Current

### `feat/optional-cache-layer`

Status: in_progress

Goal:
- добавить в продукт optional cache/coordination layer с `Valkey/Redis` backend без обязательной зависимости от него.

Main code areas:
- `crates/crank-core`
- `crates/crank-runtime`
- `apps/admin-api`
- `apps/mcp-server`
- `deploy/community/*`
- `docs/runtime-config.md`
- `docs/product-editions.md`
- `docs/commercial-boundaries.md`

Implementation slices:
1. Зафиксировать public cache contracts:
   - response cache
   - rate-limit store
   - token replay / one-time token store
   - ephemeral coordination state
2. Подготовить Community fallback path:
   - без `Valkey/Redis` все должно работать
   - degraded mode documented explicitly
3. Добавить optional `Valkey` service в Community deployment manifests как рекомендованный, но не обязательный runtime component.
4. Подготовить `Valkey/Redis` backend для:
   - managed Cloud default
   - enterprise optional cluster-aware deployment
5. Протянуть capability/config model так, чтобы решение "использовать или нет внешний cache" принимал оператор, а не кодовая база.
6. Зафиксировать safe cache boundaries:
   - platform cache и response cache не смешиваются;
   - ключи response cache изолируются минимум по `workspace + agent + operation + request fingerprint`;
   - ключи coordination state изолируются минимум по `workspace + agent + cache scope`;
   - при отсутствии внешнего cache все эти контуры продолжают работать через in-memory fallback.

DoD:
- без `Valkey/Redis` Community и self-hosted deployment остаются рабочими;
- с `Valkey/Redis` платформа умеет снижать runtime/load pressure и хранить ephemeral coordination state;
- `Cloud` может использовать shared cache layer по умолчанию;
- `Enterprise` может подключать cache layer на своей инфраструктуре, включая кластерный вариант;
- runtime/docs/manifests не делают cache обязательным для базового запуска.
- cache boundaries и key namespaces документированы так, чтобы разные агенты и рабочие области не пересекались друг с другом.

Verification:
- targeted runtime/admin/mcp tests for cache contracts and fallback mode;
- deploy manifest validation.

Progress:
- done:
  - product/docs/runtime plan already define cache layer as optional and edition-aware
  - public cache contracts and runtime cache config now exist in `crank-core` / `crank-runtime`
  - Community fallback in-memory implementations now exist for response cache, rate-limit state, replay guard, and coordination state
  - Community deployment manifest now includes optional `valkey` profile and cache env wiring without making cache mandatory
  - shared `Valkey/Redis` backend layer now exists in `crank-runtime` with config-driven store factory for managed / enterprise contours
  - admin-api and mcp-server ingress rate limiting now use shared external cache state when `CRANK_CACHE_BACKEND` is `valkey` or `redis`
  - `ExecutionConfig.response_cache` is now part of the public operation model, and `admin-api` validates the safe Community baseline: only explicit `REST GET` operations without `auth_profile_ref`
  - cache boundary and namespace rules are now documented for `platform / coordination cache` versus `response cache`
  - runtime executor now performs actual response cache reads/writes for eligible `REST GET` operations with keys isolated by `workspace + agent + operation + request fingerprint`
  - mcp-server published tool catalog now uses shared coordination snapshots across instances, while preserving the same `workspace + agent` isolation model
- pending:
  - preserve the same isolation model while extending response cache beyond the first `REST GET` hot path
  - wire replay guard into the first real token or nonce flow once commercial machine-token issuance stops being a `Community` stub
  - wire coordination state into additional runtime or transport paths beyond the shared published catalog snapshot

## Planned

### `feat/open-core-repo-boundary`

Status: in_progress

Goal:
- закрепить техническую границу между `crank-community`, `crank-enterprise` и `crank-cloud`.

Main code areas:
- `docs/commercial-boundaries.md`
- `docs/module-decomposition.md`
- `docs/development-rules.md`
- `docs/implementation-plan.md`
- release scripts / Docker manifests / future packaging files

Implementation slices:
1. Определить extension seams в public code.
2. Подготовить отдельные delivery manifests для Community.
3. Убрать из Community repo assumptions о размещении private code рядом с Community logic.
4. Подготовить naming и packaging strategy для private repositories.
5. После завершения seams и capability split остановиться на управленческом gate и создать:
   - public repository `crank-community`
   - private repository `crank-enterprise`
   - private repository `crank-cloud`
   Только после этого начинать физическое вынесение commercial code из текущего monorepo.

DoD:
- можно объяснить, что именно публикуется как OSS, а что уходит в private delivery;
- Community release path отделен от commercial release path;
- документация не ссылается на удаленные review files.
- момент создания `3` целевых repositories зафиксирован в плане как отдельный обязательный шаг, а не подразумевается неявно.

Verification:
- docs consistency pass;
- release checklist review.

Progress:
- done:
  - gate for creating `3` target repositories is already documented before any physical commercial split
  - canonical Community deployment manifest and env template now live under `deploy/community/*`, and public deploy uses that manifest instead of the root compose file
  - CI, README, runtime/deploy smoke docs now point to `deploy/community/*` as the Community delivery source of truth
  - separate `Community` release checklist now exists and explicitly forbids treating future `Enterprise/Cloud` delivery as just another env on the same public manifest
  - explicit repository split map now defines what goes to `crank-community`, `crank-enterprise`, and `crank-cloud`
  - `Community` is now fixed as `REST-only` in product docs, capability model, backend validation, demo seed, and UI protocol expectations
- pending:
  - remaining extension seams and packaging split still need to move from planning into concrete `crank-community` / `crank-enterprise` / `crank-cloud` manifests
  - next management gate is to actually create the `3` target repositories before physical split starts

### `feat/enterprise-access-governance`

Status: ready

Goal:
- реализовать enterprise access layer вне Community scope.

Main code areas:
- private `enterprise` services and crates
- public contracts in:
  - `docs/admin-api.md`
  - `docs/agent-auth-model.md`
  - `docs/product-editions.md`

Implementation slices:
1. `SSO`
2. `2FA`
3. extended `RBAC`
4. `audit log`
5. enterprise admin flows in UI through capability gating

DoD:
- governance features не живут как полумеры в Community;
- enterprise access model согласован с public contracts.

### `feat/cloud-metering-control-plane`

Status: ready

Goal:
- подготовить hosted-редакцию как отдельный продуктовый контур.

Main code areas:
- private cloud services
- usage/metering integration points
- `docs/product-editions.md`
- `docs/commercial-boundaries.md`

Implementation slices:
1. usage metering by workspace / agent / token;
2. billing integration;
3. hosted tenant controls;
4. cloud operational tooling.

DoD:
- Cloud edition не зависит от ручного учета usage;
- hosted product surface согласован с feature matrix.

### `feat/release-protection-distribution`

Status: ready

Goal:
- подготовить безопасную поставку Community и коммерческих редакций.

Main code areas:
- CI workflows
- Dockerfiles
- deployment manifests
- release docs

Implementation slices:
1. public GitHub release flow for Community;
2. private registry flow for Enterprise;
3. signed artifacts and provenance;
4. release checklist for edition-specific packaging.

DoD:
- Community публикуется из `crank-community`;
- Enterprise и Cloud используют private delivery path;
- коммерческий код не требуется публиковать в open source ради поставки.

### `feat/live-authenticated-staging-entry`

Status: ready

Goal:
- держать реальный staging/demo контур в состоянии, пригодном для демонстрации и регрессии.

Main code areas:
- `docs/demo-runbook.md`
- `docs/deploy-and-staging-smoke.md`
- `docs/authenticated-staging-pass.md`
- deployment workflows

Implementation slices:
1. актуализировать demo user flow;
2. прогнать authenticated staging pass;
3. зафиксировать regressions и manual checks;
4. синхронизировать deploy docs с реальным окружением.

DoD:
- staging validation не зависит от локальных фикстур;
- documentation matches deployed behavior;
- demo flow reproducible on real environment.