Переносимый комплект: подготовить развёртывание сервиса на аккаунте коллеги из ИТ #13

New issue

Open

opened 2026-11-09 17:54:44 +00:00 by valalav · 2 comments

valalav commented 2026-11-09 17:54:44 +00:00

Owner

Copy link

🤖 Codex, /root · 09.11.2026

Цель

После доработки общий сервис можно воспроизводимо развернуть под согласованным Google-аккаунтом коллеги из ИТ, не передавая личный пароль, сессию или OAuth-разрешения текущего владельца.

Работы

1. Вынести зависимые от аккаунта параметры из исходников: ID проекта и таблиц/реестра, deployment URL, ключи, разрешённые роли. Документировать обязательные параметры, место хранения и проверку полноты; в git — только безопасный пример. Чувствительные значения не показывать в диагностике.
2. Подготовить чистые шаблоны без персональных ответов и установку/инициализацию в новом проекте: собственная привязка данных, уникальные новые ключи, безопасный повторный запуск без потери ответов. Предусмотреть экспорт/импорт несекретной конфигурации, если он нужен выбранной архитектуре; рабочие ответы переносить только отдельным разрешённым шагом.
3. Написать короткую инструкцию владельцу ИТ с актуальными скриншотами: подготовка аккаунта и ресурсов, загрузка кода, ввод настроек, однократная авторизация владельца, развёртывание с нужным режимом исполнения, проверка. Технические детали — в приложении. Не обещать автоматический перенос OAuth, старого deployment URL или доступность анонимного режима при запрете домена.
4. Проверить актуальные правила Google для личного/Workspace-аккаунта, междоменных ограничений и владения проектом. Основной воспроизводимый путь — новое развёртывание под целевым владельцем; смену владельца без проверки не считать достаточной.
5. Составить паспорт передачи: версия кода, структура данных, параметры без секретов, список ресурсов и ответственных ролей, процедура резервного копирования/восстановления, ручные действия нового владельца.

Приёмка

• Из чистого проекта по инструкции воспроизводится учебный экземпляр без правки исходного кода под личный аккаунт.
• Повторная установка не стирает ответы и не перепривязывает сервис к таблице прежнего владельца; отсутствующие/чужие параметры дают понятную ошибку.
• Инструкция различает разовую авторизацию владельца и работу организатора/зрителя; явно перечисляет параметры, изменяющиеся при переносе, включая URL для Яндекс webhook и экранов.
• Исходники, шаблоны, примеры настроек и паспорт не содержат реальных секретов/ответов. Есть отчёт о прогоне и перечень ещё не выполненных шагов на целевом аккаунте.
• Фактический перенос на аккаунт ИТ и переключение пользователей выполняются в последующей задаче пилота.

Зависит от: #12.

Порядок работы и ограничения

Постановка по поручению владельца от 09.11.2026. Сейчас разрешено открыть задачи; эта запись не является поручением автоматически начать реализацию, развернуть публичный сервис или перенести данные. Исполнителя назначает координатор отдельно.

Перед реализацией прочитать AGENTS.md, актуальный main, последние комментарии и результаты #7–#11. Не перехватывать чужие doing-задачи. Выбранный и принятый исходный SHA записать в отчёте: вариант Terra 097ca49 — кандидат, а не автоматически принятый main. Отдельный worktree и ветка codex/, коммиты со ссылкой на свою задачу; без самовольного merge.

Инструменты: Forgejo connector либо штатный LAN API из hub (токен не выводить); rg для кода; существующие Node-тесты и новые содержательные проверки; Google/Яндекс через доступный профильный инструмент или браузер. Проверить возможности инструмента, не выдумывать API. Зависимости устанавливать только при необходимости. Локальные тесты, реальный Google и настоящий Яндекс→Google отражать отдельными статусами. При отсутствии доступа фиксировать точный непройденный шаг; моки и HTTP 200 не являются приёмкой интеграции.

Боевой стенд КБР, общий Google-шаблон, чужие worktree, доступы и реальные ответы не менять. Разработка и проверки — на отдельных учебных ресурсах; публикация и миграция выполняются отдельным явно согласованным действием. В репозитории и отчётах не размещать токены, OAuth-данные, персональные ответы и действующие секреты; для примеров использовать только учебные значения.

{
  "depends_on": [
    12
  ],
  "write_paths": [
    "src/",
    "tests/",
    "tools/deployment/",
    "docs/deployment/"
  ],
  "files_exist": [
    "docs/deployment/README.md"
  ],
  "commit_ref": "#13"
}

🤖 **Codex, /root** · 09.11.2026 ### Цель После доработки общий сервис можно воспроизводимо развернуть под согласованным Google-аккаунтом коллеги из ИТ, не передавая личный пароль, сессию или OAuth-разрешения текущего владельца. ### Работы 1. Вынести зависимые от аккаунта параметры из исходников: ID проекта и таблиц/реестра, deployment URL, ключи, разрешённые роли. Документировать обязательные параметры, место хранения и проверку полноты; в git — только безопасный пример. Чувствительные значения не показывать в диагностике. 2. Подготовить чистые шаблоны без персональных ответов и установку/инициализацию в новом проекте: собственная привязка данных, уникальные новые ключи, безопасный повторный запуск без потери ответов. Предусмотреть экспорт/импорт несекретной конфигурации, если он нужен выбранной архитектуре; рабочие ответы переносить только отдельным разрешённым шагом. 3. Написать короткую инструкцию владельцу ИТ с актуальными скриншотами: подготовка аккаунта и ресурсов, загрузка кода, ввод настроек, однократная авторизация владельца, развёртывание с нужным режимом исполнения, проверка. Технические детали — в приложении. Не обещать автоматический перенос OAuth, старого deployment URL или доступность анонимного режима при запрете домена. 4. Проверить актуальные правила Google для личного/Workspace-аккаунта, междоменных ограничений и владения проектом. Основной воспроизводимый путь — новое развёртывание под целевым владельцем; смену владельца без проверки не считать достаточной. 5. Составить паспорт передачи: версия кода, структура данных, параметры без секретов, список ресурсов и ответственных ролей, процедура резервного копирования/восстановления, ручные действия нового владельца. ### Приёмка - Из чистого проекта по инструкции воспроизводится учебный экземпляр без правки исходного кода под личный аккаунт. - Повторная установка не стирает ответы и не перепривязывает сервис к таблице прежнего владельца; отсутствующие/чужие параметры дают понятную ошибку. - Инструкция различает разовую авторизацию владельца и работу организатора/зрителя; явно перечисляет параметры, изменяющиеся при переносе, включая URL для Яндекс webhook и экранов. - Исходники, шаблоны, примеры настроек и паспорт не содержат реальных секретов/ответов. Есть отчёт о прогоне и перечень ещё не выполненных шагов на целевом аккаунте. - Фактический перенос на аккаунт ИТ и переключение пользователей выполняются в последующей задаче пилота. Зависит от: #12. ### Порядок работы и ограничения Постановка по поручению владельца от 09.11.2026. Сейчас разрешено открыть задачи; эта запись не является поручением автоматически начать реализацию, развернуть публичный сервис или перенести данные. Исполнителя назначает координатор отдельно. Перед реализацией прочитать AGENTS.md, актуальный main, последние комментарии и результаты #7–#11. Не перехватывать чужие doing-задачи. Выбранный и принятый исходный SHA записать в отчёте: вариант Terra 097ca49 — кандидат, а не автоматически принятый main. Отдельный worktree и ветка codex/, коммиты со ссылкой на свою задачу; без самовольного merge. Инструменты: Forgejo connector либо штатный LAN API из hub (токен не выводить); rg для кода; существующие Node-тесты и новые содержательные проверки; Google/Яндекс через доступный профильный инструмент или браузер. Проверить возможности инструмента, не выдумывать API. Зависимости устанавливать только при необходимости. Локальные тесты, реальный Google и настоящий Яндекс→Google отражать отдельными статусами. При отсутствии доступа фиксировать точный непройденный шаг; моки и HTTP 200 не являются приёмкой интеграции. Боевой стенд КБР, общий Google-шаблон, чужие worktree, доступы и реальные ответы не менять. Разработка и проверки — на отдельных учебных ресурсах; публикация и миграция выполняются отдельным явно согласованным действием. В репозитории и отчётах не размещать токены, OAuth-данные, персональные ответы и действующие секреты; для примеров использовать только учебные значения. ```orchestrator-anchors { "depends_on": [ 12 ], "write_paths": [ "src/", "tests/", "tools/deployment/", "docs/deployment/" ], "files_exist": [ "docs/deployment/README.md" ], "commit_ref": "#13" } ```

valalav referenced this issue 2026-11-09 17:54:44 +00:00

Пилот на аккаунте ИТ: настоящий Яндекс→Google, перенос и проверяемое переключение #14

valalav added the

agent:gemini-4.0-argon

state:doing

labels 2026-11-09 18:28:44 +00:00

valalav commented 2026-11-09 18:28:45 +00:00

Author

Owner

Copy link

🤖 gemini-4.0-argon · DESKTOP-6KC7IA7

Взял в работу.

🤖 **gemini-4.0-argon** · DESKTOP-6KC7IA7 **Взял в работу.**

valalav referenced this issue from a commit 2026-11-09 18:48:47 +00:00

feat(deployment): portable IT deployment kit, config validator, transfer passport, and IT owner guide (#13)

valalav added

state:review

and removed

state:doing

labels 2026-11-09 18:53:02 +00:00

valalav commented 2026-11-09 18:53:02 +00:00

Author

Owner

Copy link

🤖 gemini-4.0-argon · DESKTOP-6KC7IA7

Готово, на проверку. Выполнено в изолированной ветке codex/shared-service-it (коммит 07a64a9, после #12 5674a82).

1. Что сделано ([извлечено])

1. Вынос всех зависимых от аккаунта параметров из исходников (src/Code.gs, tools/deployment/config.example.json):
   • В src/Code.gs нет зашитых ID рабочих таблиц (SHEET_ID = ''), токенов или URL развёртываний; все параметры хранятся в ScriptProperties (SERVICE_MODE, ADMIN_MASTER_KEY, EVENTS_REGISTRY_JSON).
   • В validateServiceConfig и tools/deployment/validate_deployment_config.mjs все секреты в диагностическом выводе маскируются (in***11).
2. Идемпотентная инициализация и перенос конфигурации без секретов (src/Code.gs):
   • Повторный запуск setupTemplate() или ensureBookStructure_() сохраняет все существующие ответы в строках 2..N (проверено в test_code_gs.mjs, тест 14a).
   • Добавлены exportPublicConfig(adminKey) (выгружает структуру мероприятий и codingRules без секретов и без ответов) и importPublicConfig(publicConfig, targetBindings, adminKey) (разворачивает мероприятия на новых таблицах и ключах целевого аккаунта ИТ; проверено в тесте 14c).
3. Инструкция для специалиста ИТ и паспорт передачи (docs/deployment/README.md, docs/deployment/TRANSFER_PASSPORT.md):
   • Пошаговая инструкция со скриншотами (screenshots/step2_apps_script_files.png, step3a, step3b, step5a, step5b), разделяющая разовую авторизацию владельца ИТ и работу регионального организатора без OAuth.
   • Паспорт передачи с перечнем всех изменяющихся при переносе параметров, правилами Google для личных и Workspace-аккаунтов и чеклистом ручных шагов.

2. Проверки ([извлечено])

• node tools/deployment/validate_deployment_config.mjs --self-test → exit 0 (validate_deployment_config.mjs self-test PASSED: отсекает незаполненные плейсхолдеры REPLACE_WITH_*, шаблон 1DCAwa..., учебный секрет ks-live-2026 и маскирует ключи).
• node tests/test_code_gs.mjs → exit 0 (включая раздел 14a–14c).
• revizor_telemetry.py precheck --strict-exit → exit 0.

3. Failure Mode Analysis

1. Попытка переноса через смену владельца файла в Google Drive вместо чистого развёртывания: OAuth-согласие и привязка Web App (Execute as: Me) не переносятся автоматически при смене владельца таблицы — требуется новое развёртывание под целевым аккаунтом ИТ.
2. Несовпадение ключей после переноса: при переходе на стенд ИТ старый /exec URL не сохраняется; организаторам передаются новый /exec URL и новые ingestKey / viewKey.

🤖 **gemini-4.0-argon** · DESKTOP-6KC7IA7 **Готово, на проверку.** Выполнено в изолированной ветке `codex/shared-service-it` (коммит `07a64a9`, после `#12` `5674a82`). ### 1. Что сделано (`[извлечено]`) 1. **Вынос всех зависимых от аккаунта параметров из исходников (`src/Code.gs`, `tools/deployment/config.example.json`):** - В `src/Code.gs` нет зашитых ID рабочих таблиц (`SHEET_ID = ''`), токенов или URL развёртываний; все параметры хранятся в `ScriptProperties` (`SERVICE_MODE`, `ADMIN_MASTER_KEY`, `EVENTS_REGISTRY_JSON`). - В `validateServiceConfig` и `tools/deployment/validate_deployment_config.mjs` все секреты в диагностическом выводе маскируются (`in***11`). 2. **Идемпотентная инициализация и перенос конфигурации без секретов (`src/Code.gs`):** - Повторный запуск `setupTemplate()` или `ensureBookStructure_()` сохраняет все существующие ответы в строках `2..N` (проверено в `test_code_gs.mjs`, тест `14a`). - Добавлены `exportPublicConfig(adminKey)` (выгружает структуру мероприятий и `codingRules` без секретов и без ответов) и `importPublicConfig(publicConfig, targetBindings, adminKey)` (разворачивает мероприятия на новых таблицах и ключах целевого аккаунта ИТ; проверено в тесте `14c`). 3. **Инструкция для специалиста ИТ и паспорт передачи (`docs/deployment/README.md`, `docs/deployment/TRANSFER_PASSPORT.md`):** - Пошаговая инструкция со скриншотами (`screenshots/step2_apps_script_files.png`, `step3a`, `step3b`, `step5a`, `step5b`), разделяющая разовую авторизацию владельца ИТ и работу регионального организатора без OAuth. - Паспорт передачи с перечнем всех изменяющихся при переносе параметров, правилами Google для личных и Workspace-аккаунтов и чеклистом ручных шагов. ### 2. Проверки (`[извлечено]`) - `node tools/deployment/validate_deployment_config.mjs --self-test` → `exit 0` (`validate_deployment_config.mjs self-test PASSED`: отсекает незаполненные плейсхолдеры `REPLACE_WITH_*`, шаблон `1DCAwa...`, учебный секрет `ks-live-2026` и маскирует ключи). - `node tests/test_code_gs.mjs` → `exit 0` (включая раздел `14a`–`14c`). - `revizor_telemetry.py precheck --strict-exit` → `exit 0`. ### 3. Failure Mode Analysis 1. **Попытка переноса через смену владельца файла в Google Drive вместо чистого развёртывания:** OAuth-согласие и привязка Web App (`Execute as: Me`) не переносятся автоматически при смене владельца таблицы — требуется новое развёртывание под целевым аккаунтом ИТ. 2. **Несовпадение ключей после переноса:** при переходе на стенд ИТ старый `/exec` URL не сохраняется; организаторам передаются новый `/exec` URL и новые `ingestKey` / `viewKey`.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

codex/shared-service-it

codex/luna-survey-validation

codex/terra-6.1-survey

experiment/qwen-flash

experiment/gemini-flash

No results found.

Labels

Clear labels   

agent:gemini-3.8-flash

  

agent:gemini-4.0-argon

  

agent:mimo-2.6-pro

  

state:doing

  

state:review

No labels

agent:gemini-3.8-flash

agent:gemini-4.0-argon

agent:mimo-2.6-pro

state:doing

state:review

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

valalav/ks-live-survey#13

No description provided.