lhumina_code/hero_archipelagos
21
0
Fork 0
Code Issues 4 Pull requests Projects Releases Packages Wiki Activity Actions

Intelligent automation app #40

New issue
Open
opened 2026-03-25 10:01:51 +00:00 by timur · 3 comments
timur commented 2026-03-25 10:01:51 +00:00
Owner
Copy link

We want to create an app where we can create workflows of rhai scripts, ai execution, etc. Perhaps as part of a larger ai app, where people can define agents, roles, workflows that roles can implement etc. The idea is that then bots can be brought alive then can listen to events, or be manually triggered to execute these workflows. These will be control flow graphs, and an example use case is having a role such as QA Engineer defined with this workflow as a functionality of that role, then having a QA Engineer bot instance that listens to commits and then runs a CFG, nodes of which use ai, some are rhai script nodes etc. This uses hero_proc behind the scenes as hero_proc now supports running ai and rhai scripts.

There are already existing archipelagos / islands for creating bots and roles etc. lets make sure we integrate all of these into single archipelago, since all are related. there may even be some functionality for workflows already that we can use.

We should send rhai scripts to hero_proc over hero_proxy and these rhai scripts should contain the instructions for creating bots / roles / these graphs with nodes etc, so then when the rhai script is run by hero_proc the necessary db stuff is created. hero_proc and rhai scripts currently use sqlite for backend but lets also explore how we can get it to use osis like hero_rpc servers use it.

Lets first explore existing code, where things are, come up with questions that need to be answered to understand the issue correctly.

We want to create an app where we can create workflows of rhai scripts, ai execution, etc. Perhaps as part of a larger ai app, where people can define agents, roles, workflows that roles can implement etc. The idea is that then bots can be brought alive then can listen to events, or be manually triggered to execute these workflows. These will be control flow graphs, and an example use case is having a role such as QA Engineer defined with this workflow as a functionality of that role, then having a QA Engineer bot instance that listens to commits and then runs a CFG, nodes of which use ai, some are rhai script nodes etc. This uses [hero_proc](https://forge.ourworld.tf/lhumina_code/hero_proc) behind the scenes as hero_proc now supports running ai and rhai scripts. There are already existing archipelagos / islands for creating bots and roles etc. lets make sure we integrate all of these into single archipelago, since all are related. there may even be some functionality for workflows already that we can use. We should send rhai scripts to hero_proc over [hero_proxy](https://forge.ourworld.tf/lhumina_code/hero_proxy) and these rhai scripts should contain the instructions for creating bots / roles / these graphs with nodes etc, so then when the rhai script is run by hero_proc the necessary db stuff is created. hero_proc and rhai scripts currently use sqlite for backend but lets also explore how we can get it to use osis like [hero_rpc](https://forge.ourworld.tf/lhumina_code/hero_rpc) servers use it. Lets first explore existing code, where things are, come up with questions that need to be answered to understand the issue correctly.
timur commented 2026-03-25 13:31:22 +00:00
Author
Owner
Copy link

Exploration Report & Questions

What Already Exists

1. Intelligence Archipelago (hero_archipelagos)

The intelligence archipelago already consolidates these islands into a tabbed hub:

  • Agents — Define agent capabilities, each with a workflow_id reference
  • Bots/Roles — Runtime agent instances with personality, avatar, state (idle/thinking/acting/waiting/error/offline)
  • Knowledge — RAG buckets via embedder (create, sync, semantic search)
  • Templates — Prompt templates with variables
  • MCP Servers — External tool server configuration
  • Chat — Direct AI conversation interface
  • Activity — Activity feed/logging

2. Flow Domain Types (hero_osis_sdk)

The SDK already defines a complete DAG-based workflow system in the flow domain:

  • Workflow — Root object with steps: Vec<WorkflowStep>, entry_step, inputs/outputs, versioning

  • WorkflowStep — Supports 8 step types:

    • prompt — LLM call with system/user prompts, model config, variable interpolation ({{var}})
    • tool_call — External tool invocation (MCP, builtin, or sub-workflow)
    • condition — Branching logic (if/else with operators: equals, contains, regex, gt, lt, etc.)
    • parallel — Execute branches concurrently with merge strategies
    • loop — for_each, while, or count-based iteration
    • subworkflow — Call another workflow
    • transform — Data transformation
    • output — Return values

  • Steps have position_x/position_y fields — designed for a visual node editor

  • Steps link via next_step and on_error (step IDs)

  • WorkflowExecution — Tracks runtime: status, current step, variables, step snapshots

  • StepExecution — Per-step tracking: input/output snapshots, timing, retries

  • AgentCapability.workflow_id — Links agents to workflows (the binding already exists)

3. Hero Proc

  • Process supervisor with Rhai scripting engine embedded
  • Has Job, Run, Action, Service concepts with dependency graphs
  • SQLite storage, OpenRPC API over Unix sockets
  • Rhai scripts can manage services, do network ops, SSH, etc.

4. Hero Proxy

  • HTTP reverse proxy routing by URL prefix to Unix socket services
  • Service discovery + health monitoring
  • Can proxy to hero_proc and all other hero services

What Needs To Be Built

Based on the issue description and existing code, the main gaps are:

  1. Workflow Editor UI — A visual node-graph editor for creating/editing Workflow objects (the types exist but no UI)
  2. Workflow Execution Monitoring UI — View WorkflowExecution status in real-time
  3. Integration of Workflows tab into the Intelligence archipelago hub
  4. Rhai script node support — tool_call steps that send Rhai scripts to hero_proc
  5. Event/trigger system — Bots listening to events (commits, messages, etc.) and auto-triggering workflows
  6. Hero Proc ↔ OSIS bridge — Connecting hero_proc's execution to OSIS-managed workflow definitions

Questions That Need Answers

Architecture:

  1. Workflow execution engine location — The Workflow types live in hero_osis, but the issue says hero_proc runs AI and Rhai. Where should the workflow execution engine live?

    • (a) In hero_osis_server (owns the types, natural home)
    • (b) In hero_proc (the issue suggests this)
    • (c) A new dedicated service (e.g., hero_flow_engine)
    • My read: hero_osis_server already has the types and WorkflowExecution tracking. hero_proc could be the executor for individual steps (especially Rhai/process steps), while hero_osis orchestrates the DAG.

  2. Rhai script generation vs direct execution — Should the workflow editor:

    • (a) Generate a single Rhai script that encodes the entire workflow graph, send it to hero_proc
    • (b) Have the orchestrator walk the DAG and send individual Rhai scripts per tool_call step to hero_proc
    • Option (b) seems cleaner since the DAG logic (conditions, parallel, loops) would be handled by the orchestrator, and hero_proc just executes atomic scripts.

  3. Hero Proc AI support — The issue says "hero_proc now supports running ai and rhai scripts." From exploration, hero_proc is a process supervisor. How does it execute AI calls? Does it:

    • (a) Run Rhai scripts that themselves call AI APIs?
    • (b) Have new built-in AI execution capabilities not yet in the codebase?
    • (c) Delegate to another service?

Data & Storage:

  1. OSIS vs SQLite for hero_proc — The issue mentions exploring OSIS for hero_proc's storage. Is this:

    • (a) A prerequisite for this feature (must be done first)
    • (b) A future enhancement (SQLite fine for now)
    • (c) Only needed for workflow-related data (hero_proc keeps SQLite for its core process management)

  2. Workflow state persistence — Should WorkflowExecution state live in:

    • (a) hero_osis (where the workflow definitions are)
    • (b) hero_proc's SQLite/OSIS (where execution happens)
    • (c) Both (definition in OSIS, runtime state in hero_proc)

Events & Triggers:

  1. Event system — For bots to "listen to events" (e.g., commits), what event infrastructure exists?

    • Is there a pub/sub system, webhook receiver, or event bus?
    • Or does this need to be built? (e.g., a webhook endpoint that maps events → bot workflow triggers)
    • Could hero_proc's scheduler be extended for event-driven triggers?

  2. Event sources — What events should bots listen to initially?

    • Forgejo webhooks (commits, PRs, issues)?
    • Internal hero service events?
    • Manual triggers only for MVP?

UI & Scope:

  1. Visual graph editor approach — For the workflow node editor:

    • (a) Build from scratch in Dioxus/RSX (fits the archipelago pattern, but complex)
    • (b) Use an existing JS graph library (e.g., ReactFlow, xyflow) via web component embedding
    • (c) Start with a simpler list/form-based workflow builder, add visual editor later

  2. Consolidation scope — The issue says "integrate all into a single archipelago." The Intelligence archipelago already consolidates agents, roles, knowledge, templates, servers, chat, activity. What else needs merging? Are there islands outside the intelligence archipelago that should move in?

  3. MVP scope — For the first iteration, should we focus on:

    • (a) Workflow CRUD UI + manual execution (no event triggers yet)
    • (b) Full pipeline: workflow editor + bot triggers + event system
    • (c) Something else?

Proposed Architecture (For Discussion)

┌─────────────────────────────────────────────┐
│          Intelligence Archipelago            │
│  ┌─────────┐ ┌──────┐ ┌─────────┐          │
│  │ Agents  │ │ Bots │ │Workflows│ (NEW)    │
│  │  tab    │ │ tab  │ │  tab    │          │
│  └────┬────┘ └──┬───┘ └────┬────┘          │
│       │         │          │                │
│       └────┬────┘     Visual DAG Editor     │
│            │          (node graph UI)       │
│     AgentCapability                         │
│       .workflow_id ──────► Workflow          │
└────────────┬────────────────┬───────────────┘
             │                │
        hero_osis_sdk    hero_osis_sdk
        (AI domain)      (Flow domain)
             │                │
┌────────────┴────────────────┴───────────────┐
│            hero_osis_server                  │
│     Orchestrates DAG execution               │
│     Stores Workflows & Executions            │
└─────────────────┬───────────────────────────┘
                  │ (for rhai/process steps)
                  ▼
┌─────────────────────────────────────────────┐
│            hero_proxy                        │
│     Routes to hero_proc                      │
└─────────────────┬───────────────────────────┘
                  ▼
┌─────────────────────────────────────────────┐
│            hero_proc                         │
│     Executes Rhai scripts & processes        │
│     Reports results back                     │
└─────────────────────────────────────────────┘

Awaiting answers to these questions before proceeding with implementation.

## Exploration Report & Questions ### What Already Exists #### 1. Intelligence Archipelago (hero_archipelagos) The `intelligence` archipelago already consolidates these islands into a tabbed hub: - **Agents** — Define agent capabilities, each with a `workflow_id` reference - **Bots/Roles** — Runtime agent instances with personality, avatar, state (`idle`/`thinking`/`acting`/`waiting`/`error`/`offline`) - **Knowledge** — RAG buckets via embedder (create, sync, semantic search) - **Templates** — Prompt templates with variables - **MCP Servers** — External tool server configuration - **Chat** — Direct AI conversation interface - **Activity** — Activity feed/logging #### 2. Flow Domain Types (hero_osis_sdk) The SDK already defines a complete **DAG-based workflow system** in the `flow` domain: - **`Workflow`** — Root object with `steps: Vec<WorkflowStep>`, `entry_step`, inputs/outputs, versioning - **`WorkflowStep`** — Supports 8 step types: - `prompt` — LLM call with system/user prompts, model config, variable interpolation (`{{var}}`) - `tool_call` — External tool invocation (MCP, builtin, or sub-workflow) - `condition` — Branching logic (if/else with operators: equals, contains, regex, gt, lt, etc.) - `parallel` — Execute branches concurrently with merge strategies - `loop` — for_each, while, or count-based iteration - `subworkflow` — Call another workflow - `transform` — Data transformation - `output` — Return values - Steps have `position_x`/`position_y` fields — **designed for a visual node editor** - Steps link via `next_step` and `on_error` (step IDs) - **`WorkflowExecution`** — Tracks runtime: status, current step, variables, step snapshots - **`StepExecution`** — Per-step tracking: input/output snapshots, timing, retries - **`AgentCapability.workflow_id`** — Links agents to workflows (the binding already exists) #### 3. Hero Proc - Process supervisor with Rhai scripting engine embedded - Has `Job`, `Run`, `Action`, `Service` concepts with dependency graphs - SQLite storage, OpenRPC API over Unix sockets - Rhai scripts can manage services, do network ops, SSH, etc. #### 4. Hero Proxy - HTTP reverse proxy routing by URL prefix to Unix socket services - Service discovery + health monitoring - Can proxy to hero_proc and all other hero services --- ### What Needs To Be Built Based on the issue description and existing code, the main gaps are: 1. **Workflow Editor UI** — A visual node-graph editor for creating/editing `Workflow` objects (the types exist but no UI) 2. **Workflow Execution Monitoring UI** — View `WorkflowExecution` status in real-time 3. **Integration of Workflows tab** into the Intelligence archipelago hub 4. **Rhai script node support** — `tool_call` steps that send Rhai scripts to hero_proc 5. **Event/trigger system** — Bots listening to events (commits, messages, etc.) and auto-triggering workflows 6. **Hero Proc ↔ OSIS bridge** — Connecting hero_proc's execution to OSIS-managed workflow definitions --- ### Questions That Need Answers **Architecture:** 1. **Workflow execution engine location** — The `Workflow` types live in hero_osis, but the issue says hero_proc runs AI and Rhai. Where should the workflow execution engine live? - (a) In hero_osis_server (owns the types, natural home) - (b) In hero_proc (the issue suggests this) - (c) A new dedicated service (e.g., hero_flow_engine) - My read: hero_osis_server already has the types and `WorkflowExecution` tracking. hero_proc could be the *executor* for individual steps (especially Rhai/process steps), while hero_osis orchestrates the DAG. 2. **Rhai script generation vs direct execution** — Should the workflow editor: - (a) Generate a single Rhai script that encodes the entire workflow graph, send it to hero_proc - (b) Have the orchestrator walk the DAG and send individual Rhai scripts per `tool_call` step to hero_proc - Option (b) seems cleaner since the DAG logic (conditions, parallel, loops) would be handled by the orchestrator, and hero_proc just executes atomic scripts. 3. **Hero Proc AI support** — The issue says "hero_proc now supports running ai and rhai scripts." From exploration, hero_proc is a process supervisor. How does it execute AI calls? Does it: - (a) Run Rhai scripts that themselves call AI APIs? - (b) Have new built-in AI execution capabilities not yet in the codebase? - (c) Delegate to another service? **Data & Storage:** 4. **OSIS vs SQLite for hero_proc** — The issue mentions exploring OSIS for hero_proc's storage. Is this: - (a) A prerequisite for this feature (must be done first) - (b) A future enhancement (SQLite fine for now) - (c) Only needed for workflow-related data (hero_proc keeps SQLite for its core process management) 5. **Workflow state persistence** — Should `WorkflowExecution` state live in: - (a) hero_osis (where the workflow definitions are) - (b) hero_proc's SQLite/OSIS (where execution happens) - (c) Both (definition in OSIS, runtime state in hero_proc) **Events & Triggers:** 6. **Event system** — For bots to "listen to events" (e.g., commits), what event infrastructure exists? - Is there a pub/sub system, webhook receiver, or event bus? - Or does this need to be built? (e.g., a webhook endpoint that maps events → bot workflow triggers) - Could hero_proc's scheduler be extended for event-driven triggers? 7. **Event sources** — What events should bots listen to initially? - Forgejo webhooks (commits, PRs, issues)? - Internal hero service events? - Manual triggers only for MVP? **UI & Scope:** 8. **Visual graph editor approach** — For the workflow node editor: - (a) Build from scratch in Dioxus/RSX (fits the archipelago pattern, but complex) - (b) Use an existing JS graph library (e.g., ReactFlow, xyflow) via web component embedding - (c) Start with a simpler list/form-based workflow builder, add visual editor later 9. **Consolidation scope** — The issue says "integrate all into a single archipelago." The Intelligence archipelago already consolidates agents, roles, knowledge, templates, servers, chat, activity. What else needs merging? Are there islands outside the intelligence archipelago that should move in? 10. **MVP scope** — For the first iteration, should we focus on: - (a) Workflow CRUD UI + manual execution (no event triggers yet) - (b) Full pipeline: workflow editor + bot triggers + event system - (c) Something else? --- ### Proposed Architecture (For Discussion) ``` ┌─────────────────────────────────────────────┐ │ Intelligence Archipelago │ │ ┌─────────┐ ┌──────┐ ┌─────────┐ │ │ │ Agents │ │ Bots │ │Workflows│ (NEW) │ │ │ tab │ │ tab │ │ tab │ │ │ └────┬────┘ └──┬───┘ └────┬────┘ │ │ │ │ │ │ │ └────┬────┘ Visual DAG Editor │ │ │ (node graph UI) │ │ AgentCapability │ │ .workflow_id ──────► Workflow │ └────────────┬────────────────┬───────────────┘ │ │ hero_osis_sdk hero_osis_sdk (AI domain) (Flow domain) │ │ ┌────────────┴────────────────┴───────────────┐ │ hero_osis_server │ │ Orchestrates DAG execution │ │ Stores Workflows & Executions │ └─────────────────┬───────────────────────────┘ │ (for rhai/process steps) ▼ ┌─────────────────────────────────────────────┐ │ hero_proxy │ │ Routes to hero_proc │ └─────────────────┬───────────────────────────┘ ▼ ┌─────────────────────────────────────────────┐ │ hero_proc │ │ Executes Rhai scripts & processes │ │ Reports results back │ └─────────────────────────────────────────────┘ ``` Awaiting answers to these questions before proceeding with implementation.
timur commented 2026-03-25 13:48:21 +00:00
Author
Owner
Copy link
  1. hero proc already has dag orchestration too, so maybe best use that entirely? later hero_osis can become the data layer for hero_proc instead of the current sqlite. open an issue for this where relavant and place in backlog
  2. neither, but closer to a. should generate a single rhai script, which when run generates the steps and workflow in the hero_proc db. basically that rhai script would be one that defines the workflow, when run puts the workflow in state (this is also where it would be ideal to use osis since per root object the rhai script engine module can also be generated to directly save and fetch that object from osis)
  3. read hero_proc code and understand.
  4. lets explore how we might switch to osis, as mentioned, and create a issue
  5. hero_procs osis. basically osis saves to same location so doesnt really matter if hero_procs osis or osis they would be saving to same place same way anyways if in same context namespace.
  6. create an issue for this to research, nothing exists yet.
  7. there should be a generic way to configure and add events, and all you mentioned should also be events that can be added. so many different inputs from different sources should be able to be configured as events. this also needs issue
  8. a. but perhaps no need to keep position x position y etc in model that unnecessaarily complicates and is not necessary to save state of node in view
  9. if its in same archipelago, no problem
  10. b
1. hero proc already has dag orchestration too, so maybe best use that entirely? later hero_osis can become the data layer for hero_proc instead of the current sqlite. open an issue for this where relavant and place in backlog 2. neither, but closer to a. should generate a single rhai script, which when run generates the steps and workflow in the hero_proc db. basically that rhai script would be one that defines the workflow, when run puts the workflow in state (this is also where it would be ideal to use osis since per root object the rhai script engine module can also be generated to directly save and fetch that object from osis) 3. read hero_proc code and understand. 4. lets explore how we might switch to osis, as mentioned, and create a issue 5. hero_procs osis. basically osis saves to same location so doesnt really matter if hero_procs osis or osis they would be saving to same place same way anyways if in same context namespace. 6. create an issue for this to research, nothing exists yet. 7. there should be a generic way to configure and add events, and all you mentioned should also be events that can be added. so many different inputs from different sources should be able to be configured as events. this also needs issue 8. a. but perhaps no need to keep position x position y etc in model that unnecessaarily complicates and is not necessary to save state of node in view 9. if its in same archipelago, no problem 10. b
timur commented 2026-03-25 14:15:12 +00:00
Author
Owner
Copy link

Implementation Progress

Completed

1. Workflows tab added to Intelligence Archipelago

  • New Workflows tab in the intelligence island hub (between Templates and Servers)
  • Full tab navigation, icon, metadata, and view registration

2. Workflow Service Layer (workflow_service.rs)

  • Uses FlowClient from hero_osis_sdk (flow domain)
  • Full CRUD: fetch_workflows, create_workflow, save_workflow, delete_workflow
  • Execution: execute_workflow, get_execution
  • Validation: validate_workflow
  • Published listing: fetch_published_workflows

3. Visual DAG Workflow Editor (workflow_graph.rs)

  • Automatic topological layout (no position persistence per your feedback)
  • SVG-based node rendering with curved edge connections
  • Color-coded step types: AI Prompt (purple), Tool/Script (blue), Condition (amber), Parallel (green), Loop (pink), Transform (teal), Output (gray)
  • Toolbar to add any step type
  • Entry step indicator, error path visualization (dashed red edges)
  • Click to select nodes, delete nodes

4. Workflow Editor (workflow_editor.rs)

  • Full-screen modal with 3 panels: Metadata, Graph, Step Config
  • Metadata panel: name, description, version, icon, published toggle
  • Graph panel: the visual DAG editor
  • Step Config panel: step-type-specific forms
    • AI Prompt: system prompt, user prompt (with {{variable}} support), model, output variable
    • Tool Call: source selector (builtin/MCP/workflow), tool name/script, output variable
    • Other step types: placeholder forms (condition, parallel, loop configs coming next)
  • Auto-wiring: new steps connect to the previous step automatically
  • Step deletion with reference cleanup

5. Workflow List (workflow_list.rs)

  • Card grid showing all workflows
  • Shows: name, version, icon, description, step type badges (AI count, tool count, condition count), published status
  • Actions: execute, edit, delete per workflow
  • Empty state with guidance

6. Rhai Script Generation (rhai_codegen.rs)

  • generate_rhai_script(workflow) takes a Workflow and produces a Rhai script
  • Generated script connects to hero_proc and creates:
    • Actions with depends_on relationships for each WorkflowStep
    • Jobs from those actions
    • A Run to orchestrate all jobs
  • Maps step types to appropriate interpreters (bash for prompts/tools, rhai for transforms)
  • Handles dependency graph: if A→B, then B requires A

Issues Created

Build Status

cargo check -p hero_archipelagos_intelligence passes clean (only pre-existing warnings from other code).

Files Changed/Created

New files:

  • src/services/workflow_service.rs — OSIS FlowClient CRUD
  • src/services/rhai_codegen.rs — Rhai script generation for hero_proc
  • src/views/workflows/mod.rs — Module root
  • src/views/workflows/workflow_list.rs — Workflow card grid
  • src/views/workflows/workflow_editor.rs — Full editor with graph + forms
  • src/views/workflows/workflow_graph.rs — Visual DAG editor
  • src/views/tabs/workflows_tab.rs — Tab wrapper

Modified files:

  • Cargo.toml — Added flow feature to hero_osis_sdk
  • src/state.rs — Added Workflows to ActiveTab enum
  • src/services/mod.rs — Registered new service modules
  • src/views/mod.rs — Registered workflows view module
  • src/views/tabs/mod.rs — Registered workflows tab
  • src/island.rs — Wired Workflows tab (state, data loading, rendering, metadata)
  • src/lib.rs — Added workflows to get_metadata JSON

Next Steps

  • Condition/parallel/loop step config forms (advanced editor panels)
  • Workflow execution monitoring UI (watch WorkflowExecution status)
  • Agent capability ↔ workflow linking UI
  • Event trigger system (depends on #41 research)
## Implementation Progress ### Completed **1. Workflows tab added to Intelligence Archipelago** - New `Workflows` tab in the intelligence island hub (between Templates and Servers) - Full tab navigation, icon, metadata, and view registration **2. Workflow Service Layer** (`workflow_service.rs`) - Uses `FlowClient` from hero_osis_sdk (flow domain) - Full CRUD: `fetch_workflows`, `create_workflow`, `save_workflow`, `delete_workflow` - Execution: `execute_workflow`, `get_execution` - Validation: `validate_workflow` - Published listing: `fetch_published_workflows` **3. Visual DAG Workflow Editor** (`workflow_graph.rs`) - Automatic topological layout (no position persistence per your feedback) - SVG-based node rendering with curved edge connections - Color-coded step types: AI Prompt (purple), Tool/Script (blue), Condition (amber), Parallel (green), Loop (pink), Transform (teal), Output (gray) - Toolbar to add any step type - Entry step indicator, error path visualization (dashed red edges) - Click to select nodes, delete nodes **4. Workflow Editor** (`workflow_editor.rs`) - Full-screen modal with 3 panels: Metadata, Graph, Step Config - Metadata panel: name, description, version, icon, published toggle - Graph panel: the visual DAG editor - Step Config panel: step-type-specific forms - AI Prompt: system prompt, user prompt (with `{{variable}}` support), model, output variable - Tool Call: source selector (builtin/MCP/workflow), tool name/script, output variable - Other step types: placeholder forms (condition, parallel, loop configs coming next) - Auto-wiring: new steps connect to the previous step automatically - Step deletion with reference cleanup **5. Workflow List** (`workflow_list.rs`) - Card grid showing all workflows - Shows: name, version, icon, description, step type badges (AI count, tool count, condition count), published status - Actions: execute, edit, delete per workflow - Empty state with guidance **6. Rhai Script Generation** (`rhai_codegen.rs`) - `generate_rhai_script(workflow)` takes a Workflow and produces a Rhai script - Generated script connects to hero_proc and creates: - Actions with `depends_on` relationships for each WorkflowStep - Jobs from those actions - A Run to orchestrate all jobs - Maps step types to appropriate interpreters (bash for prompts/tools, rhai for transforms) - Handles dependency graph: if A→B, then B `requires` A ### Issues Created - hero_proc#28: [Migrate hero_proc storage from SQLite to OSIS](https://forge.ourworld.tf/lhumina_code/hero_proc/issues/28) (backlog) - hero_archipelagos#41: [Research and design event system for bot triggers](https://forge.ourworld.tf/lhumina_code/hero_archipelagos/issues/41) - hero_archipelagos#42: [Generic event configuration UI for bot workflow triggers](https://forge.ourworld.tf/lhumina_code/hero_archipelagos/issues/42) ### Build Status `cargo check -p hero_archipelagos_intelligence` passes clean (only pre-existing warnings from other code). ### Files Changed/Created **New files:** - `src/services/workflow_service.rs` — OSIS FlowClient CRUD - `src/services/rhai_codegen.rs` — Rhai script generation for hero_proc - `src/views/workflows/mod.rs` — Module root - `src/views/workflows/workflow_list.rs` — Workflow card grid - `src/views/workflows/workflow_editor.rs` — Full editor with graph + forms - `src/views/workflows/workflow_graph.rs` — Visual DAG editor - `src/views/tabs/workflows_tab.rs` — Tab wrapper **Modified files:** - `Cargo.toml` — Added `flow` feature to hero_osis_sdk - `src/state.rs` — Added `Workflows` to `ActiveTab` enum - `src/services/mod.rs` — Registered new service modules - `src/views/mod.rs` — Registered workflows view module - `src/views/tabs/mod.rs` — Registered workflows tab - `src/island.rs` — Wired Workflows tab (state, data loading, rendering, metadata) - `src/lib.rs` — Added workflows to get_metadata JSON ### Next Steps - Condition/parallel/loop step config forms (advanced editor panels) - Workflow execution monitoring UI (watch WorkflowExecution status) - Agent capability ↔ workflow linking UI - Event trigger system (depends on #41 research)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_archipelagos#40
No description provided.