feat: add the production interface manifest - #432
Conversation
| { "pattern": "^[^{}]*\\{id\\}[^{}]*$" } | ||
| ] | ||
| }, | ||
| "editField": { |
There was a problem hiding this comment.
Are these... properties or attributes of an automation? Or "variables" for the user to fill in or to select?
If so, could we name this "attributes" or "variables"?
It's a UI-specific concern that it happens to be represented on agent-canvas side by an edit field. If the agent uses this interface via API, "editField" seems a bit of an awkward fit
There was a problem hiding this comment.
Since these represent attributes of an automation—the keys are the runtime model properties themselves—I renamed the $defs.editField definition to attribute and added the following description: "How one settable attribute is offered: a semantic input type, user-visible copy, and value constraints."
I also updated the corresponding TypeScript types for consistency:
AutomationEditField*→AutomationAttribute*AutomationEditableProperty→AutomationAttributeNameAutomationInterfaceEdit→AutomationInterfaceAttributes
These changes were applied in both automations/index.d.ts and the root index.d.ts re-exports.
Thank you very much! 🙏
| "pattern": "^https://docs\\.openhands\\.dev/[A-Za-z0-9/._-]*$" | ||
| }, | ||
| "edit": { | ||
| "description": "The edit dialog: which Automation properties it offers, keyed by the property each field edits. The closed key set is the editable surface of the runtime model; schedule is a semantic type whose frequency/weekday/time composite the host owns, like the setup form's cron type.", |
There was a problem hiding this comment.
From what I'm reading, "edit" and "editable" means "input", right? Input from the user. What if we say, idk, like:
"variables": {
"description": "The input for an Automation: which variables it offers, keyed by the variable the user or agent can send. The closed key set is the input surface of the runtime model; schedule ..."
There was a problem hiding this comment.
Agreed. I reframed it to represent the input surface exactly as discussed, with one terminology change: I used attributes (your other suggestion) instead of variables. In this package, variables already refers to the setup form's {{form.<name>}} template variables, whereas these represent something different—the runtime model's own properties, which can be updated on an existing automation.
The block is now a top-level attributes map keyed by the runtime model property. It is described as the input surface, while leaving the presentation up to the client—for example, Canvas may render an edit dialog, whereas an agent may provide the values through the API. I also moved the previous dialog title into pages, alongside the rest of the page identity copy.
Thank you very much! 🙏
There was a problem hiding this comment.
Thank you for this! It clarifies a lot and seems to allow us to play with Automations better, even design a new UI for them on the basis of this lot of structured information.
I left a few comments inline, basically on the "edit fields": those don't sound like domain-level Automation definition, they're particular UI-specific, that is, they belong on agent-canvas side. Agent-canvas can choose edit fields for receiving input. But the Automation is not made of edit fields, it seems to me, it would be made of inputs, or variables.
If I may put this differently, if I take a step back and imagine the agents working with Automations (they don't necessarily use canvas), it would nice for them to have a clean and explicit domain structure. That will include inputs, it seems to me.
|
Hello @enyst, I've updated the code based on your feedback. When you have a chance, could you please take another look at the pull request? Thank you very much! 🙏 |
enyst
left a comment
enyst
left a comment
There was a problem hiding this comment.
I'm curious how easy will the agent work with it now. We'll see 😅
Thank you!
3 participants
Why
Promotes extension-owned data into the production Automation interface. The merged setup contract (#423) deliberately modeled only the per-entry
setupblock, so every domain-level fact — routes, navigation, page copy, the settable attributes, the import/export envelope, endpoint paths, the proven/responder groupings — still lived hardcoded in Agent Canvas. This PR gives those facts one extension-owned home, stated once at the domain level rather than eight times per entry, and adds the assisted fallback the acceptance criteria require for deployments that cannot run direct setup.Summary
automations/interface.json(the production interface manifest) andautomations/interface.schema.json(its strict contract), exported asAUTOMATION_INTERFACEwith full typings from./automationsand the root entry, plus packageexportsentries for both files.messageonmode:"direct"setup entries — the seed for the fallback conversation offered when a deployment's capabilities preclude the direct path — and add fallback messages togithub-pr-reviewerandgithub-repo-monitor.automations/README.md(ownership rules, trust boundary, deviation-table updates) and addtests/test_interface_manifest.py(12 tests: schema validity, manifest conformance, mutation rejections, catalog cross-references, fallback messages, node export smoke).Issue Number
Resolves #421
How to Test
uv sync --group testuv run --group test pytest tests/ -q— 512 passed, 6 skipped, including the newtests/test_interface_manifest.py.node --input-type=module -e "import('./automations/index.js').then(m => console.log(m.AUTOMATION_INTERFACE.routes))"prints the three routes.npm run build:automations—automations/catalog-index.jsis unchanged (the two manifest edits are content-only).Video/Screenshots
Not applicable — data/contract change; the pytest run above is the verification.
Notes
AUTOMATION_INTERFACEdefensively (absent → host defaults), so this releases independently of the Canvas PR./v1/preset/prompt; a future change toendpoints.createPromptmust regenerate them in the same release (noted in the README section).