Which workflow templates should Aevatar ship?

[AbigailDeng]

@louis4li @ctkm-aelf, I would like your input before we define the first official Workflow templates.

Why this needs a product decision

The current Workflow Activity vNext UI exposes a frontend-bundled Incident triage example as if it were an official product template. Earlier template PRs were closed, so this example was reintroduced without a confirmed template set. A demo workflow should not silently become product content.

Proposed template contract

1. One authority: official templates come from the public Workflow template catalog, with a stable template ID and explicit version. The frontend should not maintain a separate hardcoded catalog.
2. Independent result: choosing a template creates a new editable workspace draft. Template identity, draft workflowId, and any published service identity remain separate.
3. Useful before impressive: every shipped template must solve a recognizable job end to end. It should not exist only to demonstrate node types.
4. Honest setup: required credentials, services, permissions, inputs, and human approval points must be visible before use. A template must never imply that an unavailable integration is ready.
5. Safe defaults: no embedded secrets, destructive actions disabled or confirmed, bounded retries, and an explicit failure path.
6. Operationally verified: the template parses, creates a draft, can be customized, and has a maintained acceptance test for its intended happy path.
7. Owned and reviewable: each template has a product owner, target user, maintenance owner, and a clear reason to remain in the catalog.
8. No placeholder default: if there are no approved templates, the UI should hide the template creation method or show an honest empty state instead of inventing one.

What I need from you

Please each propose the top 1–3 templates that real users need first. For every candidate, use this shape:

• Template name:
• Target user / role:
• Job to be done:
• Trigger and required input:
• Expected output / completion fact:
• Required integrations or credentials:
• Human review or approval point:
• What users are expected to customize:
• Acceptance scenario:
• Why this belongs in the official catalog:

A few product questions I would especially like you to answer:

• Should the first catalog optimize for onboarding examples, immediately useful production workflows, or both as visibly separate categories?
• Which Aevatar capabilities must the initial set demonstrate because they are strategically important?
• Which integrations can we rely on being available to a new user?
• Do we need organization-specific/private templates in the first iteration, or only public first-party templates?
• Who should approve and maintain a template after it ships?

Proposed next decision

After your replies, we can choose a deliberately small initial set, define metadata and preview requirements, and replace the current frontend placeholder with catalog-backed templates. Until then, Incident triage should be treated as a prototype example, not an approved official template.