Code Review: feat(autoresearch): add Dr. Claw research pack

Overall a clean, well-scoped feature addition. A couple of minor concerns.

👍 Highlights

1. Data-driven approach — Dr. Claw is added purely as a PackDef entry in autoResearchPacks.ts with no special-case logic. The pack system is well designed.
2. Graceful env-only handling — The backend correctly skips MCP registration for packs that only need env vars (like gemini-figure). The frontend hides the MCP selector when there is only one option and hides the register command when it is empty. Logical.
3. configLabel extension — The optional configLabel field on PackDef is a clean extension. Other packs can use it too without breaking changes.
4. inno- prefix in symlink filter — Necessary for Dr. Claw skills to be discovered. One-line change, correct.

🔴 Must Fix

1. Unknown backend errors are silently swallowed (medium severity)

Old code:

if (!args) {
  results.errors.push({ step: 'mcp', error: `Unknown backend: ${mcpBackend}` });
}

New code:

if (!args) {
  results.steps.push({ step: 'mcp', status: 'skipped', message: `No MCP server needed for ${mcpBackend}` });
}

This is correct for gemini-figure, but if someone misconfigures a pack with a typo (e.g., mcpBackend: "codxe"), the old code would report an error while the new code silently skips with "No MCP server needed."

Suggestion: maintain an explicit allowlist of env-only backends (e.g., const envOnlyBackends = new Set(['gemini-figure'])) and only skip for those. Unknown backends should still error.

🟡 Suggestions

2. register: '' relies on JS falsy semantics (nit)

{ key: 'gemini-figure', label: 'Gemini (Figure Gen)', register: '', envVars: [...] }

The UI checks {mcpOpt.register && (...)}, so empty string works as falsy. But register: string in the PackDef type does not convey the intent. Consider either:

• Making the type register?: string (optional), or
• Adding a comment explaining that empty string means "no register command"

3. Korean translations are copy-pasted English (nit)

All ko strings are identical to en. If Korean localization is planned, these should be translated. If not, consider omitting ko and falling back to en at the consumer level to avoid maintaining duplicate strings.

Verdict

Approve with one fix — Address #1 (silent error swallowing for unknown backends), then good to merge. The rest are cosmetic improvements.