Feature request: configurable Scheduled Issue workflows and multi-model credentials

[dbydd]

Summary

Two current limitations make long-running, role-separated Scheduled Issue workflows difficult:

1. every Scheduled Issue run has the same hard-coded 30-minute watchdog, and an Issue cannot declare a different execution budget or a cleanup/finalizer stage;
2. one {provider/vendor, auth type, API key} credential can remember and project only one model, although the underlying provider endpoint and key may expose several models suited to different roles.

These are useful independently, but together they block a common workflow: run a stronger research model for the main task, then reserve a smaller/faster model to consolidate partial output, commit artifacts, and deliver an Inbox report even when the primary step fails or times out.

Current behavior

Verified against dev commit 6fba9daae483755b3fe7f7c5c7973c62b82b947b.

Scheduled Issue execution

• src/workspaces/issues/run-failure.ts defines SCHEDULED_ISSUE_RUN_TIMEOUT_MS = 30 * 60_000.
• src/workspaces/schedule/scanner.ts passes that constant to both fresh and resumed dispatch paths.
• src/workspaces/issues/declaration.ts accepts title, status, priority, assignee, when, and optional agent, but no execution-budget or workflow field.

When a research/reporting task reaches the watchdog, the runtime is terminated before it can reliably consolidate partial results, commit generated artifacts, or publish its final Inbox report. Raising the global constant would only move the problem and would make every Scheduled Issue share the same policy.

Provider/model persistence

• credentials are intentionally deduplicated by {vendor, authType, apiKey} in src/core/config.ts;
• a credential only stores lastModel: string, and a Workspace default only stores model: string;
• src/workspaces/adapters/pi-config.ts projects a configured Workspace provider as models: [model], a one-element array.

As a result, saving another model for the same endpoint/key updates the remembered/default model and the OpenAlice-managed Pi provider still exposes only one model. Users must duplicate credentials or manually maintain Pi configuration, and OpenAlice reconciliation may later replace that manual projection.

Pi already supports multiple entries in a provider's models[]; this appears to be an OpenAlice data-model/UI/projection limitation rather than an Agent Runtime limitation.

Proposed behavior

1. Per-Issue execution budget and optional workflow chain

Add a validated, human-editable execution budget to Scheduled Issue frontmatter. A duration string is easier to review in Markdown than raw milliseconds, for example:

---
title: Weekly market research
when: { kind: cron, cron: "0 20 * * 0", timezone: Asia/Shanghai }
assignee: "@workspace"
timeout: 60m
agent: pi
---

When omitted, retain the current 30-minute default for backward compatibility. The effective budget should be used by dispatch, failure classification, Automation UI, retry/run-now, and persisted run metadata.

Also consider an optional sequential workflow declaration with an always finalizer:

workflow:
  - id: research
    agent: pi
    model: generic-researcher
    timeout: 50m
  - id: finalize
    agent: pi
    model: flash-vibe
    timeout: 10m
    run: always

The exact schema is open for design. The important behavior is:

• steps execute in a declared order and each has an independently enforced budget;
• an always finalizer runs after success, failure, or primary-step timeout, provided the launcher is still available;
• the finalizer receives structured prior-step status plus artifact/log references, not an unbounded transcript;
• the finalizer can consolidate partial work and perform the Issue's required commit/Inbox delivery, but must not rewrite a failed primary step as success;
• step status and aggregate workflow status remain visible in Runs/Automation health and provenance;
• retries do not accidentally dispatch duplicate finalizers;
• existing single-agent Issue files continue to behave exactly as today.

A smaller first increment could add only timeout; the workflow schema can follow without changing that field's contract.

2. Multiple models for one credential/provider

Keep one credential/key and one wire/endpoint set, but let it own or reference a model catalog separate from lastModel, for example conceptually:

{
  "models": [
    { "id": "generic-researcher", "contextWindow": 256000, "reasoning": true },
    { "id": "flash-vibe", "contextWindow": 128000, "reasoning": true }
  ],
  "lastModel": "generic-researcher"
}

lastModel can remain a convenience/default. Global per-agent and per-Workspace settings should still select one scalar default model, while the OpenAlice-managed provider projects every configured model into Pi's models[]. Workflow steps and interactive model switching can then select another model without duplicating the API key.

The UI should support adding/removing model IDs and model-specific capabilities for a credential/provider, selecting one default, and testing models independently. Updating one model must not silently drop the others.

For runtimes that only support one selected model per Workspace, OpenAlice can still inject the chosen default while preserving the shared catalog for runtimes such as Pi that support it.

Acceptance criteria

• A Scheduled Issue can override the 30-minute execution budget through validated frontmatter; invalid or unsafe values fail loudly.
• The effective budget is honored consistently by dispatch, timeout reporting, run-now/retry, and Automation UI.
• Optional workflow steps can reserve a bounded finalizer that runs after primary success/failure/timeout and records per-step provenance.
• Existing Issue files without new fields retain current behavior.
• One deduplicated credential/key can expose multiple model IDs without secret duplication.
• Pi's OpenAlice-managed provider contains all configured models in models[], while project/global defaults still select one model.
• Model-specific context/reasoning metadata round-trips through storage and UI.
• Saving, resetting, offboarding, or reconciling one Workspace does not drop sibling models or overwrite unrelated user-managed providers.
• Existing single-model credentials migrate without user action, using the current model as the initial catalog/default.

Why this matters

Long-running research, reporting, and data-processing Issues often need more than 30 minutes, but simply increasing a global watchdog reduces failure isolation. A per-Issue budget plus a reserved finalizer gives predictable completion behavior. Multi-model credentials then let the workflow use the same trusted endpoint/key with different cost/latency/capability profiles, without duplicating secrets or fighting generated Pi configuration.