Support input_type for asymmetric embeddings in built-in memorySearch

[prospect1314521]

Support input_type for Asymmetric Embeddings in Built-in memorySearch

Summary

Built-in memorySearch does not currently support passing input_type to embedding providers. This blocks asymmetric embedding models that require input_type (e.g., query vs passage), causing 400 errors and forcing users to patch their local code.

Current Behavior

• memorySearch embedding requests are sent without input_type
• Asymmetric models return 400 errors: "input_type parameter is required for asymmetric models"
• Users must manually patch built/dist files as a workaround

Expected Behavior

Add official config support for memorySearch and forward these fields to the embedding request body:

• inputType — optional global default
• queryInputType — optional, used for query embeddings
• documentInputType — optional, used for document/indexing embeddings

Suggested Config Example

{
  "memorySearch": {
    "enabled": true,
    "provider": "openai",
    "remote": {
      "baseUrl": "https://api.example.com/v1",
      "apiKey": "***"
    },
    "model": "your-asymmetric-embedding-model",
    "inputType": "passage",
    "queryInputType": "query",
    "documentInputType": "passage"
  }
}

Implementation Plan

Primary Changes (Core Functionality)

File	Change
src/types.ts	Add inputType, queryInputType, documentInputType to embedding config types
src/embedding/providers/openai.ts	Forward input_type in embedding request body for OpenAI-compatible providers
src/embedding/index.ts	Route query calls to use queryInputType, document calls to use documentInputType (fallback to inputType)
src/viewer/server.ts	Auto-retry embedding test with input_type=query when provider returns "input_type required" error

Secondary Changes (Improvements)

#	File	Change
1	src/ingest/providers/{anthropic,bedrock,gemini,openai}.ts	Increase all LLM call default timeouts from 15s to 600s (summarize, summarizeTask, generateTaskTitle, judgeNewTopic, classifyTopic, arbitrateTopicSplit, filterRelevant, judgeDedup)
2	src/ingest/providers/index.ts	Enhance fallback chain: deduplicate models, expand fallbacks, randomize polling start point
3	src/shared/llm-call.ts	Enhance retry/timeout logic; ensure input_type is preserved across retries
4	src/skill/generator.ts	Make skill generation timeout configurable; inject skill-creator best practices into STEP1_SKILL_MD_PROMPT (short name, description as trigger, body <500 lines, Progressive Disclosure)
5	src/skill/upgrader.ts	Fix hardcoded timeouts (90s/60s → read from config, default 600s) via get timeoutMs() getter
6	src/index.ts	Fix workspaceDir fallback: process.cwd() → path.join(stateDir, "workspace") to prevent EPERM: mkdir 'C:\Windows\System32\skills' on Windows
7	src/types.ts	Extend types to support summarizer fallbacks
8	package.json	Preserve and verify beta4 script customizations
9	tsconfig.json, openclaw-plugin-sdk.d.ts, package-lock.json	Verify compatibility with new types

Why This Matters

• Makes asymmetric embedding models usable in built-in memorySearch without manual patches
• Avoids upgrade-time regressions for users depending on query/passage semantics
• Aligns built-in behavior with plugins or forks that already support input_type

Reference

• Original OpenClaw report: Support input_type for asymmetric embeddings in built-in memorySearch openclaw/openclaw#60727

Notes for Maintainers

• Priority: Implement primary changes first — they enable core functionality
• Backwards compatibility: Default to existing behavior when inputType is not provided (symmetric models)
• Testing: Add a test exercising both query and document embedding paths against an asymmetric-compatible mock provider

[prospect1314521]

Additional Suggestion: Post-process frontmatter to guarantee name/description

Even with prompt improvements, the LLM frequently omits or malforms frontmatter (e.g., empty --- blocks, missing name/description fields). This causes generated skills to be invisible to the agent's skill router.

Recommended fix: Add a post-processing step in SkillGenerator.generate() that validates and repairs frontmatter after LLM output:

private ensureFrontmatter(content: string, evalResult: CreateEvalResult): string {
  const hasName = /^name:\s*\S+/m.test(content);
  const hasDesc = /^description:\s*\S+/m.test(content);
  if (hasName && hasDesc) return content;

  const safeName = evalResult.suggestedName.replace(/[^a-z0-9-]/g, "-").toLowerCase();
  const safeDesc = evalResult.reason || `Skill generated from task`;
  const frontmatter = `---\nname: "${safeName}"\ndescription: "${safeDesc}"\n---\n\n`;

  let body = content.trim();
  if (body.startsWith("---")) {
    const end = body.indexOf("---", 3);
    if (end !== -1) body = body.slice(end + 3).trim();
  }
  return frontmatter + body;
}

Why this matters:

• Without valid frontmatter, the skill is never triggered — the entire generation effort is wasted
• Prompt instructions alone are not reliable enough; LLMs often skip frontmatter when excited about the body content
• A simple post-process guarantee ensures every generated skill is at least discoverable