feat(manager): migrate Manager runtime from copaw to qwenpaw 2.0 - #1095
Open
LUOSENGWA wants to merge 62 commits into
Open
feat(manager): migrate Manager runtime from copaw to qwenpaw 2.0#1095LUOSENGWA wants to merge 62 commits into
LUOSENGWA wants to merge 62 commits into
Conversation
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
LUOSENGWA
force-pushed
the
manager-qwenpaw-2.0
branch
2 times, most recently
from
July 28, 2026 14:26
0676a69 to
9e293b2
Compare
LUOSENGWA
added a commit
to LUOSENGWA/HiClaw
that referenced
this pull request
Jul 28, 2026
After PR agentscope-ai#1095 the Manager runs QwenPaw 2.0, not copaw. The script name should reflect reality. start-manager-agent.sh now accepts both 'copaw' (legacy runtime identifier used by controller/installer/CI) and 'qwenpaw' (forward- looking name). Both map to the same start-qwenpaw-manager.sh. Controller, installer, CI, Makefile, and Docker image name still use 'copaw' as the runtime identifier — changing those is a separate PR (the controller already defines RuntimeQwenPaw='qwenpaw' for Workers; adding a qwenpaw Manager runtime requires new config fields, image selection logic, and CI matrix entries).
Change-Id: I9ad741de07f4b7bfbbe3721030df8749546a0def
Change-Id: I7d7930c2391217d2c1887eb4d7e20449b4b16ce8
Change-Id: I3073b27f43f0ecde4e6fa2164fd49d2659d50dcf
Change-Id: I31687da14f2d40bfb50dade36a8d7467e9aa8ddd
Change-Id: Ieeed7e69bf3b23e3f03aaa5168e4fe807040c1fe
Change-Id: I9b2094e39e7dfc12437aedf347199ace79de1f5b
Change-Id: I04a62daf94efad6d0445dce93a56cf897530c25e
Change-Id: I7af2aece15ab2c733754beee59e31d377ca1d810
Change-Id: I55ac99d6d22041bc7e0d229449fd0333f6ca8a29
Change-Id: I961ed24fb022cbe8ac01fab81dfe018a00c14a5d
Change-Id: Ic437642f20426d03f585442fb06867ede35e6151
Change-Id: I352dc6fa16715f0ce03ce00931e61a0abadc4efc
Change-Id: I03e49cd512911c176c9a8cb3d407877fdf8b2363
Change-Id: I50577926a078ed50232e3eb6af6583d1162be7df
Change-Id: I88060c8e6c49862205ec602de2ae3e72a4f2c879
maplefeng-a
force-pushed
the
codex/qwenpaw-2-startup
branch
from
July 30, 2026 11:29
60a8c88 to
19211da
Compare
Manager now runs on QwenPaw 2.0.1 alongside PR agentscope-ai#1077's Worker migration. Key changes: - Separate venvs: /opt/copaw-venv (copaw 1.0.2 for bridge.py) and /opt/venv/qwenpaw (qwenpaw 2.0.1 for Manager runtime), avoiding agentscope version conflict (1.0.20 vs 2.0.4) - Replace copaw hooks (monkey-patch CoPawAgent._create_toolkit) with agentteams-manager-tools QwenPaw plugin (api.register_tool()) for projectflow/taskflow/message/filesync - Delete Matrix channel physical overlay; use QwenPaw plugin system (agentteams-matrix-channel) symlinked into WORKING_DIR/plugins/ - run_copaw_app.py simplified to runpy.run_module('qwenpaw') - bridge.py invoked with /opt/copaw-venv/bin/python3 (pure stdlib, copaw 1.0.2 deps preserved) - CI pgrep pattern accepts both 'copaw app' and 'qwenpaw app'
The message and taskflow tools deferred-imported copaw.config.config to read Matrix credentials (homeserver, access_token, user_id). In the QwenPaw 2.0 venv copaw 1.0.2 is absent, so _matrix_config_for_agent() raised ImportError — the message tool could not send any Matrix messages. Fix: read workspaces/<id>/agent.json directly (framework-agnostic). bridge.py already writes the Matrix channel config there. Also add QWENPAW_WORKING_DIR fallback to _resolve_copaw_working_dir() and _current_actor().
copaw is the predecessor of qwenpaw (renamed package). In the qwenpaw 2.0 venv the copaw package does not exist, so the try/except in _resolve_copaw_working_dir() should attempt qwenpaw first.
Systematic alignment with PR agentscope-ai#1077 Worker Dockerfile and QwenPaw 2.0 conventions: Dockerfile: - CMS observability: loongsuite-instrumentation-copaw → -qwenpaw + add loongsuite-otel-util-genai (matches Worker Dockerfile) start-copaw-manager.sh: - Add QWENPAW_SECRET_DIR, QWENPAW_RUNNING_IN_CONTAINER, QWENPAW_LOG_LEVEL env vars (matches Worker entrypoint) - CMS bootstrap: replace python3 heredoc script with direct heredoc (matches Worker), add LOONGSUITE_PYTHON_SITE_BOOTSTRAP_LOG_SUCCESS export - Inject session file privacy policy into AGENTS.md/SOUL.md (matches Worker _ensure_session_file_prompt_policy) - Remove dead PYTHONPATH=/opt/agentteams/copaw/src (path never existed in the image; modules are in site-packages) agent.manager.json: - Move approval_level into running section (matches QwenPaw 2.0 AgentProfileConfig schema, default AUTO)
QA Agent: Worker disables QwenPaw_QA_Agent_0.2 via API client.
Manager runs QwenPaw in-process with no API client, so set
enabled=false in config.json agents.profiles before startup.
QwenPaw's ensure_qa_agent_exists() skips agents already in profiles,
so our preset is preserved. start_all_configured_agents() skips
enabled=false agents.
approval_level: Move from running{} to top-level in agent.manager.json.
QwenPaw 2.0 AgentProfileConfig.approval_level is a top-level field,
not inside AgentsRunningConfig (which has extra='ignore' and would
silently drop it).
OpenClaw Manager sets tools.exec.ask=off for YOLO mode. QwenPaw 2.0's equivalent is approval_level=OFF (short-circuits the governance pipeline to ALLOW-all). start-manager-agent.sh promotes the yolo-mode marker file to AGENTTEAMS_YOLO=1 before calling this script; we translate that to agent.json approval_level=OFF here.
After PR agentscope-ai#1095 the Manager runs QwenPaw 2.0, not copaw. The script name should reflect reality. start-manager-agent.sh now accepts both 'copaw' (legacy runtime identifier used by controller/installer/CI) and 'qwenpaw' (forward- looking name). Both map to the same start-qwenpaw-manager.sh. Controller, installer, CI, Makefile, and Docker image name still use 'copaw' as the runtime identifier — changing those is a separate PR (the controller already defines RuntimeQwenPaw='qwenpaw' for Workers; adding a qwenpaw Manager runtime requires new config fields, image selection logic, and CI matrix entries).
…disable Six issues found during deep audit with CI script and PR agentscope-ai#1077 cross-reference: 1. pgrep pattern: \|qwenpaw app was a literal pipe in ERE, breaking the original copaw pattern. Manager process cmdline is still 'python3 -m copaw_worker.run_copaw_app app' (runpy.run_module does not change /proc/cmdline), so the original agentscope-ai#1077 pattern works. Reverted to 'copaw(_worker\.run_copaw_app)? app'. 2. Plugins invisible at runtime: Dockerfile copied plugins to /root/manager-workspace/.copaw/plugins/ (build-time), but the install script mounts a host volume at /root/manager-workspace, hiding build-time files. Now stores plugins in image-local /opt/agentteams/plugins/ and copies them at runtime in start-qwenpaw-manager.sh (mirrors Worker's _prepare_builtin_plugin). 3. CMS packages in wrong venv: pip install ran while PATH pointed to copaw-venv, but Manager runs from qwenpaw venv. Moved CMS install after qwenpaw venv creation with /opt/venv/qwenpaw/bin/pip. 4. QA Agent disable silently fails: jq wrote {"enabled": false} but AgentProfileRef requires id + workspace_dir. Pydantic validation stripped the incomplete profile, then ensure_qa_agent_exists() recreated it with enabled=true. Now writes a complete profile. 5. taskflow._current_actor() working dir resolution inconsistent with message.py: only checked env vars, no qwenpaw.constant fallback. Added _resolve_working_dir() mirroring message.py's logic. 6. plugin.py docstring stale: claimed taskflow/message still import copaw.config.config, but commit 974cdf6 already removed that. plugin.json type changed from 'general' to 'tool'.
…migration overwrite The QA Agent disable jq only injected agents.profiles['QwenPaw_QA_Agent_0.2'] without the 'default' profile. On first boot, QwenPaw's migrate_legacy_workspace_to_default_agent() sees len(profiles)==1 and 'default' not in profiles → runs legacy migration → replaces config.agents entirely → QA profile lost → ensure_qa_agent_exists() re-creates it with enabled=True, defeating the disable. Fix: inject both 'default' and QA profiles so len(profiles)>=2, which causes the migration to be skipped (multi-agent config detected).
LUOSENGWA
force-pushed
the
manager-qwenpaw-2.0
branch
from
July 30, 2026 13:53
58133f1 to
6092637
Compare
Author
|
Hi @shiyiyue1102 @maplefeng-a — this PR is the Manager-side counterpart to #1077's Worker migration from copaw 1.0.2 to QwenPaw 2.0.1. 改动概要 / What it does： 将 Manager 容器从 copaw 1.0.2 迁移到 QwenPaw 2.0.1，与 #1077 采用相同插件架构：
合入策略 / Merge strategy： 此 PR target 是 不在范围 / Not in scope： Controller 改名（copaw→qwenpaw in Go code）已推迟到独立 PR，避免与 #1077 的 controller 改动冲突。 CI 说明： pgrep 检查应该通过——Manager 进程 cmdline 保持 |
QwenPaw 2.0 and PR agentscope-ai#1077 standardise on ~/.qwenpaw as the working directory. The Controller in agentscope-ai#1077 drops copaw directory compatibility, so the Manager must also migrate from ~/.copaw to ~/.qwenpaw. - COPAW_WORKING_DIR → QWENPAW_WORKING_DIR throughout - Default path ~/.copaw → ~/.qwenpaw - Remove legacy auto-detection comment (no longer applicable) - Bridge --working-dir now points to ~/.qwenpaw - Plugin target ~/.qwenpaw/plugins
Collaborator
|
Thanks for the migration work. I found two blocking upgrade/runtime issues:
Please align all tool path resolution, add an idempotent upgrade migration, and cover a startup scenario where only The PR now targets 感谢这次迁移。目前有两个阻塞问题：
请统一工具路径解析，增加幂等的升级迁移，并补充只设置 PR 现在已经指向 |
…rate .copaw state shiyiyue1102 identified two blocking issues: 1. projectflow/taskflow/filesync resolved paths from COPAW_WORKING_DIR only, splitting state across Manager root, .copaw, and .qwenpaw. Fix: extract shared _working_dir() that reads QWENPAW_WORKING_DIR (with COPAW_WORKING_DIR fallback + qwenpaw.constant fallback). All tools now derive paths from _working_dir(). 2. Existing .copaw state was lost when runtime moved to .qwenpaw. Fix: idempotent migration step in start-qwenpaw-manager.sh copies chats.json, history.db, memory/, digest/, .secret/, and workspace prompt files from .copaw/ to .qwenpaw/ on first boot. Flag file .copaw-migrated prevents re-execution.
Per shiyiyue1102's directive to unify on QwenPaw 2.0: - Add 'qwenpaw' as menu option 1 (default), copaw as 2 (legacy), openclaw as 3 - All defaults changed from copaw to qwenpaw (new installs, non-interactive, post-machine, env file, controller env vars) - Image selection: != 'openclaw' → MANAGER_COPAW_IMAGE (covers copaw + qwenpaw) - Health check: copaw|qwenpaw → curl 18799 (same endpoint) - Domain check: console domain only for openclaw (copaw + qwenpaw skip it) - Backward compatible: existing copaw deployments keep working, upgrades preserve the existing runtime choice
… support Deep audit findings after shiyiyue1102's review: 1. message.py _resolve_copaw_working_dir(): env var priority was COPAW first → QWENPAW first (consistent with projectflow/taskflow/filesync) 2. start-qwenpaw-manager.sh migration: secret dir is a SIBLING directory (~/.copaw.secret), not a subdirectory (~/.copaw/.secret). Fixed to migrate ~/.copaw.secret → ~/.qwenpaw.secret with mkdir -p. 3. start-qwenpaw-manager.sh: export COPAW_WORKING_DIR alongside QWENPAW_WORKING_DIR. message_filter._runtime_root() and sync.FileSync still read COPAW_WORKING_DIR — without this export they fall back to cwd (wrong path). 4. CI test scripts: 'copaw)' → 'copaw|qwenpaw)' in 5 places: - test-helpers.sh wait_for_manager_agent_ready health check - test-05-heartbeat.sh heartbeat trigger - agent-metrics.sh snapshot_baseline/collect_delta/collect_test (×3)
Author
|
改错了，先别看 I made a mistake, don’t read it yet |
…ction CRITICAL: Previous commit f81d43c changed Manager image selection from '= "copaw"' to '!= "openclaw"', which incorrectly routes hermes and any unknown runtime to the copaw (QwenPaw) image instead of the openclaw image. Manager only has two images: agentteams-manager (OpenClaw) and agentteams-manager-copaw (QwenPaw 2.0). Hermes is Worker-only — there is no agentteams-manager-hermes image. An unknown runtime must fall through to MANAGER_IMAGE (OpenClaw), not MANAGER_COPAW_IMAGE. Fix: use explicit '= copaw || = qwenpaw' in all 3 image selection points (image pull, docker run env var, docker run image name). Behavior for copaw/qwenpaw/openclaw is unchanged; hermes and unknown values now correctly fall through to MANAGER_IMAGE.
… text - AGENTTEAMS_MANAGER_RUNTIME default: openclaw → qwenpaw (install script now defaults to qwenpaw; controller default should match) - agt create manager --runtime help: add qwenpaw to valid values The Manager reconciler has no runtime-specific logic — it passes ManagerRuntime through to the CR spec. No RuntimeQwenPaw constant needed for Manager; the install script already handles image selection via MANAGER_COPAW_IMAGE for both copaw and qwenpaw.
Per shiyiyue1102's directive: '都统一切到QwenPaw2.0' — copaw is the legacy name, qwenpaw is the new name. After this PR, copaw no longer exists as a Manager runtime option. Changes: - install.sh menu: remove copaw option (was 3 choices, now 2: qwenpaw + openclaw) - install.sh messages: remove manager_runtime.copaw, choice [1/2] - install.sh step_manager_runtime: auto-migrate copaw → qwenpaw at function entry (before menu logic) - install.sh install_manager: second migration point for --skip and non-interactive paths - start-manager-agent.sh: update comments, keep copaw|qwenpaw dispatch as defensive fallback (Controller may pass legacy value) - Controller config.go: default AGENTTEAMS_MANAGER_RUNTIME openclaw → qwenpaw - Controller create.go: update CLI help text with qwenpaw - changelog: update to reflect copaw elimination (not dual support) Defensive copaw recognition retained in: - Image selection (copaw||qwenpaw → MANAGER_COPAW_IMAGE) - Health check (copaw|qwenpaw → curl 18799) - Domain check (!= copaw && != qwenpaw → console domain) - start-manager-agent.sh dispatch (copaw|qwenpaw → start-qwenpaw-manager.sh) - CI test scripts (copaw|qwenpaw in health/heartbeat/metrics) These ensure upgrades from existing copaw deployments work correctly even if the migration step is somehow skipped.
PR agentscope-ai#1077 added RuntimeQwenPaw + QWENPAW_WORKER_IMAGE to the Controller and install script, but step_runtime still showed copaw as option 1 and default. Per shiyiyue1102's directive '都统一切到QwenPaw2.0', copaw is eliminated from the Worker runtime as well: - step_runtime: copaw → qwenpaw (option 1, default, upgrade migration) - All DEFAULT_WORKER_RUNTIME defaults: copaw → qwenpaw (4 locations) - worker_runtime messages: copaw → qwenpaw - Controller create.go: remove copaw from CLI help text, update examples - Hermes remains as option 3 (unaffected — it is a separate runtime) Runtime landscape after this PR: Manager: qwenpaw (default) | openclaw Worker: qwenpaw (default) | openclaw | hermes copaw: auto-migrated to qwenpaw on upgrade (defensive fallback retained)
Update user-facing documentation to reflect the runtime unification: - faq.md: rewrite 'Why copaw' FAQ — runtime value is now qwenpaw, copaw only remains in image names for backward compatibility - faq.md: update Worker CRD accepted runtimes list - k8s-native-agent-orch.md: Worker runtime example copaw → qwenpaw, Manager runtime comment copaw → qwenpaw - manager-guide.md: AGENTTEAMS_MANAGER_RUNTIME default openclaw → qwenpaw, update QwenPaw Manager section title - declarative-resource-management.md: Worker + Manager runtime values - import-worker.md: --runtime help text and accepted values - changelog: 'Manager runtime' → 'runtime unification' (Manager + Worker)
Per shiyiyue1102's directive: '都统一切到QwenPaw2.0' and '后面copaw
的都要切换到QwenPaw'. The Manager container already runs QwenPaw 2.0
internally — this commit aligns the external naming.
Renames (Manager-only; Worker copaw-worker stays as-is for a follow-up):
- Image: agentteams-manager-copaw → agentteams-manager-qwenpaw
- Dockerfile: manager/Dockerfile.copaw → manager/Dockerfile.qwenpaw
- Makefile vars/targets: MANAGER_COPAW_* → MANAGER_QWENPAW_*,
build-manager-copaw → build-manager-qwenpaw, etc.
- install.sh: AGENTTEAMS_INSTALL_MANAGER_COPAW_IMAGE → QWENPAW,
MANAGER_COPAW_IMAGE → MANAGER_QWENPAW_IMAGE
- CI build targets: manager-copaw → manager-qwenpaw (build.yml,
test-integration.yml, build-rc.yml)
- hack/local-k8s-up.sh: COPAW_MANAGER_IMAGE → QWENPAW_MANAGER_IMAGE
- Helm CRD: managers.agentteams.io runtime enum adds 'qwenpaw'
CI runtime matrix (manager_runtime: copaw) is intentionally unchanged —
'copaw' and 'qwenpaw' both resolve to the same QwenPaw 2.0 image via
the copaw|qwenpaw match in install.sh and start-manager-agent.sh.
Deep audit found three modules with hardcoded .copaw paths that break when running in the qwenpaw venv (working dir is ~/.qwenpaw, not ~/.copaw): 1. bridge.py sync_inner_prompt_files_to_outer(): hardcoded .copaw/workspaces/default/ — inner→outer prompt sync silently failed. Now detects .qwenpaw first, falls back to .copaw. 2. sync.py _EXCLUDE_PATHS/_EXCLUDE_PATH_PREFIXES: hardcoded .copaw/workspaces/default/ exclusion patterns — Manager-managed config files (mcporter.json) and runtime skill/shared projections were not excluded from MinIO push in qwenpaw mode. Added .qwenpaw variants alongside existing .copaw entries. 3. message_filter.py _runtime_root(): only recognized .copaw dir name — fell through to path.parent (correct by accident when COPAW_WORKING_DIR points to ~/.qwenpaw, but wrong if it points to ~/.qwenpaw/workspaces/default). Now checks QWENPAW_WORKING_DIR env var and recognizes both .copaw and .qwenpaw directory names. Also removed dead COPAW_LOG_LEVEL export from start-qwenpaw-manager.sh (no consumer — QWENPAW_LOG_LEVEL is set earlier and is the only one qwenpaw reads).
Addresses shiyiyue1102's review: 'CoPaw和QwenPaw工作目录不一样，没法兼容'. Previously, projectflow/taskflow read QWENPAW_WORKING_DIR while filesync and message_filter read COPAW_WORKING_DIR — causing task state and file sync to land in different directories. The .copaw directory is incompatible with QwenPaw 2.0 (PR agentscope-ai#1077 Controller drops .copaw support). Root cause: bridge.py set only COPAW_WORKING_DIR and patched only copaw.constant, leaving qwenpaw.constant with stale import-time values. Changes (8 files): bridge.py: - Set BOTH COPAW_WORKING_DIR and QWENPAW_WORKING_DIR env vars - Add _patch_qwenpaw_paths() to patch qwenpaw.constant module-level constants (WORKING_DIR, SECRET_DIR, MEMORY_DIR, PLUGINS_DIR, etc.) - sync_inner_prompt_files_to_outer: .qwenpaw first, .copaw legacy fallback sync.py: - FileSync reads QWENPAW_WORKING_DIR first, COPAW_WORKING_DIR fallback - Default local_dir changed from .copaw-worker to .qwenpaw-worker - _EXCLUDE_PATHS/_EXCLUDE_PATH_PREFIXES: .qwenpaw only (removed .copaw) message_filter.py: - _runtime_root(): QWENPAW_WORKING_DIR first, recognizes both .qwenpaw and .copaw directory names (legacy compat) matrix_channel.py: - _runtime_root(): QWENPAW_WORKING_DIR first, .qwenpaw/.copaw dual - _media_dir(): qwenpaw.constant first, copaw.constant fallback, .qwenpaw default (was .copaw) - _e2ee_store_path(): QWENPAW_WORKING_DIR first, .qwenpaw default worker.py: - Working dir renamed from .copaw to .qwenpaw - Auto-migrate: if .copaw exists and .qwenpaw doesn't, rename it start-qwenpaw-manager.sh: - Migration expanded: now copies config.json, custom_channels/, plugins/, models/, sessions/ in addition to previous state files - Workspace migration uses cp -an (recursive, idempotent) instead of per-file loop (was missing subdirectories like config/) - COPAW_WORKING_DIR export kept (bridge.py now sets both, but pre-bridge modules may still read it) Tests updated: test_worker_health.py and test_sync.py use .qwenpaw
Author
|
本轮修复了 @shiyiyue1102 指出的路径分裂和 .copaw 不兼容三个问题： 修复内容
bridge_controller_to_copaw() 现在同时设置 QWENPAW_WORKING_DIR 和 COPAW_WORKING_DIR sync.py：FileSync 优先读 QWENPAW_WORKING_DIR，fallback COPAW_WORKING_DIR；默认路径 .copaw-worker → .qwenpaw-worker；排除模式只保留 .qwenpaw worker.py 现在使用 .qwenpaw 作为运行时目录，存量 .copaw 存在时自动 rename start-qwenpaw-manager.sh 迁移新增：config.json、custom_channels/、plugins/、models/、sessions/（之前只迁移 chats.json/history.db/memory/digest） test_worker_health.py、test_sync.py 使用 .qwenpaw |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Migrate the Manager container from copaw 1.0.2 to QwenPaw 2.0.1, following the same plugin-based architecture that PR #1077 established for Workers.
What changed
Manager runtime — separate venv for QwenPaw 2.0.1 to avoid agentscope version conflicts with copaw 1.0.2 (used only by bridge.py for config conversion). Manager tools (projectflow, taskflow, message, filesync) registered via a QwenPaw plugin instead of monkey-patching
CoPawAgent._create_toolkit.Matrix channel — physical overlay replaced with the
agentteams-matrix-channelplugin (same as Workers). CMS observability packages installed in the QwenPaw venv (aligned with Worker).Configuration —
QWENPAW_WORKING_DIRset alongside legacyCOPAW_WORKING_DIR. Session-file privacy policy injected into prompts.approval_level=AUTOat top level of agent template. YOLO mode bridged toapproval_level=OFF. Built-in QA Agent disabled. DeadPYTHONPATHentries removed.Tool compatibility —
messageandtaskflowtools read Matrix credentials directly fromagent.jsoninstead of importingcopaw.config.config(not available in qwenpaw venv). Working directory resolution handles bothQWENPAW_WORKING_DIRandqwenpaw.constantfallback.CI — pgrep health check remains
copaw(_worker\.run_copaw_app)? app(Manager process cmdline is unchanged).Plugins at runtime — stored image-local and copied to working dir on startup, since the workspace is a host-mounted volume.
Stack
#1077 merged → retargeted to main ✅
Follow-up
Controller/install/Makefile runtime identifier migration (
copaw→qwenpawfor Manager) is tracked for a separate PR — it touches Go controller code that #1077 also modifies, and should follow the same pattern (addqwenpawalongsidecopaw, then deprecate).