Follow-up from #5829.
The stricter source slug guard fixed the core CWE-22 issue, but several unchanged paths now need consistent handling for invalid or legacy slugs:
config-validate.ts fallback path can throw from getSourceConfigPath() instead of returning a structured validation result.
source-test.ts can use source.slug from config.json, where the basic slug regex and strict path-helper regex disagree.
validateAllSources reports legacy invalid-slug directories as errors, while validateAllPermissions skips them with warnings.
deleteSource invalid-slug errors can propagate to the RPC/global handler as generic failures.
Goal: keep the stricter slug validation, but make invalid/legacy slug behavior consistent, structured, and covered by regression tests.
Suggested follow-up PR title:
fix(desktop): normalize source slug validation errors
Suggested PR linkage:
Closes #<this-issue-number>
Follow-up from #5829.
The stricter source slug guard fixed the core CWE-22 issue, but several unchanged paths now need consistent handling for invalid or legacy slugs:
config-validate.tsfallback path can throw fromgetSourceConfigPath()instead of returning a structured validation result.source-test.tscan usesource.slugfromconfig.json, where the basic slug regex and strict path-helper regex disagree.validateAllSourcesreports legacy invalid-slug directories as errors, whilevalidateAllPermissionsskips them with warnings.deleteSourceinvalid-slug errors can propagate to the RPC/global handler as generic failures.Goal: keep the stricter slug validation, but make invalid/legacy slug behavior consistent, structured, and covered by regression tests.
Suggested follow-up PR title:
Suggested PR linkage:
Closes #<this-issue-number>