LabOps 26.17.0

LabOps v26.17.0

A protocol recorded on a project's step could say what that work did differently from the version
it followed, the Protocols area showed every project and experiment that followed each protocol,
and the identifier check stopped refusing metadata workbooks with title rows over their headers.

New Features

• A protocol on a step recorded what the work did differently from its version. Most
  experiments follow a published version with a few small changes, which had to become a new
  version of the protocol to be recorded at all. Add protocol gained a Changes from this
  version box, one change per line (for example "50 µL of plasma instead of 100 µL"), and each
  protocol on a step gained an Edit button. The step showed the changes under the protocol, and
  so did the Protocols table on the project's wiki page. Recording a newer version kept the
  changes. labops projects link <item> protocol <id> --version N --deviation TEXT did the same for
  Claude and in a terminal (src/LabOps.Engines/Projects/ProjectsEngine.Write.cs,
  src/LabOps.App/Views/ChooseProtocolWindow.xaml, src/LabOps.App/Views/ProjectsView.xaml).
• The Protocols area showed where each protocol was followed. A Used by column counted the
  projects and experiments that recorded a protocol, and the selected protocol listed each one with
  its step, the version followed and any changes, closed projects included, so a mistake found in a
  version showed at once whose work used it. Clicking one opened it in the Projects area.
  labops projects uses [<protocol>] listed the same (src/LabOps.Engines/Projects/ProjectsEngine.cs,
  src/LabOps.App/ViewModels/ProtocolsViewModel.cs, src/LabOps.App/Views/ProtocolsView.xaml).

Bug Fixes

• A metadata workbook with title rows over its headers was no longer refused. A merged "Meta
  Data" or "Plasma samples" row above the columns it grouped had been read as the header row, so
  every column under it counted as having no header and the file was refused as identifying. The
  check now found the real headers under the titles and checked those, so an American mink sheet
  refused with 90 errors attached with none, and a name column under a title was caught by name
  (src/LabOps.Engines/Projects/Sheets.cs).
• A column without a header in a collaborator's sheet only warned before Claude read the file.
  An unlabeled plate map beside the samples had kept the whole workbook from Claude. Claude was
  told to check such a column instead. A column whose header named a person, a contact detail or a
  record number still kept the file from Claude, and nothing was committed with a column the check
  could not name (src/LabOps.Engines/Projects/Deidentification.cs).
• Remove stayed in view beside a protocol with a long title. A long protocol title on a step
  had pushed Remove past the edge of the timeline; Remove and Edit now wrapped onto the next line
  (src/LabOps.App/Views/ProjectsView.xaml).

LabOps 26.16.0

LabOps v26.16.0

Sample prep and data acquisition could be done in batches, each batch a step of its own under
its step, and a screen reader read the rows of the app's lists by their names.

New Features

• Sample prep and data acquisition could be done in batches. A Batches button split the
  step into a number of batches, each a step of its own shown indented under it, which was started,
  finished, assigned and planned on its own. The step's row said how many batches were done and
  kept the step's protocol, notebook and tools. Importing an Octopus layout made sample prep one
  batch per plate, with each plate's number of samples. A step split after it was done kept its
  start on the first batch and its finish on the last. The overview, the lab dashboard and the
  wiki pages named each batch ("Sample prep, batch 2"), and the instrument schedule showed each
  acquisition batch's plan. labops projects split <item> <step> --batches N did the same for
  Claude and in a terminal (src/LabOps.Engines/Projects/ProjectsEngine.Write.cs,
  src/LabOps.App/Views/ProjectsView.xaml, ViewModels/ProjectItems.cs).

Bug Fixes

• A screen reader read a project, quote or notebook in a list by its name. It had read each row
  of the Projects list, the quotes list and the notebook picker as every field the app kept for it,
  nested lists and all. A project read as its name and title, a quote as its number and title, and
  a notebook as its ID and title (src/LabOps.App/ViewModels/ProjectItems.cs,
  src/LabOps.Core/Quotes/QuoteSummary.cs, src/LabOps.Core/Panorama/PanoramaClient.cs).

LabOps 26.15.1

LabOps v26.15.1

Fixes from a review of 26.15.0: the update banner, method links reached through a junction or
mapped drive, the overview and wiki previews, and pasting pictures into the Claude pane.

Bug Fixes

• A copy too old for a lab repository looked for its update twice at once. At startup, or when
  Check for updates was pressed during a check, a second check started and downloaded the same
  release again, and the banner could say getting the update had failed while it was on its way.
  A check asked for while one ran joined it (src/LabOps.App/Services/UpdateService.cs,
  src/LabOps.Core/Infrastructure/OneAtATime.cs).

• The update banner stopped replacing the window's other messages. While the app was too old
  for a repository, each step of the update rewrote the window's banner, so a message such as "The
  quotes could not be loaded" vanished within seconds, and showed the update's button. The update
  got a banner of its own (src/LabOps.App/MainWindow.xaml, ViewModels/MainViewModel.cs).

• The update banner said what to do in two more cases. When getting the update failed, it
  showed only the error; it then said to check the internet connection and press Check for
  updates. When the update downloaded was itself older than the repository needed, it said a
  restart was all it took; it then said the restart installs it and the needed one comes after
  (ViewModels/MainViewModel.cs).

• A protocol's method opened when LabOps-Protocols was reached through a junction, a link or a
  mapped drive. The page names a method by where the copy really is, which the app compared with
  the path it knew the copy by, so clicking the method did nothing. Both were compared as Windows
  resolves them (src/LabOps.Core/Protocols/ProtocolFiles.cs, Infrastructure/FinalPath.cs).

• The projects overview and the wiki preview followed no link to another page inside the app.
  As the protocol preview did from 26.15.0, each loaded only its own page; a link to another file
  on the computer, or to a page written into the link itself, was not followed
  (src/LabOps.App/Services/WebViewGuard.cs, Views/ProjectsView.xaml.cs, Views/WikiWindow.xaml.cs).

• Pasting into the Claude pane no longer showed an error or lost a picture. A picture copied
  from a program that had since closed made Ctrl+V report that something went wrong; the paste
  then went ahead as text. Two pictures pasted in the same second could collide, and the second
  was not attached; each got a name of its own (Views/ChatPanel.xaml.cs,
  ViewModels/ChatViewModel.cs).

LabOps 26.15.0

LabOps v26.15.0

A method on a protocol's page opened in its folder, a screen capture could be pasted into the
Claude pane, and a copy too old for a lab repository could update from the banner that said so.

New Features

• A screen capture could be pasted into the Claude pane. Ctrl+V (or Shift+Insert) in
  the message box attached a picture with no text on the clipboard as a PNG named for when it was
  pasted (Pasted image 2026-10-12 14.03.27.png), and files copied in File Explorer as if they
  had been dropped there; text still pasted as text. In the Projects area a picture was attached
  only after the person said it held nothing identifying, as for any file the app cannot scan
  (src/LabOps.App/Views/ChatPanel.xaml.cs, ViewModels/ChatViewModel.cs).

Bug Fixes

• A protocol's method could be opened from its page. Clicking a method's name (a KingFisher
  program, an instrument method) on a protocol's page had done nothing; it opened File Explorer
  with the file selected, ready to copy or open. This needed LabOps-Protocols' engine, which links
  each method to its file. The preview also stopped following a link to any other file on the
  computer, or to a page written into the link itself (src/LabOps.App/Views/ProtocolsView.xaml.cs,
  Services/WebViewGuard.cs).

• A copy too old for a lab repository could update from the banner that said so. The banner
  said to update but offered no way to, and the app looked for updates only every 4 hours, so a
  release just made could wait hours. While a repository needed a newer app, LabOps looked for the
  update at once and every 10 minutes after, the banner said how the update was going, and its
  button read Check for updates, or Restart to update once the update was downloaded
  (src/LabOps.App/ViewModels/MainViewModel.cs, Services/UpdateService.cs).

• The app's examples named an invented protocol instead of one of the lab's. The title box's
  tooltip in New protocol, the message when a replacement protocol is not found, and the
  engine's error asking for a protocol's ID gave the made-up examples Spin trap digestion and
  spin-trap-digestion (src/LabOps.App/Views/NewProtocolWindow.xaml,
  ViewModels/ProtocolsViewModel.cs, src/LabOps.Engines/Projects/ProjectsEngine.Write.cs).

LabOps 26.14.0

LabOps v26.14.0

Each phase of the work got its own color wherever a step is shown, finished work turned gray,
and the protocol preview stopped flashing a black box before its first page.

New Features

• Each phase of the work had its own color, the same everywhere. Samples (aqua), Preparation
  (blue), Acquisition (violet), Analysis (pink) and Results (green) marked every step not yet
  done, and finished work was gray:

  • In the app: an edge on each step of a project, and a square beside where each project
    stood in the list and beside each kind in Add a step. A finished step's check mark was gray
    (it had been green).
  • In the overview: the board's column headings, the bars of the timeline and the
    instrument schedule, and the calendar's entries. Late work had a red ring (it had been a red
    bar), in the darker red now used for late everywhere, which stayed apart from the pink of
    Analysis. On the calendar, started entries were white and finished ones gray.
  • On Panorama: the lab dashboard, and the projects' wiki pages, where a key named the
    colors and a step's Done badge was gray (it had been green). A wiki page took the colors the
    next time its project was changed in LabOps, or was published from Wiki page.

  The colors were chosen to stay apart for color-blind readers too, and each always appeared
  beside a name. They were defined once, in src/LabOps.Engines/Projects/Phases.cs.

Bug Fixes

• No black box before a protocol's page. The first protocol opened after LabOps started, and
  any protocol opened after none was selected, showed a black box for up to half a second while
  its page rendered: the browser drew nothing for a page it had loaded while hidden, nor for an
  empty page. The preview loaded its page again as it appeared, and showed white until the
  protocol's page was ready. The quote preview and the projects overview, which loaded their pages
  the same way, did the same (src/LabOps.App/Services/WebViewGuard.cs, HiddenLoads.cs).

LabOps 26.13.0

LabOps v26.13.0

A free-text column someone had read for identifiers could be marked as read, so check stopped
warning about it until its wording changed.

New Features

• A free-text column could be marked as read. check warns about every notes or comments column,
  since no rule can tell a note from a name. Once someone had read one and found nothing identifying,
  labops projects review <project> <file> [column...] --by LOGIN recorded it in the project's
  record under reviewed:, with who, when, and a fingerprint of the column's wording. check (and
  the pre-commit check) then left that column alone, and warned again, naming who read it and when,
  as soon as its wording changed; more rows saying the same things needed no new review.

LabOps 26.12.0

LabOps v26.12.0

LabOps started again (26.10.0 and 26.11.0 could close at startup), and the lab dashboard could go on Panorama.

Important

If LabOps 26.10.0 or 26.11.0 closes as soon as it starts, it cannot update itself. Download
MacCossLab.LabOps-stable-Setup.exe below and run it; your settings and copies are kept.

New Features

• The lab dashboard went on Panorama. When LabOps-Projects' config/app.yaml named a folder
  (dashboard: {folder: /MacCoss/LabOps}), the Overview had Publish to Panorama and Open on
  Panorama. Publishing, after a confirmation, put a summary of every lab's open work on that
  folder's page: what was late or due in the next 7 days, how much work each lab had at each phase,
  and the instruments' bookings from two weeks back to four ahead, every list capped at 25 rows.
  From then on each lab member's LabOps kept it up to date after their projects reloaded, but only
  when their copy had just synced with GitHub, only a page LabOps had made, and never one edited on
  Panorama (publishing again took it back). Error messages stayed in LabOps; the page said only
  how many records had errors.

Bug Fixes

• LabOps started again. LabOps 26.10.0 and 26.11.0 could close straight away at startup ("Could
  not load file or assembly 'Serilog'"): the build had put the labops tool's list of libraries in
  place of the app's. The release checked the app's own list before publishing. A copy that does
  not start cannot update itself; download LabOps Setup from this release's page and run it.
• A page shown in LabOps loaded nothing from the web, frames included. The protocol preview and
  the Overview already ran no scripts and blocked images and scripts from the web, but a frame in a
  page could still have loaded a web address. Frames showed nothing but an empty or inline page.
• The timeline and the instrument schedule could be used without a mouse. Each bar could be
  reached with Tab, said its item, step and dates to a screen reader, showed them under it when
  focused, and showed its item in the list when clicked.
• An instrument listed twice with different capitals counted once. config/instruments.yaml
  with both "Stellar" and "stellar" gave one instrument, as first spelled, matching how
  experiments' instruments were compared.

LabOps 26.11.0

LabOps v26.11.0

The Projects area gained an Overview (what needs attention, a board, a timeline, a calendar and the
instruments' schedule) and steps could be planned, with late ones marked.

New Features

• Projects had an Overview. A List | Overview switch at the top of the Projects area
  showed the open work five ways:

  • Needs attention: late steps, steps due or starting in the next 7 days (today included),
    and records with errors, those in a lab's own record included.
  • Board: each open project and experiment at its current step, in columns from Samples to
    Results, late ones first and marked red.
  • Timeline: twelve weeks of each item's steps, what happened solid and what is planned
    dashed, late steps red, with a line for today.
  • Calendar: a month of steps started, finished, planned to start and due, three a day with a
    count of the rest; the arrows changed the month.
  • Instruments: each instrument's data acquisitions on the same weeks, with overlapping
    bookings listed and drawn red.

  Whose showed one person's work (steps assigned to them, and projects they are the lab
  contact for; in Needs attention and the calendar, only their own steps and the unassigned ones of
  those projects) and Lab one lab's. The overview opened on your own work when you had some.
  Work on hold was never shown as late, and its board card said "on hold". Late was said in words
  as well as in red, and people were shown by name. Clicking a project or experiment showed it in
  the list. The page ran no scripts and loaded nothing from the web.

• Steps had a Plan button. It set when a step should start and be finished (either date could
  be left empty, and Remove the plan removed both). The step then showed "Planned Oct 12 to
  Oct 20", in red with "late" once a date had passed and the step was not done.

• Steps could be planned. labops projects plan <item> <step>... --start DATE --finish DATE
  recorded when steps should start and finish (a date not given kept the one recorded, --no-start
  and --no-finish removed one, and --clear removed both), written on each step's line as
  planned_start and planned_finish; whatever it changed was one write. check
  refused a plan that was not dates or that finished before it started; nothing in the check depended
  on the day it ran. A step counted as late when its planned finish had passed and it was not done or
  skipped, or when its planned start had passed and it had not started.

• The lab's instruments could be listed. LabOps-Projects' config/instruments.yaml named the
  lab's instruments (- name: Orbitrap Astral); check warned about an experiment whose instrument
  was not one of them, and labops projects list gave the list. Without the file nothing changed.

• The README index listed only open work. labops projects index left closed projects and the
  closed experiments of open projects out of the table, with a line saying how many it left out, so
  the index stayed the size of the current work however many projects the repository held. check
  warned about an experiment still open in a closed project, which would otherwise drop out of view.

Bug Fixes

• A config file with a mistake no longer stopped every command. A config/people.yaml or
  config/instruments.yaml that was not valid YAML used to crash list, check and index (and
  the Projects area) and to crash a step change after it had written the record. check
  reported it as an ERROR and everything else carried on.

Breaking Changes

• LABOPS_PROJECT_ENGINE=python was removed. LabOps-Projects dropped scripts/project.py once
  LabOps 26.10.0 built the engine in, so the setting had nothing left to run. Setup's Project
  engine step said the engine was built in, and Claude was no longer allowed to run
  project.py in the projects repository, only labops projects.

LabOps 26.10.0

LabOps v26.10.0

The project engine moved into LabOps, so the Projects area no longer needed Python and its commands
ran three to seven times faster.

New Features

• The project engine was built into LabOps. The rules for labs, projects and experiments (the
  steps, the identifier check, the record edits, the wiki page, the Octopus files) used to run as
  LabOps-Projects' scripts/project.py through Python. They ran inside the app instead, rewritten in
  C# to give the same answers: every record it wrote was byte for byte what project.py wrote, and
  each wiki page was identical, so pages published before kept updating on their own. The Projects
  area stopped needing Python, and Setup's Project engine step said it was built in.
  • Claude's skills and the pre-commit hook could run the same engine as the labops tool
    (labops projects stage ..., with the commands and options of project.py), which LabOps kept
    in its tools folder. Claude could run it without asking.
  • The engine's messages, the comments it wrote into records, and the heading of the README's
    project index named labops projects commands rather than project.py.
  • LABOPS_PROJECT_ENGINE=python ran scripts/project.py instead, for this release only, in case
    the new engine missed something.

Bug Fixes

• Records the old engine stopped on were reported instead. Where project.py stopped with a
  Python error on a loosely written record, the engine said what to fix: an impossible date such as
  2026-02-30, a start date compared with a date and time, a step status it did not know, a number
  as a key in wiki.yaml, a record that was not UTF-8, or a step kind written as a list.
• Two record edits no longer damaged a line. A quoted value with " #" in it kept all of itself
  when the field was changed (it used to lose its end to the comment), and a funding value with a #
  in it was replaced rather than added a second time.

Performance

• Projects commands ran three to seven times faster. A command no longer started Python:
  listing the lab's projects took about 80 ms with the labops tool, against about 300 ms before,
  and the app ran the engine in-process, without starting anything.

LabOps 26.9.0

LabOps v26.9.0

LabOps has a new logo and app icon.

New Features

• LabOps had a new icon and logo. The app icon (a circuit and DNA mark on a rounded tile)
  replaced the old one in the window title bar, the taskbar, and the installed shortcut, and the
  logo was added to the top of the README.