mlua-swarm 0.24.0

Swarm engine host built on mlua — long-running stateful runtime with Role/Verb gate, CapToken, 3-stage pipeline, and Middleware overlay.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119

# Enhance default Blueprint (= system default, used for dogfooding).
#
# - flow: Seq [patch-spawner -> patch-applier -> Fanout(verifier-router) -> committer]
# - All 4 agents run on the InProc backend; spec.fn_id selects the worker fn
#   for the three Lua steps, and patch-spawner runs on the agent_block axis
# - Verifier axis count is determined by the length of the `$.verifiers` array in
#   the init ctx (the Blueprint itself is axis-count agnostic)
#
# This YAML file is the source of truth and should be edited directly rather
# than via a Rust struct literal. The patch-applier / verifier-router /
# committer worker fns are implemented as embedded Lua scripts (see
# src/enhance/scripts/), registered through LuaScriptSource. patch-spawner has
# no script of its own — it is a PromptBasedAgent whose profile.system_prompt
# carries the whole contract (see the note on the agent below).
schema_version: "0.1.0"
id: enhance-default
flow:
  kind: seq
  children:
    - kind: step
      ref: patch-spawner
      in: { op: path, at: "$" }
      out: { op: path, at: "$.patch" }
    - kind: step
      ref: patch-applier
      in: { op: path, at: "$" }
      out: { op: path, at: "$.applied" }
    - kind: fanout
      items: { op: path, at: "$.verifiers" }
      bind: { op: path, at: "$.axis" }
      body:
        kind: step
        ref: verifier-router
        in: { op: path, at: "$" }
        out: { op: path, at: "$.verdict" }
      join: all
      out: { op: path, at: "$.verdicts" }
    - kind: step
      ref: committer
      in: { op: path, at: "$" }
      out: { op: path, at: "$.commit" }
agents:
  # No `spec.script_path` on purpose: that selects the PromptBasedAgent mode,
  # where the invoker is built in-process and this `profile.system_prompt` is
  # handed to the model as-is. A script path would need a file on disk, which a
  # bundled default cannot ship (unlike the other three, whose Lua bodies are
  # `include_str!`-embedded). `spec.project_root` stays: agent-block reads that
  # directory's `.env` at startup. Swap the whole agent out via
  # `EnhanceSetting.spawner` to drive a different execution axis.
  - name: patch-spawner
    kind: agent_block
    spec:
      project_root: "."
    profile:
      system_prompt: |
        You turn one natural-language Blueprint issue into an RFC 6902 JSON Patch.

        Your prompt is a JSON object with these keys:
          issue        - { issue_id, blueprint_id, intent }; `intent` states the
                         requested change in prose.
          prev_bp_yaml - the target Blueprint serialized as YAML. This is the
                         document you patch.
          prev_hash    - content hash of prev_bp_yaml, for traceability only.
          epoch_id     - optimistic-concurrency token, for traceability only.
          verifiers    - names of the verifier axes that will judge your patch.

        Reply with a single JSON object and nothing else:

          {"ops": [...], "bump": "patch", "rationale": "..."}

          ops       - RFC 6902 operations against the JSON representation of
                      prev_bp_yaml. Every `path` is an RFC 6901 pointer into
                      that document and array indices are 0-based (for example
                      "/agents/0/profile/system_prompt"). Emit the smallest set
                      of operations that satisfies `intent`.
          bump      - "major", "minor" or "patch": how the resulting
                      Blueprint's semantic version should move.
          rationale - one sentence naming what the operations change and why.

        Rules:
        - Emit the bare JSON object. No markdown code fence, no prose before or
          after it, no trailing commentary. The next step parses your reply as
          JSON and fails the run when anything else surrounds it.
        - Never write a `version_hash` field. Replacing an agent's
          `system_prompt` recomputes that agent's hash automatically, so an
          explicit hash operation would only conflict with it.
        - Keep the patched document a valid Blueprint. It is deserialized back
          into the schema before it is verified, so operations that drop
          required keys or invent unknown ones are rejected.
        - When `intent` cannot be expressed as a patch of prev_bp_yaml —
          ambiguous, out of scope, or already satisfied — return an empty `ops`
          array and say why in `rationale`. That is a valid answer; a
          fabricated operation is not.
      model: claude-haiku-4-5-20251001
    meta:
      description: "enhance-flow default: patch-spawner (= LLM-driven NL Issue → JSON Patch)"
      tags: [enhance]
  - name: patch-applier
    kind: lua
    spec: { fn_id: patch-applier }
    meta:
      description: "enhance-flow default: patch-applier"
      tags: [enhance]
  - name: verifier-router
    kind: lua
    spec: { fn_id: verifier-router }
    meta:
      description: "enhance-flow default: verifier-router"
      tags: [enhance]
  - name: committer
    kind: lua
    spec: { fn_id: committer }
    meta:
      description: "enhance-flow default: committer"
      tags: [enhance]
metadata:
  description: "Enhance default flow: spawn → apply → verify (Fanout N axes) → commit"
  tags: [enhance, default]
  version_label: "0.3.0"