Workflows: allow a caller-supplied title for each run

[ensembleworks-lsp]

The workflow

We run the saved behavior-preserving-refactor workflow once for each backlog
item. We want the Runs list and chat preview to identify the item being worked
on, for example refactor-r11-coach-component, while retaining
behavior-preserving-refactor as the underlying saved workflow name.

Typical callers are either:

bb workflows run --name behavior-preserving-refactor --args '{"item":"r11-coach-component"}'

or the equivalent bb_workflow_run agent tool call. The item-specific name is
valuable for monitoring several runs, correlating a run with the backlog, and
reading notifications without opening each run.

What happens today

Every run of the saved workflow is displayed with the same name,
behavior-preserving-refactor, including the runs list and chat preview. There
is no caller-facing override: bb workflows run has --name to select a saved
workflow, and bb_workflow_run has name for the same selection, but neither
has a separate display-name/run-name input.

This is also visible in the source:

• plugins/workflows/src/parser.ts: readMetadata validates meta.name with
  ^[a-z][a-z0-9-]{0,63}$ and rejects other metadata fields.
• plugins/workflows/src/service.ts: run creation passes
  name: parsed.metadata.name to createRun.
• plugins/workflows/src/cli.ts: source selection maps --name to the saved
  workflow selector; there is no title/run-name option.
• plugins/workflows/src/runtime.ts: phase(title) updates the run's phase,
  not its name.

The released bundle shows the same path in
~/.npm/_npx/*/node_modules/bb-app/server/dist/builtin-plugins/workflows/dist/server.js:
readMetadata, createRun, and updateRunPhase are separate operations, and
run creation stores name: parsed.metadata.name.

What you would expect

Please provide a supported way to set a per-run display title independently of
the workflow identity. It should appear anywhere the current run name appears,
including the Runs list and chat preview, and should remain available in
status/list output where the run name is reported.

Possible API shapes, in preference order:

(a) Caller-supplied title (recommended)

Add an optional title (or runName) input to both bb workflows run and
bb_workflow_run. For example:

bb workflows run \
  --name behavior-preserving-refactor \
  --title refactor-r11-coach-component \
  --args '{"item":"r11-coach-component"}'

The persisted run could retain both fields, e.g. workflowName (or the
existing name) and title, with existing behavior as the fallback when the
optional title is omitted.

(b) Runtime title setter

Allow the script to set the title explicitly, for example:

title("R11 coach-component");
phase("Inspecting");

This is useful when the title is computed from validated args, though it
would make the initial Runs-list name timing and title validation part of the
runtime contract.

(c) Template meta.name from args

Allow a constrained template form that derives the display name from args.
This is compact, but couples workflow metadata/identity to each invocation and
would need clear escaping, validation, and source/cache semantics.

Option (a) seems the least surprising and most compatible: it keeps a stable
saved-workflow identity for discovery/grouping while adding an invocation
identity for humans and automation. A bounded, validated title (with the
existing name as fallback) would be sufficient.

Context and alternatives

Our current workaround is to generate a per-item inline wrapper script whose
literal meta.name is the item name and whose body delegates to the saved
workflow:

export const meta = {
  name: "refactor-r11-coach-component",
  description: "Run behavior-preserving-refactor for one backlog item",
  // copied from the saved workflow so the progress stepper still renders
  phases: [{ title: "Assess quality" }, { title: "Refactor" }, { title: "Gate" },
           { title: "Verify behavior" }, { title: "Reassess quality" }, { title: "Land" }],
};

return await workflow("behavior-preserving-refactor", args);

Nested workflows share the run, so this produces the desired display name. The
cost is a generated 12-line script for every launch, and bb workflows list
cannot group those runs by their underlying saved workflow. It also makes a
human-facing naming concern affect the workflow source/hash rather than being
an invocation-level field.

I searched the open and closed issues for workflow run name, workflow title,
workflow naming, run titles, and meta.name, and searched Discussions for
the same terms. I found no direct duplicate. Related results, such as issue
1868 about workflow progress rendering and issue 1366 about workflow workers,
do not request per-run titles.

Environment: bb-app 0.40.0; repository package directory
packages/bb-app; repository https://github.com/get-bb/bb.

Checks

• I searched open and closed issues for the same request.
• If an agent wrote this, the body ends with > AGENT GENERATED.

AGENT GENERATED

[bb-slop-cop]

🚨 SLOP COP 🚨 · new-issue-autopilot

• Type: Feature
• Priority: Medium
• Effort: High
• Labels: cli, plugins, workflows

Pull request: None. This feature needs a product and stored-data design.