mirror of
https://github.com/bytedance/deer-flow.git
synced 2026-09-25 14:06:18 +00:00
c9043c2574
* fix(skills): resolve the user-scoped install scan from its own config UserScopedSkillStorage.ainstall_skill_from_archive re-implements the parent body to redirect the install target into the per-user custom root, and the copy dropped the app_config argument. _scan_skill_archive_contents_or_raise therefore fell back to the process-global get_app_config() for the static scan, while the archive preflight it inherits still read self._app_config -- so the two gates of a single install could consult different configs. The divergence is reachable whenever the storage outlives a config edit: DeerFlowClient snapshots get_app_config() at construction, and the Gateway hands its per-request get_config() to get_or_new_user_skill_storage, while get_app_config() hot-reloads a later edit of config.yaml. With the storage's config enabling skill_scan and the global disabling it, the preflight ran, the content scan silently skipped, and a CRITICAL archive installed. * fix(skills): thread app_config into the per-file LLM scan _scan_skill_archive_contents_or_raise takes app_config and uses it for the static gate, but never forwarded it to _scan_skill_file_or_raise, so the per-file LLM scan fell back to the process-global get_app_config() for skill_evolution.moderation_model_name and the model it constructs. Under the stale-snapshot scenario the content-scan fix addresses, the two halves of one install still read two different configs. Raised in review of #5703 by willem-bd. The gateway's own skill-write routes already pass app_config to scan_skill_content; this brings the install path in line.