crank/TASKS.md

TASKS

Current

feat/open-core-repo-boundary

Status: in_progress

Goal:

• закрепить техническую границу между public Community repo и private commercial delivery.

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. Убрать из public repo assumptions о размещении private code рядом с Community logic.
4. Подготовить naming и packaging strategy для private repositories.
5. После завершения seams и capability split остановиться на управленческом gate и создать:
   • private repository crank-enterprise
   • private repository crank-cloud Только после этого начинать физическое вынесение commercial code из public repo.

DoD:

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

Verification:

• docs consistency pass;
• release checklist review.

Progress:

• done:
  • gate for creating 2 private 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
• pending:
  • remaining extension seams and packaging split still need to move from planning into concrete public/private manifests

Planned

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 публикуется из public repo;
• 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.