labcode 0.6.0__tar.gz → 0.8.0__tar.gz

{labcode-0.6.0 → labcode-0.8.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: labcode
-Version: 0.6.0
+Version: 0.8.0
 Summary: labcode -- a dialect wrapper over the Object-Flow Programming Language toolchain
 Author-email: Kazunari Kaizu <kwaizu@gmail.com>
 License-Expression: MIT
@@ -21,8 +21,8 @@ Requires-Python: >=3.10
 Description-Content-Type: text/markdown
 License-File: LICENSE
 Requires-Dist: ofplang-validate<0.3,>=0.2
-Requires-Dist: ofplang-schedule<0.11,>=0.9
-Requires-Dist: ofplang-run<0.10,>=0.8
+Requires-Dist: ofplang-schedule<0.12,>=0.9
+Requires-Dist: ofplang-run<0.13,>=0.11
 Provides-Extra: test
 Requires-Dist: pytest>=7.0; extra == "test"
 Requires-Dist: opentelemetry-sdk>=1.20; extra == "test"
@@ -145,9 +145,29 @@ lc run <workflow> --env <env>
     [--seconds-per-tick S] [--op-timeout S | --no-op-timeout] [--no-probe]
     [--max-transport-legs N] [--ignore-resources] [--trace] [--mission-id ID]
     [--object-ids seeded|real]
+
+lc run --jobs <run doc> --env <env> [--on-job-failure continue|stop] [...]
 ```
 
 - `<workflow>` — the portable v0 workflow: *what* happens.
+- `--jobs RUNDOC` — run **several jobs together** in one laboratory (schedule SPEC
+  §6.11) in place of the single `<workflow>`. The run document names each job — an `id`,
+  its workflow, its own boundary, and when it may start — plus what the laboratory's own
+  stocks hold to begin with and which spots it is already holding. They are planned
+  *together*, so they compete for the same machines and share a refill neither needs
+  alone. Each job's workflow goes through both front doors separately and a rejection
+  names the job it came from; a boundary belongs to a job, so `--boundary` is not used
+  with `--jobs`.
+  🔴 Object identities are minted **per job**: two jobs of one workflow bind the same
+  port names and render the same node paths, so a reproducible generator keyed on those
+  alone would give one job's plate the other's `_id`. `--trace` records the job on every
+  operation (`ofp.job`) for the same reason — the node alone does not say whose work it
+  was. A run of a single workflow names no job and is recorded exactly as it always was.
+- `--on-job-failure continue|stop` — what one job's failure does to the rest of a
+  `--jobs` run. `continue` (the default) stops that job alone and lets the others
+  finish — which is why they were planned together — while `stop` stops the whole run.
+  A stopped job's plate stays where it is, and the plan is made around it rather than
+  onto it. A single workflow is a single job, so this makes no difference to it.
 - `--env` (required) — the labcode environment: the execution environment (spec §5) plus
   the `x-labcode` extension saying *how* each operation is carried out.
 - `--boundary DOC` — the whole-workflow I/O as one document: a `boundary:` mapping with a

{labcode-0.6.0 → labcode-0.8.0}/README.md

@@ -101,9 +101,29 @@ lc run <workflow> --env <env>
     [--seconds-per-tick S] [--op-timeout S | --no-op-timeout] [--no-probe]
     [--max-transport-legs N] [--ignore-resources] [--trace] [--mission-id ID]
     [--object-ids seeded|real]
+
+lc run --jobs <run doc> --env <env> [--on-job-failure continue|stop] [...]
 ```
 
 - `<workflow>` — the portable v0 workflow: *what* happens.
+- `--jobs RUNDOC` — run **several jobs together** in one laboratory (schedule SPEC
+  §6.11) in place of the single `<workflow>`. The run document names each job — an `id`,
+  its workflow, its own boundary, and when it may start — plus what the laboratory's own
+  stocks hold to begin with and which spots it is already holding. They are planned
+  *together*, so they compete for the same machines and share a refill neither needs
+  alone. Each job's workflow goes through both front doors separately and a rejection
+  names the job it came from; a boundary belongs to a job, so `--boundary` is not used
+  with `--jobs`.
+  🔴 Object identities are minted **per job**: two jobs of one workflow bind the same
+  port names and render the same node paths, so a reproducible generator keyed on those
+  alone would give one job's plate the other's `_id`. `--trace` records the job on every
+  operation (`ofp.job`) for the same reason — the node alone does not say whose work it
+  was. A run of a single workflow names no job and is recorded exactly as it always was.
+- `--on-job-failure continue|stop` — what one job's failure does to the rest of a
+  `--jobs` run. `continue` (the default) stops that job alone and lets the others
+  finish — which is why they were planned together — while `stop` stops the whole run.
+  A stopped job's plate stays where it is, and the plan is made around it rather than
+  onto it. A single workflow is a single job, so this makes no difference to it.
 - `--env` (required) — the labcode environment: the execution environment (spec §5) plus
   the `x-labcode` extension saying *how* each operation is carried out.
 - `--boundary DOC` — the whole-workflow I/O as one document: a `boundary:` mapping with a

{labcode-0.6.0 → labcode-0.8.0}/examples/README.md

@@ -59,12 +59,24 @@ python examples/render_plate_line.py
 
 🔴 **These are a record of one run, not a reproducible golden.** The labcode backend
 runs its operations out of process against a **wall clock** (`seconds_per_tick`), so
-which tick a subprocess finishes on varies between runs: re-rendering the same commit
-gives a final `now` of 10 one time and 13 the next. Do not treat a difference here as a
-regression, and do not gate a change on these files being byte-identical — the way the
-scheduler's and the runner's own artifacts can be, both of those being driven by a
-virtual clock. What *is* stable is the plan the scheduler produces from a given input,
-which the tests cover.
+which tick an operation finishes on varies between runs. Do not treat a difference here
+as a regression, and do not gate a change on these files being byte-identical — the way
+the scheduler's and the runner's own artifacts can be, both of those being driven by a
+virtual clock.
+
+Measured on one machine, three runs of the same commit: **the same nine activities
+every time**, and a makespan of 144, 128 and 137. What moves is *when* each activity
+happened and, because a rolling run replans against what it has observed, *the
+arrangement* the plan settles on — one run loads the plate first, the next moves the
+tube first. What does not move is **what ran**, the `_id` each Object carries, and the
+values the scripts produced: `outputs/plate_line.boundary.yaml` came back **byte-identical
+across all three**, being the one artifact here that carries no times at all.
+
+🔴 It is not only the subprocesses. `LabcodeRunner` accepts an injected `monotonic` /
+`sleep`, and a **scriptless** run driven by a fake clock still varied run to run
+(measured) — so "inject a clock" is not the fix, and making labcode's execution output
+deterministic is an open problem rather than an oversight. The plan the *scheduler*
+produces from a given input is reproducible, and the tests are where that is pinned.
 
 - [`outputs/plate_line.plan.yaml`](outputs/plate_line.plan.yaml) — the **final execution
   schedule** (the §6/§7 status document: every activity, `completed`).
@@ -78,21 +90,100 @@ which the tests cover.
   boundary**, echoing the produced `od` and the returned `tube` (as `--boundary-out`
   writes it).
 
-Because the labcode backend runs each op out-of-process on a wall clock, the exact times
-(and makespan) may vary slightly between runs; the sequence and produced values do not.
-
 Every Object's view carries a reserved **`_id`** — labcode's implicit, value-layer Object
 identity (see [`../SPECIFICATIONS.md`](../SPECIFICATIONS.md) §4). In the observation you can
 follow the *same* Plate (one `_id`) from `load` through `dispense`/`read` to `store`, and
 the Tube's `_id` round-trips from the input boundary to the output. The ids are
-reproducible (a seeded, provenance-keyed generator), so these outputs are stable to
-re-generate.
+reproducible (a seeded, provenance-keyed generator, keyed **per job** in a `--jobs`
+run), so the ids in these outputs are stable to re-generate even though their times are
+not.
 
 > The scripts here are mocks (they just return values / reference their locals). Replace a
 > script's body with real device calls — e.g. `robot.move(from_spot, to_spot)` in a
 > transport, or an instrument read in `read` — to drive real hardware; the code may
 > `import` anything the host Python can.
 
+## `shared_bench` — two jobs, one laboratory
+
+`plate_line` runs one workflow. A bench does not: the morning's tubes and the
+afternoon's are the same work on the same machines, and running them one after the other
+leaves the reader idle while somebody fetches the next rack. `lc run --jobs` plans them
+**together** (schedule SPEC §6.11), so the plan decides who gets the bench.
+
+```
+   rack.slot_a ─┐                      ┌─ rack.slot_a      morning
+                ├─ arm ─▶ reader.stage ┤
+   rack.slot_b ─┘                      └─ rack.slot_b      afternoon
+```
+
+A slot per job, and **one reader and one arm** — the contention is the subject. Both jobs
+run the *same* workflow file and differ only in their boundary: which tube, and which
+slot it lives on.
+
+- [`shared_bench.workflow.yaml`](shared_bench.workflow.yaml) — fetch a Tube, measure it,
+  put it back. Nothing about it is joint, which is the point: a workflow says what
+  happens to one piece of work.
+- [`shared_bench.env.yaml`](shared_bench.env.yaml) — the laboratory, with an
+  `x-labcode.script` on the measure mode and on every route.
+- [`shared_bench.run.yaml`](shared_bench.run.yaml) — the **run document**: the two jobs,
+  each naming its workflow and its boundary.
+- [`shared_bench.morning.boundary.yaml`](shared_bench.morning.boundary.yaml) /
+  [`.afternoon.`](shared_bench.afternoon.boundary.yaml) — a boundary belongs to a *job*,
+  which is why the run document names one per job rather than the command line carrying
+  one for all of them.
+
+### Run it
+
+```sh
+lc run --jobs examples/shared_bench.run.yaml --env examples/shared_bench.env.yaml     --seed 0 --seconds-per-tick 0.2 --boundary-out /tmp/shared_bench.boundary.yaml
+```
+
+`--on-job-failure continue` (the default) stops a failing job alone and lets the other
+finish — which is why they were planned together; `stop` stops the whole run.
+
+### Produce the outputs
+
+```sh
+python examples/render_shared_bench.py
+```
+
+- [`outputs/shared_bench.plan.yaml`](outputs/shared_bench.plan.yaml) — the final
+  schedule. Every activity carries the `job` it belongs to, and the roster at the top
+  carries each job's promised completion.
+- [`outputs/shared_bench.svg`](outputs/shared_bench.svg) — the Gantt chart. The reader's
+  lane is where the joint plan shows: the two jobs take turns on it rather than one run
+  waiting for the other to end.
+- [`outputs/shared_bench.observation.yaml`](outputs/shared_bench.observation.yaml) — the
+  observation document, each record naming its job.
+- [`outputs/shared_bench.boundary.yaml`](outputs/shared_bench.boundary.yaml) — the result
+  boundary, **per job**.
+
+🔴 **The result boundary is where to look.** Both jobs render the same node paths and
+bind the same port names, so what tells their work apart is the job:
+
+```yaml
+jobs:
+  morning:
+    boundary:
+      outputs:
+        sample: { spot: rack.slot_a, view: { label: morning,   _id: d3eb614f-… } }
+        od:     { view: 0.7 }
+  afternoon:
+    boundary:
+      outputs:
+        sample: { spot: rack.slot_b, view: { label: afternoon, _id: 9393759b-… } }
+        od:     { view: 0.9 }
+```
+
+Two tubes, two identities. labcode mints each Object's `_id` **per job** for exactly this
+reason — a reproducible generator keyed on the node path alone would hand both tubes one
+identity, silently and the same way on every run — and `--trace` records the job on every
+operation (`ofp.job`) so a record says whose work it was. A run of a single workflow names
+no job and is minted and recorded exactly as it always was.
+
+The times here move between runs like every other labcode execution output (above); the
+result boundary does not, carrying none.
+
 ## `sila2_seal` — the same idea, driven by real SiLA2 servers
 
 Where `plate_line`'s scripts are mocks that only return values, this example's scripts open

labcode-0.8.0/examples/outputs/shared_bench.boundary.yaml

@@ -0,0 +1,33 @@
+jobs:
+  morning:
+    boundary:
+      inputs:
+        sample:
+          spot: rack.slot_a
+          view:
+            label: morning
+            _id: d3eb614f-1607-4f72-946c-4e7b4ff459b9
+      outputs:
+        sample:
+          spot: rack.slot_a
+          view:
+            label: morning
+            _id: d3eb614f-1607-4f72-946c-4e7b4ff459b9
+        od:
+          view: 0.7
+  afternoon:
+    boundary:
+      inputs:
+        sample:
+          spot: rack.slot_b
+          view:
+            label: afternoon
+            _id: 9393759b-b778-4196-8be5-392dc38f1f97
+      outputs:
+        sample:
+          spot: rack.slot_b
+          view:
+            label: afternoon
+            _id: 9393759b-b778-4196-8be5-392dc38f1f97
+        od:
+          view: 0.9

labcode-0.8.0/examples/outputs/shared_bench.observation.yaml

@@ -0,0 +1,141 @@
+schema: ofplang-observation/v0
+time:
+  unit: second
+---
+kind: transport
+job: morning
+from_spot: rack.slot_a
+to_spot: reader.stage
+transporter: arm
+arc:
+  from:
+    node: []
+    port: sample
+  to:
+    node:
+    - Measure
+    port: sample
+start: 0
+end: 1
+moved:
+  view:
+    label: morning
+    _id: d3eb614f-1607-4f72-946c-4e7b4ff459b9
+---
+kind: processing
+job: morning
+process: measure
+mode: m0
+node:
+- Measure
+devices:
+- reader
+input_spots:
+  sample: reader.stage
+output_spots:
+  measured: reader.stage
+start: 1
+end: 3
+inputs:
+  sample:
+    view:
+      label: morning
+      _id: d3eb614f-1607-4f72-946c-4e7b4ff459b9
+outputs:
+  measured:
+    view:
+      label: morning
+      _id: d3eb614f-1607-4f72-946c-4e7b4ff459b9
+  od:
+    view: 0.7
+---
+kind: transport
+job: morning
+from_spot: reader.stage
+to_spot: rack.slot_a
+transporter: arm
+arc:
+  from:
+    node:
+    - Measure
+    port: measured
+  to:
+    node: []
+    port: sample
+start: 3
+end: 5
+moved:
+  view:
+    label: morning
+    _id: d3eb614f-1607-4f72-946c-4e7b4ff459b9
+---
+kind: transport
+job: afternoon
+from_spot: rack.slot_b
+to_spot: reader.stage
+transporter: arm
+arc:
+  from:
+    node: []
+    port: sample
+  to:
+    node:
+    - Measure
+    port: sample
+start: 5
+end: 7
+moved:
+  view:
+    label: afternoon
+    _id: 9393759b-b778-4196-8be5-392dc38f1f97
+---
+kind: processing
+job: afternoon
+process: measure
+mode: m0
+node:
+- Measure
+devices:
+- reader
+input_spots:
+  sample: reader.stage
+output_spots:
+  measured: reader.stage
+start: 7
+end: 9
+inputs:
+  sample:
+    view:
+      label: afternoon
+      _id: 9393759b-b778-4196-8be5-392dc38f1f97
+outputs:
+  measured:
+    view:
+      label: afternoon
+      _id: 9393759b-b778-4196-8be5-392dc38f1f97
+  od:
+    view: 0.9
+---
+kind: transport
+job: afternoon
+from_spot: reader.stage
+to_spot: rack.slot_b
+transporter: arm
+arc:
+  from:
+    node:
+    - Measure
+    port: measured
+  to:
+    node: []
+    port: sample
+start: 9
+end: 10
+moved:
+  view:
+    label: afternoon
+    _id: 9393759b-b778-4196-8be5-392dc38f1f97
+---
+final: true
+now: 10
+outcome: completed

labcode-0.8.0/examples/outputs/shared_bench.plan.yaml

@@ -0,0 +1,134 @@
+time:
+  unit: second
+now: 10
+jobs:
+- id: morning
+  release: 0
+  bound: 10
+  fingerprint: ec69dad347c6ba08
+  interface:
+    inputs:
+      sample: rack.slot_a
+    outputs:
+      sample: rack.slot_a
+- id: afternoon
+  release: 0
+  bound: 20
+  fingerprint: ec69dad347c6ba08
+  interface:
+    inputs:
+      sample: rack.slot_b
+    outputs:
+      sample: rack.slot_b
+objective:
+  kind:
+  - completion_time_sum
+  - makespan
+  value:
+  - 15
+  - 10
+activities:
+- kind: transport
+  job: morning
+  status: completed
+  start: 0
+  end: 1
+  from_spot: rack.slot_a
+  to_spot: reader.stage
+  transporter: arm
+  arc:
+    from:
+      node: []
+      port: sample
+    to:
+      node:
+      - Measure
+      port: sample
+  seq: 0
+- kind: processing
+  job: morning
+  status: completed
+  start: 1
+  end: 3
+  process: measure
+  mode: m0
+  node:
+  - Measure
+  devices:
+  - reader
+  input_spots:
+    sample: reader.stage
+  output_spots:
+    measured: reader.stage
+- kind: transport
+  job: morning
+  status: completed
+  start: 3
+  end: 5
+  from_spot: reader.stage
+  to_spot: rack.slot_a
+  transporter: arm
+  arc:
+    from:
+      node:
+      - Measure
+      port: measured
+    to:
+      node: []
+      port: sample
+  seq: 0
+- kind: transport
+  job: afternoon
+  status: completed
+  start: 5
+  end: 7
+  from_spot: rack.slot_b
+  to_spot: reader.stage
+  transporter: arm
+  arc:
+    from:
+      node: []
+      port: sample
+    to:
+      node:
+      - Measure
+      port: sample
+  seq: 0
+- kind: processing
+  job: afternoon
+  status: completed
+  start: 7
+  end: 9
+  process: measure
+  mode: m0
+  node:
+  - Measure
+  devices:
+  - reader
+  input_spots:
+    sample: reader.stage
+  output_spots:
+    measured: reader.stage
+- kind: transport
+  job: afternoon
+  status: completed
+  start: 9
+  end: 10
+  from_spot: reader.stage
+  to_spot: rack.slot_b
+  transporter: arm
+  arc:
+    from:
+      node:
+      - Measure
+      port: measured
+    to:
+      node: []
+      port: sample
+  seq: 0
+meta:
+  workflow:
+  - <in-memory>
+  - <in-memory>
+  environment: C:\Users\kaizu\Documents\Python Scripts\ofplang-labcode\examples\shared_bench.env.yaml
+  status: <in-memory>

labcode-0.8.0/examples/outputs/shared_bench.svg

@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 784 206" width="784" height="206" font-family="system-ui, sans-serif" font-size="12"><text fill="#1a1a1a" font-size="15" font-weight="600" x="16" y="24">Schedule &#8212; device view</text><text fill="#666666" x="16" y="40">makespan 10 second</text><defs><marker id="ah" markerWidth="8" markerHeight="8" refX="7" refY="3" orient="auto"><path d="M0,0 L7,3 L0,6 Z" fill="#9333ea"/></marker></defs><g transform="translate(0,48)"><line stroke="#b3b3b3" stroke-width="1" x1="200.0" y1="34.0" x2="200.0" y2="130.0"/><text fill="#666666" x="200.0" y="28.0" text-anchor="middle">0</text><line stroke="#b3b3b3" stroke-width="1" x1="256.0" y1="34.0" x2="256.0" y2="130.0"/><text fill="#666666" x="256.0" y="28.0" text-anchor="middle">1</text><line stroke="#b3b3b3" stroke-width="1" x1="312.0" y1="34.0" x2="312.0" y2="130.0"/><text fill="#666666" x="312.0" y="28.0" text-anchor="middle">2</text><line stroke="#b3b3b3" stroke-width="1" x1="368.0" y1="34.0" x2="368.0" y2="130.0"/><text fill="#666666" x="368.0" y="28.0" text-anchor="middle">3</text><line stroke="#b3b3b3" stroke-width="1" x1="424.0" y1="34.0" x2="424.0" y2="130.0"/><text fill="#666666" x="424.0" y="28.0" text-anchor="middle">4</text><line stroke="#b3b3b3" stroke-width="1" x1="480.0" y1="34.0" x2="480.0" y2="130.0"/><text fill="#666666" x="480.0" y="28.0" text-anchor="middle">5</text><line stroke="#b3b3b3" stroke-width="1" x1="536.0" y1="34.0" x2="536.0" y2="130.0"/><text fill="#666666" x="536.0" y="28.0" text-anchor="middle">6</text><line stroke="#b3b3b3" stroke-width="1" x1="592.0" y1="34.0" x2="592.0" y2="130.0"/><text fill="#666666" x="592.0" y="28.0" text-anchor="middle">7</text><line stroke="#b3b3b3" stroke-width="1" x1="648.0" y1="34.0" x2="648.0" y2="130.0"/><text fill="#666666" x="648.0" y="28.0" text-anchor="middle">8</text><line stroke="#b3b3b3" stroke-width="1" x1="704.0" y1="34.0" x2="704.0" y2="130.0"/><text fill="#666666" x="704.0" y="28.0" text-anchor="middle">9</text><line stroke="#b3b3b3" stroke-width="1" x1="760.0" y1="34.0" x2="760.0" y2="130.0"/><text fill="#666666" x="760.0" y="28.0" text-anchor="middle">10</text><text fill="#666666" x="200.0" y="150.0">time (second)</text><line stroke="#d9d9d9" stroke-width="1" x1="0" y1="70.0" x2="784.0" y2="70.0"/><text fill="#1a1a1a" x="190.0" y="59.0" text-anchor="end">rack</text><line stroke="#d9d9d9" stroke-width="1" x1="0" y1="100.0" x2="784.0" y2="100.0"/><text fill="#1a1a1a" x="190.0" y="89.0" text-anchor="end">reader</text><line stroke="#d9d9d9" stroke-width="1" x1="0" y1="130.0" x2="784.0" y2="130.0"/><text fill="#1a1a1a" x="190.0" y="119.0" text-anchor="end">arm (transporter)</text><line stroke="#dc2626" stroke-width="1.5" stroke-dasharray="4 3" x1="760.0" y1="34.0" x2="760.0" y2="130.0"/><text fill="#dc2626" x="763.0" y="28.0">now=10</text><rect fill="#f59e0b" x="200.0" y="105.0" width="56.0" height="20" rx="3"/><text fill="#3a2a00" x="204.0" y="119.0">&gt; morn…</text><rect fill="#f59e0b" fill-opacity="0.2" x="200.0" y="45.0" width="56.0" height="20" rx="3"/><rect fill="#f59e0b" fill-opacity="0.2" x="200.0" y="75.0" width="56.0" height="20" rx="3"/><rect fill="#3b82f6" x="256.0" y="75.0" width="112.0" height="20" rx="3"/><text fill="#ffffff" x="260.0" y="89.0">morning:Measure</text><rect fill="#f59e0b" x="368.0" y="105.0" width="112.0" height="20" rx="3"/><text fill="#3a2a00" x="372.0" y="119.0">&gt; morning:trans…</text><rect fill="#f59e0b" fill-opacity="0.2" x="368.0" y="75.0" width="112.0" height="20" rx="3"/><rect fill="#f59e0b" fill-opacity="0.2" x="368.0" y="45.0" width="112.0" height="20" rx="3"/><rect fill="#f59e0b" x="480.0" y="105.0" width="112.0" height="20" rx="3"/><text fill="#3a2a00" x="484.0" y="119.0">&gt; afternoon:Mea…</text><rect fill="#f59e0b" fill-opacity="0.2" x="480.0" y="45.0" width="112.0" height="20" rx="3"/><rect fill="#f59e0b" fill-opacity="0.2" x="480.0" y="75.0" width="112.0" height="20" rx="3"/><rect fill="#3b82f6" x="592.0" y="75.0" width="112.0" height="20" rx="3"/><text fill="#ffffff" x="596.0" y="89.0">afternoon:Measu…</text><rect fill="#f59e0b" x="704.0" y="105.0" width="56.0" height="20" rx="3"/><text fill="#3a2a00" x="708.0" y="119.0">&gt; afte…</text><rect fill="#f59e0b" fill-opacity="0.2" x="704.0" y="75.0" width="56.0" height="20" rx="3"/><rect fill="#f59e0b" fill-opacity="0.2" x="704.0" y="45.0" width="56.0" height="20" rx="3"/></g></svg>

labcode-0.8.0/examples/render_shared_bench.py

@@ -0,0 +1,109 @@
+"""Run the `shared_bench` example -- two jobs in one laboratory -- and write its outputs.
+
+The companion of `render_plate_line.py`, driving `labcode.run_labcode` exactly as
+`lc run --jobs examples/shared_bench.run.yaml --env examples/shared_bench.env.yaml`
+does. Where that example runs one workflow down a line, this one runs the *same* workflow
+twice at once and lets the plan sort out who gets the bench:
+
+    rack.slot_a ─┐                      ┌─ rack.slot_a       morning
+                 ├─ arm ─▶ reader.stage ┤
+    rack.slot_b ─┘                      └─ rack.slot_b       afternoon
+
+One reader and one arm, a slot per job. The two jobs are planned **together** (schedule
+SPEC §6.11), so they take turns on the reader instead of one run waiting for the other
+to finish -- which is what planning them together is for.
+
+🔴 What to look at: the two jobs run the same file, so every node path and port name
+they render is identical. What tells their work apart is the **job** -- each Object's
+`_id` is minted per job (see the printed result boundary: two different tubes), and
+`--trace` records the job on every operation. Without that a reproducible generator
+would hand both tubes one identity.
+
+Run it:
+
+    python examples/render_shared_bench.py
+
+It writes four artifacts under examples/outputs/:
+  - shared_bench.plan.yaml        -- the final execution schedule (§6/§7), every activity
+                                     carrying the `job` it belongs to
+  - shared_bench.observation.yaml -- the observation document (D38), likewise per job
+  - shared_bench.svg              -- a Gantt chart (device view): the reader's lane shows
+                                     the two jobs queueing for it
+  - shared_bench.boundary.yaml    -- the result boundary, **per job**: each tube back on
+                                     its own slot, with its own `_id` and its own `od`
+
+🔴 These are a record of one run, not a golden: labcode runs out of process on a wall
+clock, so the times and the arrangement move between runs (examples/README.md). The one
+artifact that does not is the result boundary, which carries no times.
+
+Requires the sibling `ofplang-schedule` (the runner replans through it, and its
+visualizer draws the SVG).
+"""
+
+from __future__ import annotations
+
+from pathlib import Path
+
+import yaml
+from ofplang.run.runner import load_document, parse_run_document, serialize_document
+from ofplang.schedule.scheduler.visualize import render_svg
+
+from labcode.runner import run_labcode
+
+HERE = Path(__file__).parent
+OUT = HERE / "outputs"
+RUN_DOCUMENT = HERE / "shared_bench.run.yaml"
+ENVIRONMENT = HERE / "shared_bench.env.yaml"
+
+# As in render_plate_line.py: a small real-seconds-per-tick keeps the out-of-process demo
+# quick. The reader takes 6 ticks and each move 2, so two jobs sharing one reader is a
+# few seconds of wall clock.
+SECONDS_PER_TICK = 0.2
+
+
+def main() -> None:
+    OUT.mkdir(exist_ok=True)
+
+    # The run document is the joint entry: which jobs, each one's workflow and boundary.
+    # Parsed the way `lc run --jobs` parses it, relative to this directory.
+    run_doc = parse_run_document(
+        load_document(str(RUN_DOCUMENT)), RUN_DOCUMENT.parent
+    )
+
+    # `run_labcode` takes the roster in place of a workflow. It does per job what it does
+    # for a lone workflow -- inject `_id` into the Object types, mint the boundary's ids,
+    # share one IdGenerator with the backend -- and keys the minting by the job, so the
+    # two tubes are two tubes.
+    result = run_labcode(
+        list(run_doc.jobs),
+        str(ENVIRONMENT),
+        # No boundary for the run: a boundary belongs to a job, and each carries its own.
+        poll_interval=1,
+        running_task_margin=1,
+        random_seed=0,
+        seconds_per_tick=SECONDS_PER_TICK,
+        observation_out=str(OUT / "shared_bench.observation.yaml"),
+        # The default, spelled out because it is the interesting one here: if the morning
+        # tube is dropped, the afternoon's still gets measured.
+        on_job_failure="continue",
+    )
+
+    status = result.status
+    status.setdefault("objective", {"kind": "makespan", "value": status.get("now")})
+
+    (OUT / "shared_bench.plan.yaml").write_text(
+        serialize_document(status), encoding="utf-8"
+    )
+    (OUT / "shared_bench.svg").write_text(
+        render_svg(status, view="device"), encoding="utf-8"
+    )
+    (OUT / "shared_bench.boundary.yaml").write_text(
+        serialize_document(result.result_boundary), encoding="utf-8"
+    )
+
+    print(f"makespan: {status.get('now')}")
+    print(yaml.safe_dump(result.result_boundary, sort_keys=False).rstrip())
+
+
+if __name__ == "__main__":
+    main()

labcode-0.8.0/examples/shared_bench.afternoon.boundary.yaml

@@ -0,0 +1,15 @@
+# The afternoon job's boundary: its tube starts on `slot_b` and goes back there.
+#
+# A boundary belongs to a *job*, not to the run -- which is why a run document names one
+# per job rather than the command line carrying one for all of them. The two jobs here
+# differ in exactly this file: same workflow, same laboratory, different slot and
+# different tube.
+boundary:
+  inputs:
+    sample:
+      spot: rack.slot_b
+      view:
+        label: afternoon
+  outputs:
+    sample: { spot: rack.slot_b }
+    od: {}