Add name field to TaskPromptDocument for human-readable identification #176

Original author: Josh Duffney (@duffney)

Problem

Task prompts are currently identified by a content-addressed UUIDv5 derived from the prompt text (e.g., a65ef13c-77cc-46b1-a632-08d87e24d117). This makes them idempotent and dedup-safe, but when looking at a list of runs or analysis results grouped by taskPromptId, the only way to know which task you are looking at is to read the full prompt text.

This matters for workflows like A/B comparisons where you run the same task prompt with different agent configurations (e.g., baseline vs. with-skills). You need to quickly find "all runs for the ecommerce-order-api task" — not scan UUIDs or full prompt paragraphs.

Proposal

Add an optional name (slug-style) field to TaskPromptDocument:

export interface TaskPromptDocument {
  _id: string;                          // UUIDv5 (unchanged, stays content-addressed)
  name?: string;                        // Human-readable slug, e.g. "cosmosdb-ecommerce-order-api"
  text: string;
  features?: PromptFeatureResult[];
  featuresExtractedAt?: Date;
  createdAt: Date;
  deletedAt?: Date;
}

Scope

Data layer:

• Add optional name?: string to TaskPromptDocument type
• Add rename(id: string, name: string) method to TaskPromptStore
• Accept name in findOrCreate() (set on create, ignored on existing match)

API:

• POST /api/v1/task-prompts — accept optional name in body
• PATCH /api/v1/task-prompts/:id — new endpoint to update name
• GET /api/v1/task-prompts — support ?search= matching against name in addition to text

CLI:

• task-prompt create — add --name <slug> option
• task-prompt list — display name column when present

Portal:

• Task prompt list page — show name as primary label (fall back to truncated text)
• Task prompt detail page — editable name field (inline edit or edit button)
• Task prompt create dialog — optional name input

What this does NOT include

• No changes to _id generation — it stays content-addressed by text
• No name uniqueness constraint (nice-to-have, not required)
• No changes to RequestDocument (run naming) — the task prompt name provides enough context for identifying what a group of runs was testing

Use case

# Create a named task prompt
pnpm cli task-prompt create --name "cosmosdb-ecommerce-order-api" --file scenarios/ecommerce.txt

# Submit baseline (no skills)
pnpm cli run submit --task-prompt cosmosdb-ecommerce-order-api --worker coder-acp-copilot

# Submit with skills
pnpm cli run submit --task-prompt cosmosdb-ecommerce-order-api --worker coder-acp-copilot \
  --skills AzureCosmosDB/cosmosdb-agent-kit/cosmosdb-best-practices

# All runs visible under the same named prompt in portal + analysis

Context

Builds on the completed #97 (task prompts as first-class entities). The content-addressed UUID stays as _id, this just adds a human-friendly label on top.