Dual-lane architecture
This section is the BioLine OpenClaw migration baseline. The execution lane runs a Job against an existing BioLine Flow. The authoring lane creates or updates a Tool, Tool Version, or Flow. Each lane has its own registry, state machine, filesystem root, and container labels; runtime state never crosses the boundary.
Documentation source
The machine-readable index is fixed at https://www.bioline.cloud/ai/commandLineAndFkit/, with Markdown served from the same-origin /ai/ tree (a directory address returns that directory's index.md, and a leaf address returns the matching Markdown). OpenClaw requests an exact page with fkit <command path> --docs --docs-json --docs-lang <zh|en>; there are five public docs options: --docs, --docs-index, --docs-link <path>, --docs-lang, and --docs-json. fkit does not parse the user-facing https://doc.bioline.cloud/ HTML site or read a local documentation bundle. If the remote index or command page is unavailable, persist document_gap and stop; skill_fallback_allowed is always false.
Two lanes
| Lane | Root | External objects | Outputs |
|---|---|---|---|
| execution | /data/output/<job-id>/, override with OPENCLAW_JOBS_ROOT | dynamically discovered Flows and Jobs | stage, analysis, scripts, logs, results |
| authoring | /data/authoring/<slug>/, override with OPENCLAW_AUTHORING_ROOT | Tools, Tool Versions, Flows | draft, validation, publish result, handoff |
Execution paths may not be under the authoring root, and authoring paths may not be under the execution root. Execution containers use --network none, drop all extra capabilities, and mount stage/ read-only. Authoring builds use the separate openclaw.role=authoring label and the default build network; they never reuse downstream containers.
Exact state sequences
Execution:
initialize → docs_loaded → planned → awaiting_plan_confirmation → submitted → running → succeeded → finalized → downstream_prepared → downstream_running → completed
Authoring:
bootstrap → docs_loaded → drafted → awaiting_build_confirmation → built → tested → awaiting_publish_confirmation → published → awaiting_register_confirmation → registered → verified → handed_off → completed
Failure phases are explicit rather than successful-looking placeholders. Execution uses plan_failed, submit_failed, upstream_failed, finalize_failed, downstream_failed, and document_gap; authoring uses draft_failed, build_failed, test_failed, publish_failed, register_failed, verification_failed, and document_gap.
Invariants
- Execution planning is read-only: use fkit to discover and inspect the Flow, list input files, and present bindings and defaults.
- A user confirms the plan before Job creation; build, publish, and register are separate confirmations.
- Successful upstream output is finalized before local downstream execution.
- New objects are checked through fkit list/config/summary/inspect read-back; handoff records only verified IDs.
- There is no shared Flow mapping. Execution obtains IDs from BioLine responses and never guesses them locally.