АРХ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: managedBy split Operational Core

scripts/bootstrap_nodedc_platform_plan.py

@@ -899,7 +899,9 @@ Plane должен оставаться самостоятельным прод
 
 Практически проверено: корпоративные назначения из Launcher доходят до Operational Core, public-пользователь может создать workspace после выдачи доступа, а прямой доступ к сервису проходит через NODE.DC SSO. Safari-only падение workspace зафиксировано как отдельный deferred debug, потому что Chrome/Chromium flow работает и проблема не должна блокировать платформенную обвязку.
 
-Открытая развилка: нужно формально добавить managedBy=launcher/managedBy=tasker или эквивалентный флаг в mapping workspace, чтобы интерфейс Task Manager понимал, когда скрывать собственное управление пользователями, а когда оставлять автономный SaaS-режим.
+Развилка managedBy закрыта в NDCPLATFORM-8: Launcher хранит managedBy в Tasker workspace binding, отдает workspacePolicy/workspaces через internal access-check, а Tasker резолвит policy по workspace_slug. Для managedBy=launcher интерфейс и backend Tasker блокируют конфликтующее управление участниками/инвайтами; для managedBy=tasker штатные Tasker users/invites остаются частью standalone/public режима.
+
+Важная runtime-оговорка: в standalone или неверно поднятом local runtime без PLANE_NODEDC_* env Tasker продолжает работать в безопасном standalone-режиме managedBy=tasker. Для NODE.DC enforcement контейнеры должны запускаться с plane.env или эквивалентными env.
 """,
             ),
             checker(
@@ -909,8 +911,8 @@ Plane должен оставаться самостоятельным прод
                     {"text": "Сохранить автономность Task Manager как standalone-продукта.", "checked": True},
                     {"text": "Зафиксировать managedBy=launcher для enterprise workspace.", "checked": True},
                     {"text": "Зафиксировать managedBy=tasker для standalone/public workspace.", "checked": True},
-                    "Скрыть или readonly-заблокировать Task Manager users/invites для managedBy=launcher.",
-                    "Оставить Task Manager users/invites включенными для managedBy=tasker.",
+                    {"text": "Скрыть или readonly-заблокировать Task Manager users/invites для managedBy=launcher.", "checked": True},
+                    {"text": "Оставить Task Manager users/invites включенными для managedBy=tasker.", "checked": True},
                     "Очистить оставшиеся demo users/seed data без удаления живых связей.",
                     "Оформить Safari-only workspace crash как отдельный deferred debug.",
                 ],
@@ -1139,7 +1141,7 @@ Launcher: добавлены admin routes для project memberships, control-pl
                 "tasker-provisioning",
                 "Этап 5. Stale assignees cleanup после снятия пользователей",
                 """
-Статус: реализовано в рабочем дереве, ожидает финальную проверку и коммит после подтверждения.
+Статус: реализовано и закоммичено.
 
 После удаления, блокировки или снятия пользователя из workspace/project Tasker не должен продолжать показывать его исполнителем в карточках и группировках. Последняя локальная правка удаляет IssueAssignee на membership remove и фильтрует assignee arrays только по активным workspace/project membership.
 """,
@@ -1165,14 +1167,14 @@ Launcher: добавлены admin routes для project memberships, control-pl
 
 Проверка БД 2026-05-09: запрос по активным IssueAssignee без active WorkspaceMember/ProjectMember вернул 0 записей. Значит текущий runtime не содержит реально stale assignee links после последней очистки.
 
-Рабочее дерево Task Manager остается dirty: этот этап еще не закоммичен и требует финальной проверки перед переводом карточного пункта в полностью закрытое состояние.
+Этап закоммичен отдельным изменением Operational Core. Глобальный frontend typecheck остается не полностью чистым из-за ранее существующих unrelated ошибок Plane fork, поэтому следующий регресс лучше проверять точечно по issue list/kanban после пересборки web runtime.
 """,
             ),
             text_block(
                 "tasker-provisioning",
                 "Этап 6. Source-of-truth split managedBy",
                 """
-Статус: следующий критический этап.
+Статус: реализовано локально, проверено на policy path, готово к browser acceptance.
 
 Нужно формально закрепить источник управления для workspace. managedBy=launcher означает enterprise workspace: пользователи, инвайты и базовые роли идут из Launcher, а Tasker не должен давать конфликтующее управление. managedBy=tasker означает standalone/public workspace: штатные Tasker механизмы пользователей, инвайтов и ролей остаются включенными.
 """,
@@ -1181,15 +1183,28 @@ Launcher: добавлены admin routes для project memberships, control-pl
                 "tasker-provisioning6",
                 "Чекер этапа 6. Source-of-truth split managedBy",
                 [
-                    "Добавить managedBy в Launcher Tasker workspace binding.",
-                    "Возвращать managedBy/workspacePolicy из Launcher internal access-check.",
-                    "Передавать managedBy в Tasker adapter responses или workspace policy resolver.",
-                    "Скрыть или readonly-заблокировать Tasker users/invites для managedBy=launcher.",
-                    "Оставить Tasker users/invites включенными для managedBy=tasker.",
+                    {"text": "Добавить managedBy в Launcher Tasker workspace binding.", "checked": True},
+                    {"text": "Возвращать managedBy/workspacePolicy из Launcher internal access-check.", "checked": True},
+                    {"text": "Передавать managedBy в Tasker adapter responses или workspace policy resolver.", "checked": True},
+                    {"text": "Скрыть или readonly-заблокировать Tasker users/invites для managedBy=launcher.", "checked": True},
+                    {"text": "Оставить Tasker users/invites включенными для managedBy=tasker.", "checked": True},
                     "Проверить enterprise client admin и public self-service user flows отдельно.",
-                    "Зафиксировать правила в NDCPLATFORM-4 и NDCPLATFORM-10 после реализации.",
+                    {"text": "Зафиксировать правила в NDCPLATFORM-4 и NDCPLATFORM-10 после реализации.", "checked": True},
                 ],
             ),
+            text_block(
+                "tasker-provisioning",
+                "Реализация этапа 6",
+                """
+Launcher: Tasker workspace binding получил managedBy=launcher|tasker. Legacy workspace binding по умолчанию нормализуется как launcher-managed, а internal access-check возвращает managedBy/defaultManagedBy/workspaces вместе с canCreateWorkspace. Для обычного enterprise-пользователя с launcher-managed workspace создание workspace запрещается, root/superadmin сохраняет право создавать новые workspace.
+
+Tasker backend: workspace policy resolver принимает workspace_slug и возвращает managed_by/default_managed_by/workspaces. Workspace members, project members и workspace invites блокируют create/update/delete/leave операции для launcher-managed workspace с ошибкой nodedc_launcher_managed_workspace. Без NODE.DC env Operational Core остается standalone и считает workspace tasker-managed.
+
+Tasker frontend: create-workspace flow понимает новые поля policy, settings modal скрывает members tab для launcher-managed workspace, а страницы workspace/project members показывают readonly-сообщение о том, что участниками управляет Launcher. Для managedBy=tasker штатные Tasker users/invites UI не отключаются.
+
+Проверки 2026-05-09: Launcher node --check прошел для server/dev-server.mjs и server/control-plane-store.mjs; Tasker python compile прошел для policy/member/invite views; Launcher access-check для support@dctouch.ru вернул managedBy=launcher и canCreateWorkspace=false; Tasker policy resolver в API container с NODE.DC env вернул managed_by=launcher и is_launcher_managed=True для workspace nodedc. pnpm --filter web check:types все еще падает на ранее существующих unrelated TypeScript ошибках Plane fork, новых ошибок в измененных файлах не выявлено.
+""",
+            ),
         ],
     },
     {