Add reusable workflow starter templates

[AbigailDeng]

Problem

Workflow Activity vNext needs reusable starter definitions that users can instantiate and edit. The original enterprise_knowledge_assistant starter only answered from context supplied with the run, so its canvas did not perform the Lark knowledge retrieval implied by the scenario.

The intended contract is:

Aevatar Run/Chat question
-> caller-owned connected Lark Docs/Wiki search
-> relevant document content read
-> cited answer or structured extraction

Lark is only the knowledge source. It is not the question channel or trigger.

Solution

• Add ten importable starter YAML assets under workflow-templates/.
• Rewrite enterprise_knowledge_assistant.yaml as a visible 12-step retrieval workflow using only existing workflow primitives and the existing nyxid_proxy tool.
• Plan a bounded search query and call Lark Search v2 with DOCX/WIKI filters only.
• Select the most relevant eligible result, branch explicitly between DOCX and WIKI, resolve a Wiki node when needed, and call Get Docx Raw Content.
• Return either cited natural-language prose or strict JSON with data, sources, and missing_fields.
• Treat search responses and document content as untrusted evidence and fail closed when a source or document token cannot be read.

The four nyxid_proxy callsites intentionally omit capability. A reusable starter cannot embed one tenant's user_service_id or endpoint_id; after instantiation, the existing admission flow must bind each callsite to the caller's exact connected Lark operation before the workflow can run.

With the current primitives, the starter reads the single best eligible result per run. It does not use foreach for external reads because item-specific sub_param_arguments are not re-evaluated per item today.

Scope

• Final diff: ten workflow-templates/*.yaml assets only.
• No backend source changes.
• No frontend source, tests, styles, configuration, or dependency changes.
• No backend test files added or modified.
• No tracked implementation plan or design document added.

Explicit non-goals:

• No Lark bot trigger.
• No questions asked inside Lark.
• No answer or message sent to Lark.
• No Lark message or attachment search.
• No hardcoded Lark service ID, endpoint ID, slug, token, tenant, or document ID.
• No local vector index or document synchronization subsystem.

Verification

• Repository-independent YAML structure check:

  ruby -e 'require "yaml"; doc=YAML.safe_load(File.read(ARGV.fetch(0)), [], [], false); steps=doc.fetch("steps"); external=steps.select { |s| s["type"] == "tool_call" }; abort "wrong template shape" unless doc["name"] == "enterprise_knowledge_assistant" && doc.fetch("roles").length == 4 && steps.length == 12 && steps.map { |s| s.fetch("id") }.uniq.length == 12 && external.length == 4 && external.all? { |s| s.dig("parameters", "tool") == "nyxid_proxy" } && steps.none? { |s| s.key?("capability") }; puts "yaml_ok roles=4 steps=12 external_calls=4 capabilities=unbound"' workflow-templates/enterprise_knowledge_assistant.yaml

  Result: yaml_ok roles=4 steps=12 external_calls=4 capabilities=unbound.

• Repository parser, validator, authorization dependency compiler, and expression expansion check through a local one-off untracked harness:

  /Users/abigaildeng/.cache/codex-dotnet/10.0.100/dotnet run --project .planning/template-validator/template-validator.csproj --no-restore -- workflow-templates/enterprise_knowledge_assistant.yaml

  Result: success; 4 external invocations, all nyxid_proxy, all selectors unbound. The harness also expanded all four JSON argument templates with escaped sample values and parsed them successfully. Existing repository obsolete/complexity warnings were emitted; there were no errors.

• Final scope checks:

  git diff --check HEAD^ HEAD
  git diff --name-status feat/2026-08-04_workflow-activity-vnext...HEAD
  git diff feat/2026-08-04_workflow-activity-vnext...HEAD -- . ':(exclude)workflow-templates/*.yaml' --quiet

  Result: clean diff; exactly 10 added YAML files; no changes outside workflow-templates/.

No frontend validation was run because the final diff contains no frontend changes. Full repository validation remains with GitHub CI.

A live Lark request was not executed locally because it requires a deployed runtime, the caller's connected Lark service, and exact operation selection during workflow admission.