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
• pending:
  • preserve the same isolation model while extending response cache beyond the first REST GET hot path
  • wire replay guard / coordination state into additional concrete runtime and transport paths

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.