Generic Host API for workspace-scoped automation execution history

[yontani]

Problem

Managed plugins can subscribe to automation events, but event delivery is best-effort and does not provide a complete restart/reconciliation inventory. Connectors for reporting, audit, calendars, or operational memory need a typed read surface for automation definitions and execution history.

I inspected main at dc2d77359f101fe398255112346b60c617477162. The public Host/SDK provides task/session/message readers, transition history, exact-query conventions, and managed-conversation schedule methods. The application also has automation.runs.list, including bounded run pages and retry-history views. I did not find a general plugin reader for those automation runs. An application WebSocket route or a database query should not become a connector's integration contract.

Proposed direction

An additive, optional, workspace-scoped Host reader for:

• automation definitions with safe schedule/timezone and trigger-kind projections;
• bounded execution/run pages;
• refreshing a known run by identity so a later completion does not depend on the original event.

The observations would preserve automation/trigger identity, task/session/turn links when present, source timestamps and original status, and retry-group/parent-attempt/attempt-number relationships. Taskless and skipped runs must remain representable without fabricated task IDs or success states.

Use public allowlisted DTOs, opaque query/workspace-bound cursors, explicit exhaustion and unsupported outcomes, existing capability discovery, and the appropriate workspace approval. Recheck access on continuation and omit secrets, request headers, raw trigger bodies and internal claim tokens. Existing managed-conversation schedule methods keep their contracts.

Ownership boundary

The Host extension would contain only generic reads, authorization, projection, pagination and capability discovery. Scheduling and execution stay with their current owners. Export selection, retention, provider calls, summaries, memory-bank routing and external retry policy stay in each consuming plugin. No provider-specific business logic belongs in Kandev core.

Draft design and questions

A draft requirements/design/work-order package is available in the fork: illuwa-soft#1

This is a design proposal; no runtime implementation or released API availability is claimed.

1. Is there an existing public Host surface intended for general automation execution history that I missed?
2. Would an optional extension following the existing exact-query/capability conventions be the preferred boundary?
3. Are there existing paging/snapshot and run-field contracts maintainers want this reader to reuse rather than duplicate?

[carlosflorencio]

Hey @yontani ,

Thanks for raising this discussion, yep we can extend the plugin api surface to include automations. Ideally the plugin api would cover all kandev features so all can be extended.

I'm preparing a PR with a HostAutomationHistory plugin SDK reader with three operations:

• ListAutomations: workspace automation definitions and safe trigger/schedule details.
• ListRuns: bounded, paginated execution history.
• GetRun: refresh a known run independently of event delivery.

The API will reuse workspace approvals and capability discovery, preserve run and retry identities, and exclude sensitive fields. Export and reconciliation policy remain plugin-owned.