a.tolmachev
201 lines
8.0 KiB
Markdown
201 lines
8.0 KiB
Markdown
# 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" принимал оператор, а не кодовая база.
|
||
|
||
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 обязательным для базового запуска.
|
||
|
||
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
|
||
- pending:
|
||
- external cache backend for managed / enterprise contours
|
||
|
||
## 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.
|