MaveScape 0.8.0

Wave 8 of the roadmap: calibration, for research. A new view,
Calibrate, measures how far a run's scores separate variants whose effect is known: control sets
from ClinVar's records of the gene or a table of labels, each label in its source's words, with what
may make them circular; ROC and precision–recall curves with a seeded bootstrap, thresholds and the
functional classes they make, each checked against R; each class's evidence strength as Brnich et
al.'s OddsPath, and score-level likelihood ratios as acmgscaler computes them, always marked for
research and kept apart from a clinical classification, which MaveScape never makes. Nothing
calibrates by itself. A calibration is part of the record: the report and methods, figure panels,
the certificate (format 2), the checkpoint diff and a MaveDB deposit's score calibrations. Four
examples teach it: BRCA1, TP53 and PTEN calibrated against ClinVar, which shows how much of a strong
agreement may rest on classifications made since the assay, and a simulated calibration whose
circular labels overstate its evidence against the truth. 0.8.0 keeps two archives and a
certificate of its own, a calibrated workspace and one with an agent's calibration waiting.

Added

• Control sets and the Calibrate view (wave 8, slice 1): variants whose effect is known, for
  calibration (research use), each label as its source gives it and always shown with it ("ClinVar:
  Likely pathogenic ★★"). Made from the ClinVar track's records of the gene (pathogenic and likely
  pathogenic against benign and likely benign, at least one review star and missense variants by
  default, conflicting and uncertain records left out) or from a table of labels (CSV or TSV,
  numbered on the reference or the target, with its citation), placed on the target as the ClinVar
  track places its records, saying what was left out and why. The Calibrate view, the eighth, shows
  a set's composition, what of it the run shown scored, and what may make its labels circular:
  nonsense or synonymous controls on a scale they set, the design's own controls, ClinVar
  classifications evaluated since the assay was published, the assay's own publication, too few
  controls, a predictor whose classes were set with ClinVar. Kept with the workspace (its archive,
  history and checkpoints' diffs); an AI agent's are proposals. Remote actions and agent tools
  make_control_set, control_sets, remove_control_set, and functions in the R and Python
  packages.
• Calibrations (wave 8, slice 2): how far a run's scores separate a control set's P controls
  from its B controls, made when asked in Calibrate. Each side's scores against the run's; the ROC
  curve and its AUC with DeLong's interval, the precision–recall curve and its area (Keilwagen et
  al. 2014's interpolation), both with a seeded, stratified bootstrap's intervals and bands;
  thresholds set by the controls (at most 5% of either side in the other's class, or Youden's J)
  or given, and the functional classes they make (abnormal-like, intermediate, WT-like) for the
  controls and the run's variants; sensitivity and specificity with Wilson's intervals; and how far
  the bootstrap moves the thresholds. Where abnormal-like scores are comes from the design's
  readout, else the controls, and the calibration says when the controls run the other way. Kept
  with the workspace (its archive, history and checkpoints' diffs; deleted with its run or control
  set); an AI agent's are proposals. Remote actions and agent tools calibrate, calibrations,
  remove_calibration, and functions in the R and Python packages (60).
• Evidence strength, for research (wave 8, slice 3): each class of a calibration says what it
  would contribute as functional evidence, the abnormal-like class toward PS3 and the WT-like class
  toward BS3: its OddsPath as Brnich et al. (Genome Medicine 2020;12:3) define it, with one control
  of the other side added to each class as their model adds it, and the strength their Table 3
  makes of it; the bootstrap's interval and its share of samples at each strength, the thresholds
  kept. Beside it, what it rests on (the controls, each side's labels as their source gives them)
  and what limits it: thresholds set on the same controls, few controls in a class, a strength the
  bootstrap does not hold, circularity. The view says four things apart: how far the assay's scores
  separate the controls, a variant's functional class, the evidence strength a class would give,
  and a clinical classification, which MaveScape does not make. In calibrate's and
  calibrations' data.
• Score-level likelihood ratios, for research (wave 8, slice 4): each calibration's likelihood
  ratio at every score, as acmgscaler computes it (Badonyi 2025; ported from its R package 1.0.0,
  MIT, and equal to it): each side's kernel density in 1,000 bootstrap samples, their regularized
  log ratio made monotone, the samples' median with its interval; each variant's evidence strength
  from its interval's conservative end, and the score where each strength begins. The thresholds
  are Tavtigian et al.'s from a prior (0.1 by default, c = 350) or Pejaver et al. 2022's Table 1
  (prior 0.0441, c = 1,124). A plot of the ratio against the score, the thresholds, the controls;
  calibrate's prior and pejaver, and with curves each variant's ratio. R's numerics it rests
  on are MaveScape's own (rcompat.js), written from their publications.
• Published calibrations (wave 8, slice 4): a MaveDB record's calibrations of its scores listed
  in Calibrate, and, for a run of the record's published scores, a calibration with a published
  calibration's thresholds (calibrate's published), MaveScape's OddsPath on your controls beside
  the one it states.
• Calibration in the record (wave 8, slice 5), each calibration computed again from its run's
  scores wherever it is written:
  • the report and a run's methods: each control set (where its labels came from, its sides in
    their source's words, what was left out) and each calibration as computed, every method cited
    (pROC, Keilwagen et al. and PRROC, DeLong et al., Wilson, Brnich et al., acmgscaler, Tavtigian
    et al., Pejaver et al.), what limits it with the limitations;
  • figure panels of Calibrate's plots (Add to figure; add_figure_panel's calibration):
    each side's scores, the ROC and precision–recall curves, the likelihood ratio of a score; a
    figure's manifest names the calibration as kept, its control set's labels and its run;
  • the certificate: each calibration's numbers computed again and compared bit for bit (format 2,
    so that an older MaveScape says it cannot check one rather than skipping them), and the review
    report's section of them, every number traced;
  • the checkpoint diff: a run scored again and calibrated against the same set, its thresholds,
    AUC and each class's OddsPath before and after, and the variants whose functional class changed;
  • a MaveDB deposit's score calibrations (score_calibrations.json, MaveDB's
    ScoreCalibrationCreate): each class's range as abnormal, not specified or normal, bounded as
    MaveScape classes a score at a threshold, its OddsPath and strength, research use only; a
    package's calibrations listed as its published calibrations when it is opened, and passed
    through when its scores are deposited again.
• Classifications made before the assay (wave 8, slice 6): a control set can keep only the
  classifications last evaluated before a year (Last evaluated before in Calibrate,
  make_control_set's evaluated_before), ClinVar's by each record's date or a table's by its own
  column of dates (last_evaluated; ClinVar's tabular download is read as it is, its words such as
  "Benign; association" by their first term). Those made before the assay was published cannot rest
  on it; a dated table's made since are named as ClinVar's are. Nonsense or synonymous controls on
  published scores are named too: how the authors set their scale is not recorded.
• Four examples of calibration (wave 8, slice 6), each opening in Calibrate with its guide, every
  number in it checked:
  • BRCA1, TP53 and PTEN: published scores from MaveDB (Findlay et al.'s saturation genome
    editing, Giacomelli et al.'s etoposide screen, Matreyek et al.'s VAMP-seq) with ClinVar's
    records of the gene as NCBI gave them on 13 October 2026, bundled as the ClinVar track keeps
    them (web/examples/clinvar/) so that the numbers hold. BRCA1's evidence is strong for both
    classes, but rests on classifications made since the assay (made before it, moderate); TP53's
    is moderate and the bootstrap does not hold it; PTEN's abundance misses pathogenic variants that
    fold, with too few benign controls to say more;
  • a simulated calibration with circular labels: 100 dated classifications of a noisy simulated
    assay's missense variants, half made from the truth before the assay was "published", half
    made since from its own scores. The guide compares each calibration's classes with the truth:
    the circular labels lift the abnormal-like class to strong where the truth is moderate.
    make_control_set's source example makes the open example's labels a set; open_example
    names the four.

Changed

• The likelihood-ratio plot's threshold names are a little larger (9/10 of the text) and move apart
  where they would overlap, so a figure's smallest text stays at 6 pt or more.
• A table of labels' column names are matched without case and with spaces as underscores, so
  "Germline classification" or "Protein change" are found as germline_classification and
  protein_change are.

Fixed

• A count of 0 giv...

MaveScape 0.7.0

Wave 7 of the roadmap: agents and scripts. mavescape mcp makes
MaveScape a Model Context Protocol server, so an AI agent such as Claude Code calls its 54 actions
as tools in the window you watch: it opens data, scores, reads the quality control and the scores
as tables, looks at the map, the structure and figures as pictures, compares, makes figures and
certifies. Its changes are proposals: what it makes is marked proposed and usable at once, while a
design, QC thresholds, an acknowledgement, a target's check, MaveDB details or a removal waits; you
accept or reject them above the view, and every change carries the agent's name in the workspace's
hash-chained history. R and Python packages make each action a function, tables coming back as data
frames and pictures as files, with a notebook on GRB2 and a script on DHFR's two conditions as
examples; the guide Agents and scripts follows an agent through a session on Hsp90. 0.7.0 keeps
two archives and a certificate of its own, one archive saved with an agent's proposal open, which
every later version must reopen as 0.7 decides it.

Added

• mavescape mcp, an MCP server for AI agents (wave 7, slice 1; mcp.go, after CytoWeave's).
  It starts MaveScape with remote control on and speaks the Model Context Protocol on stdin and
  stdout (JSON-RPC, protocol versions 2024-11-05 to 2025-11-25), its banner and logs on stderr; the
  window opens when a tool first needs it (--window), and MaveScape stops when the agent closes
  stdin. Its tools are the 54 remote actions under their names, each with a title and MCP's hints
  (read only; replaces or removes something; may ask a public service), and its instructions say
  where to start and that scores are never a clinical classification. A call reports progress
  while it runs long and may be cancelled; files are read and written by absolute path, an
  existing one never replaced unless asked. Each change an agent makes is recorded in the
  workspace's history with the agent's name (by, covered by the entry's hash), shown in the
  history and the report's decision log. docs/MCP.md gives the setup for Claude Code and other
  clients, the tools by area and the product requirements' names for them.
• GET /api/remote/tools gives each action's title and hints too.
• An agent's changes are proposals (wave 7, slice 2; web/lib/proposals.js, after
  CytoWeave's). What an agent makes (tables and targets it opens into your workspace, runs,
  selections, tracks, structure views, figures and the panels it adds to yours, analyses kept in
  the report, checkpoints) is made at once and marked proposed, so that it and you can use it
  meanwhile; a design it sets or drafts, QC thresholds and acknowledgements, a target's check, the
  MaveDB details and every removal wait until you accept them. A strip above the view says who
  proposes how many changes, lists them, and has Accept all and Reject all; rejecting
  removes what the agent made with what was built on it since (MaveScape asks first), and puts back
  the items of yours it changed. Each decision is one entry of the history, yours, and can be
  undone; what was held is applied under the agent's name. The views mark what is proposed: the
  dataset tree, the design proposed beside yours with how they differ, the QC view, the figures'
  panels, the report's kept analyses and checkpoints. Nothing is certified while a proposal is
  open. The report has an AI agents section (what agents proposed and you accepted), and a
  checkpoint's diff names who proposed what was added. Scripts' changes are not proposals.
• Two actions: set_qc_thresholds (a script's apply at once, an agent's wait) and proposals (what
  waits for the person, and the latest decisions).
• Results as data and pictures (wave 7, slice 3). scores gives a run's variants as a table
  with the columns of its scores export (or a contrast's differential scores, or a nucleotide run's
  at the protein level), numbers as numbers: those at positions, of kinds, in a saved selection or
  matching a query, sorted by a column, a page at a time. provenance gives a run's provenance
  inline. render_map with image gives the map as a picture (its SVG export drawn as a PNG, at a
  scale, of the whole target or a stretch of positions), render_structure the Structure view with
  its legend, and figures with image each page as exported. mavescape mcp sends the pictures
  to an agent as images it can look at; a script gets them as data URLs.
• R and Python clients (wave 7, slice 4; clients/, after CytoWeave's): the packages
  mavescape for R (curl and jsonlite) and Python (the standard library; pandas for data frames)
  make each of the 54 actions a function with its arguments and help (ms_scores(),
  ms.scores()), generated from clients/tools.json, which a Go test keeps equal to the actions.
  They find the running MaveScape through remote.json; tables come back as data frames, pictures
  as files (file = on render_map, render_structure and figures), and an action refused is
  an error carrying MaveScape's reason. Installed from the repository; their version is
  MaveScape's.
• The guide to agents and scripts (wave 7, slice 5): docs/MCP.md with the setup for Claude
  Code, Claude Desktop, Cursor, VS Code and Codex, the options, a check that MaveScape answers,
  what to ask, proposals with two screenshots (Claude Code's proposal reviewed, and accepted in the
  history) and troubleshooting; the website's page Agents and scripts (formerly Remote control,
  headless runs and scripting, at the same address), agents first; the README's section AI agents
  and scripts. The documentation's capture has two scenes of an agent working through mavescape mcp, as Claude Code's client does.
• Examples for scripts and agents (wave 7, slice 6): a Python notebook on GRB2
  (clients/examples/grb2-sh3.ipynb, kept with its outputs: the example opened and checked, its
  QC as a data frame, scored again with the DiMSum-compatible preset, both runs against the
  record's published scores, a figure exported as PDF and PNG) and an R script on DHFR's two
  conditions (clients/examples/dhfr-lon.R: the fast growers of each, the authors' unweighted
  regression against the published scores, the 377 differences called and the residues they
  replace, a plot and MaveScape's map). The guide's A session on Hsp90: an agent's prompts, tool
  calls and answers, from comparing the published scores to a design proposed, accepted and scored,
  with a screenshot of the proposal reviewed.

Changed

• An agent's tool results say when what it did waits for the person, and score waits for a design
  the agent proposed. The MCP server's instructions say how proposals work.
• The website's Figures page shows the figure of its screenshot as MaveScape exports it: a PNG at
  200 dpi with its manifest inside, to download and drop on the window (the capture's figures scene
  writes it, docs/images/figure-export.png; the site's build takes such a file as <artwork>).

Fixed

• compare said "Kept in the report." after every comparison, kept or not: it read the
  comparison's own report of compatibility as the analysis kept. It says so only when report is
  given, and the kept analysis's id is in inReport, beside the comparison's report.
• open_example's description named four of the fourteen examples (none of those from MaveDB, nor
  Hsp90 or factor IX), so neither an agent nor the clients' help knew their ids. It names every
  one, and a Go test keeps it so.
• The drawer's tabs and its close button were in one tab list, which may hold only tabs (axe-core's
  aria-required-children, found by the new scene with the drawer open): the tabs have a list of
  their own.
• The map's SVG and PNG export of a short target cut its key to the states (and could cut its
  title): the page was only as wide as the cells. It is at least as wide as both now.
• A run focused in the dataset tree that is no longer in the workspace (undone, or an agent's
  rejected) left the Structure view without scores to color by, saying the workspace had no run;
  it is passed over now.
• A figure exported as PNG left its last row (or column) of pixels partly transparent: its size in
  points rarely makes whole pixels (a page 178 mm tall is 1,401.6 pixels at 200 dpi), and only the
  page's own background was painted. The whole image is white now before the figure is drawn.

Validation

• validation/agent-session.mjs (CI job agents): mavescape mcp driven over stdio as
  an agent's client drives it, with no model, every one of the 54 tools called on the examples in
  headless Chrome: initialize and the tools' list (the remote actions with their titles and
  hints), errors, the runs' output hashes, a variant's score and a query's variants Node's, a
  comparison the remote action's field for field, the record through the agent (a figure and its
  manifest, a checkpoint, a certificate verified in Node), every tool said to read only leaving the
  history as it was, every change the agent made carrying its name, stdout nothing but JSON-RPC,
  and MaveScape stopped when stdin closes. Go tests of the protocol (mcp_test.go): versions, the
  tools, a call reaching the page under the agent's name, required arguments, files by path,
  cancellation and progress, the real command's stdout, and docs/MCP.md naming every tool.
• The agent session (26 checks) also acts as the person, in the window: each kind of change held or
  made at once as it should be, said in the tool's result and in the views; accepted (applied under
  the agent's name, the decision the person's, the history's chain intact) and ...

MaveScape 0.6.0

Wave 6 of the roadmap: figures and a provable record. A figure is a
page of panels at a journal's column width, each panel a view's own plot (the map with its tracks,
a structure view, a QC finding's charts, the scores, a comparison, a variant's evidence), drawn
again from the analysis until it is exported; exported as SVG, PDF or PNG, it carries what each
panel was drawn from, and dropped on the window it says what has changed since. The Report view
writes the methods of the whole workspace, with every reference checked against Crossref and the
comparisons and robustness checks you keep in it; checkpoints keep the analysis as it stood, and
what changed since is said variant by variant. A certificate computes every number the workspace
reports again from its files, and mavescape verify checks it bit for bit; its review report is
one file a reviewer opens in any browser, every number traced to where it comes from. Three
examples end with these: GRB2's figure, Hsp90's checkpoint and BRCA1 RING's certificate. Workspaces
saved by 0.1.0 to 0.5.0 open, reproduce their runs and certify; two saved by 0.6.0 and its
certificate of one are kept for later versions to reopen and verify.

Added

• Figures (wave 6, slice 1). The Figures view holds the workspace's figures: a page at a
  journal's column width (one column, 85 mm; one and a half, 114 mm; two columns, 174 mm), a 16:9
  slide or any size, its text set in points at the printed size (7 pt), its panels lettered A, B,
  C… in reading order. A panel is a run's variant-effect map (a condition, or a difference between
  conditions; its coloring, row order and palette; a range of positions; the tracks below it, the
  color bar and the key to its states) or text. Panels are dragged and resized, snapping to the
  page's margins and to each other's edges, nudged with the arrow keys, placed exactly in
  millimeters, and every change can be undone; making or deleting a figure and adding or removing a
  panel are in the workspace's history. A panel says what it shows, so the figure is drawn again
  from the workspace whenever it is shown and follows a rescoring until it is exported; figures are
  kept in the workspace and its archive. Add to figure in the Map view takes the map as it is
  shown (the positions in view, the tracks shown). Text under 6 pt at the printed size, positions
  narrower than 0.6 pt and text that does not fit are said under the page.

• Figures exported as SVG (vectors, text as text, each map cell named by its variant, the figure
  in words as its <desc>), PDF (one vector page at the printed size, text in Helvetica), PNG at
  300 or 600 dpi of the printed size (its resolution in the file), or to the clipboard. The same
  figure is the same bytes when written again. One drawing (web/lib/draw.js: marks painted on a
  canvas, written as SVG, written as PDF) makes the view and every export, in Node as in the page;
  the PDF writer is CytoWeave's (web/lib/pdf.js, web/lib/png.js).

• Remote control: figures, create_figure, add_figure_panel, set_figure and
  export_figure. FORMATS.md describes a figure's document and files; the guide's Figures page,
  with a screenshot.

• Every view's plots as figure panels (wave 6, slice 2). Add to figure beside each plot:
  a QC finding's charts (in its detail pane), a run's scores by class, its filter flow and a
  contrast's volcano (Score), the comparison shown (one against the other, Bland–Altman, the
  disagreement by position, a predictor's classes, either side's map or the map of the
  difference), a variant's evidence (the inspector: its score and 95% interval with each
  replicate's ± 1.96 SE; its time course or bins chosen in the Figures view), and a saved
  structure view (its figure panel, drawn at 4× on white and kept with the figure, in the library
  and the archive; drawn again on request when the view is saved again). A plot panel lays out its
  charts at the figure's text size, each with its heading and legend, the room shared by what each
  needs, and its properties choose what it shows and its title; a bar label shrunk under 6 pt, too
  little room and an image under 300 dpi are said. add_figure_panel takes every kind, and
  export with what: "structure-image" takes light.

• The views draw their plots with the same module as figures (web/lib/plots.js; the QC
  findings' charts in web/lib/qc-plots.js, the Score, Compare and inspector plots in
  web/lib/view-plots.js), so a panel is the view's plot at the figure's size.

• Figures that carry their analysis (wave 6, slice 3). Every exported figure carries its
  manifest (web/lib/figure-manifest.js): the figure's document and, panel by panel, what it
  shows, what it was drawn from (each run by its output's SHA-256 and its table's, the QC
  thresholds and the finding's acknowledgement, a comparison's sides, a track's file, a structure
  view's image) and a digest of its drawing; the workspace, MaveScape's version and commit; and a
  fingerprint that catches an edit. It is in the SVG's <metadata>, a PNG iTXt chunk and a file
  attached to the PDF; export_figure's json format writes it alone.

• A figure dropped on the window says what it shows, where it came from, whether its manifest is as
  written, and panel by panel whether what it was drawn from is as then, changed since (saying
  what) or not in this workspace; it opens the workspace it came from when the library holds it.
  Rebuild here adds it to the workspace, draws each panel again from its inputs and compares
  each drawing with the one recorded. Remote control: check_figure (with rebuild).

• mavescape export --format figures writes every figure of a workspace archive as SVG, PDF and
  PNG at 300 dpi, each with its manifest, and figures.json.

• The Report (wave 6, slice 4). The Report view holds the methods of the whole workspace,
  written again on every change from its record (web/lib/report.js): each run's data, design,
  scoring and QC as its own methods say them (runs that read the same named together), a table of
  every run's parameters as parameters.json names them, the QC thresholds changed and the
  findings acknowledged; the comparisons and robustness checks added to it; the saved selections
  with their queries, the annotations, structures and figures (each panel by its letter); every
  input's SHA-256; the software and each run's output hash; the decision log (the history, entry
  by entry); the limitations (what the counts did not record, each model's assumptions, findings
  not acknowledged, a predicted structure); the research-use statement. References are numbered
  as the text first cites them, only those it cites, with their BibTeX. Copied as Markdown or
  downloaded; the workspace archive carries it (report.md, report.bib).

• Add to report, under a comparison's compatibility report and in a run's robustness pane:
  the workspace keeps what the analysis found (analyses, in its history), and the report says it
  with its methods cited (Lin's concordance, Bland and Altman's limits of agreement, Bonett and
  Wright's interval, DeLong's, a multiverse analysis). Removing a run takes out the analyses that
  read it.

• Remote control: report (each section, the Markdown and BibTeX; remove an analysis kept),
  report: true on compare and check_robustness, export of report and
  report-references, and set_mode of figures and report. mavescape export --format report
  writes report.md and report.bib without a window.

• Checkpoints and what changed (wave 6, slice 5). A checkpoint keeps the analysis as it
  stands, named (the workspace's state without its history, by its SHA-256, and the history's hash
  then), with the workspace and in its archive; kept from the Report view, the drawer's history or
  remote control's checkpoint. The diff (web/lib/diff.js) says what changed from a checkpoint to
  now or another, or between two archives, in words: the tables, targets, design, runs scored and
  removed, QC thresholds and acknowledgements, selections, annotations, structure views, figures,
  the report's analyses and MaveDB details. For each table's latest run it says how its parameters,
  filters and design changed and what that did: the variants whose effect moved beyond the earlier
  95% interval, changed class, or were newly filtered or scored, the most moved by name, the QC
  findings whose verdict changed, and a map of the change. Shown above the report; remote diff.
  The report names the checkpoints.

• Reproducibility certificates (wave 6, slice 6). A certificate (web/lib/certificate.js) is
  the workspace archive with every number the workspace reports, computed again from its files:
  each run's scores, SEs and classes (and each difference between conditions'), its QC findings
  and a digest of every number its QC computed, the comparisons and robustness checks kept in the
  report, each figure panel's drawing (as the figure's manifest records it) and the report. It
  names the workspace and every file it reads by their SHA-256, the history's head and the
  checkpoints; it says what it does not compute again and what making it found; and its
  fingerprint, the SHA-256 of what it records, names exactly what was certified. The tables can be
  left out (named by their SHA-256) for data that cannot be shared. Made from the Report view's
  Certificate pane (in a worker) or remote control's certify; the same workspace gives the same
  bytes in the window and in Node.

• mavescape verify checks a certificate without a window: its fingerprint, its files, the
  history's chain, each checkpoint's state and each run's id, then every number computed again and
  ...

MaveScape 0.5.0

Wave 5 of the roadmap: variants in 3D. MaveScape draws a protein's
structure itself, a PDB entry, an AlphaFold DB model or a file of your own, with the viewer it
shares with Proteoscope, and needs no other program. The target is mapped onto every chain that
holds it, position by position, checked against SIFTS. Residues take their positions' scores in the
map's colors, and a selection is shared between the map and the structure. What the structure says
of each position (secondary structure by DSSP, accessibility, exposure and disorder, contacts with
partners) becomes tracks beside the map, the scores by structural class are tested, and a test asks
whether the least tolerant positions cluster beyond what burial explains. Views of a structure are
saved with the workspace, its archive and methods, the structure's file kept by its SHA-256, and
figure panels carry their legend and what they show. A Proteoscope running on the same computer
opens the view as its own session. Workspaces saved by 0.1.0 to 0.4.0 open and reproduce their runs;
two saved by 0.5.0 are kept for later versions to do the same, their saved views drawn again.

Added

• The Structure view (wave 5, slice 1; X1). A protein's structure in MaveScape, needing no
  other program; the Structure view follows Compare.

  • Opening: a PDB entry by its ID, an AlphaFold DB model by a UniProt accession (the target's
    by default), or a file of your own: PDB, mmCIF or BinaryCIF, gzipped or not, opened from the
    view or dropped on the window. One structure is shown at a time, for the session; it is not
    yet saved with the workspace.
  • The program's new requests (structures.go; docs/NETWORK.md): an entry's coordinates
    from RCSB PDB (/api/fetch/pdb/{id}), and a protein's AlphaFold DB entries and model
    (/api/fetch/alphafold/{accession}/prediction, …/model/{version}). Each sends a PDB ID or an
    accession only; a structure is cached compressed, as the service sent it, once it is read to
    its end and found whole, and opens offline after that.
  • Drawing: Proteoscope's renderers, copied with their tests (web/lib/structure/): WebGPU
    (impostor spheres and cylinders, the cartoon, surfaces, ambient occlusion, picking), or the
    Canvas renderer where the browser offers no WebGPU or ?renderer=canvas asks for it, the badge
    above the view saying which and why.
    • Styles: cartoon, ball and stick, sticks, spacefill, trace.
    • Colors: chain, entity, rainbow, secondary structure, molecule type, element, residue class,
      hydropathy, nucleotide, B-factor, a predicted model's pLDDT; a legend.
    • Surfaces (molecular, solvent-accessible, van der Waals, Gaussian), computed in a worker.
    • Biological assemblies, built by the entry's own operators.
    • An image of the view (PNG).
  • Residues selected by click or in Proteoscope's selection language (resn CYS, chain A and resi 40-80, byres (protein and within 4 of nucleic), plddt < 70), drawn as sticks, ball
    and stick or spacefill, hidden, labeled, and focused on (the camera on them, their neighbors
    within 5 Å with their side chains).
  • In words: the entry's title, method and resolution (or that it is a prediction), its
    chains with the residues observed and the UniProt residues each covers, and what else it holds.
  • Remote control: open_structure (a PDB ID, or an AlphaFold DB model; "target" for the
    target's) and set_structure (style, color, surface, assembly; select, show, label, focus);
    open_files opens structure files; get_state gives the structure shown.
  • The factor IX example's sixth step opens PDB 1RFN and draws its cysteines as sticks: seven
    disulfide bonds, one joining its two chains. The guide page Structures.

• The target mapped onto structures (wave 5, slice 2; X2). The workspace's target is placed on
  the structure shown, position by position, whatever the entry's numbering.

  • The mapping (lib/mapping.js): the target's protein aligned to each chain's sequence (the
    entry's SEQRES, its residues observed marked) by Proteoscope's overlap alignment
    (structure/align.js, copied with its tests: BLOSUM62, affine gaps, free end gaps). Each
    position is on a residue (identical, or another with the entry's reason: an engineered
    mutation, a conflict), not observed, missing from the structure's sequence, or outside it; a
    position is ambiguous where an alignment that scores the same places it otherwise. The entry's
    own record of the UniProt residues each chain covers is compared, residue by residue, and a
    shift said. Every chain that holds the target is mapped; the one that holds the most is
    chosen, and another can be.
  • Structures of the target: the PDB entries that cover it, from PDBe's SIFTS
    (/api/fetch/pdbe/best-structures/{accession}, the accession only), ranked by the target
    positions each covers, then resolution, with its AlphaFold DB model first; each opens with the
    target mapped on its chain.
  • Positions on the structure: pos 30-40 (the target's) and uniprot 188-198 (the
    reference's) in the selection language; a selection is kept, position by position, when
    another structure is opened, an experimental one or the AlphaFold DB model; a residue pointed
    at says its target position.
  • The mapping in words beside the view, its residues selected by state, and written out
    (<entry>_chain-<chain>_mapping.csv; FORMATS.md).
  • Remote control: find_structures, map_structure; open_structure takes a chain;
    export writes structure-mapping; get_state and open_structure give the mapping.
  • Factor IX's sixth step opens 1RFN from the structures of the target and reads its
    mapping: chain A at 227–461 though numbered as chymotrypsin is, chain B at 132–188, which the
    entry's own record numbers five earlier.

• Scores on the structure (wave 5, slice 3; X3). Each residue of the target takes its
  position's scores, in the map's colors (lib/structure-scores.js, ui/structure-coloring.js).

  • Colorings: the median, mean, lowest or highest score of a position's missense
    substitutions; the fraction abnormal-like (below or above a threshold set by hand, or by a MaveDB
    record's published calibration, for its scores as published); how many are scored; one
    substitution; the uncertainty (median SE); the disagreement of the two sides Compare shows;
    the QC state. On every chain that holds the target.
  • The map's grammar: its palette and scale, centered on the wild type; filtered and missing
    positions drawn in grays the palettes do not hold, never in the wild type's color; a value
    from scores of low confidence only drawn paler; a legend, with how many positions are in each.
  • The run and condition the map shows (or its contrast) are those colored by, chosen here or
    on the map.
  • A strip of the target's positions below the view: their colors, which are on the
    structure, and an AlphaFold DB model's confidence beside them; a click or a drag selects.
  • One selection for the map and the structure: a residue picked selects its position's
    variants on the map (as at selects them) and puts the position in the inspector, a new
    section with its substitutions' scores and its residue on each chain; a selection made on the
    map is drawn on the structure; residues selected in words are selected on the map too. With
    residues colored by scores, a selection is shown by its side chains, not by a tint.
  • The coloring written out (<entry>_chain-<chain>_<coloring>.csv; FORMATS.md).
  • Remote control: set_structure's color takes the scores' colorings (with
    substitution, threshold, side, calibration), pick picks a residue as a click does;
    export writes structure-scores; get_state gives the scores colored by.
  • The GRB2 example's sixth step colors 2VWF by the median score: the core is the least
    tolerant, and the residues that touch the Gab2 peptide score near the wild type, an abundance
    assay not seeing binding. Its fourth step now points to what the analysis can do.

• Structure as evidence (wave 5, slice 4; X4). What the structure shown says of each target
  position (lib/structure-evidence.js, ui/structure-evidence.js), on the chain mapped:

  • Measures: DSSP's secondary structure; the accessible area by Shrake–Rupley with DSSP's
    radii, in the chain alone and in the structure, relative to Tien et al.'s maxima;
    StructureMap's exposure (pPSE) and disorder, with an AlphaFold DB model's aligned error;
    pLDDT; the nearest partner (another chain, a ligand, an ion; common crystallization additives
    only when chosen), within 4 Å an interface, its contacts typed by PLIP's rules. Proteoscope's
    exposure.js and interactions.js copied with their tests.
  • Structural classes: disordered, interface, buried or exposed; a coloring of the structure,
    a row of the strip, words when a residue is pointed at or picked (the inspector).
  • Tracks beside the map: the classes and secondary structure, shown; the accessibility,
    exposure, distance and pLDDT, to show. The query language reads them as features (in feature buried).
  • The scores by class: each class's positions and median score, against the rest by
    Mann–Whitney's test, BH-adjusted; a class's residues selected.
  • Clusters: whether the least tolerant positions (10–30%) make more pairs within 8 Å than
    positions of the same burial (seeded draws within strata of relative accessibility), with the
    same burial ignored beside it; compact groups of them...

MaveScape 0.4.0

Wave 4 of the roadmap: compare. Two replicates, conditions or runs of
a workspace, or a run and a MaveDB score set or a predictor kept beside it, are compared after a
report that says what their agreement can mean, by statistics checked against R, with their maps,
their difference and the variants and positions that differ beyond their uncertainty. Two assays go
on one scale by their anchors, the anchors' uncertainty carried into the tests. A run is scored
again across other reasonable analysis choices, and each variant's conclusion is said to hold or to
depend on a choice, which is named. Variants are selected on the map by click, rectangle, freeform
shape or a query in words, saved with their queries, combined, and carried across the views. There
are fourteen examples. Workspaces saved by 0.1.0, 0.2.0 and 0.3.0 open and reproduce their runs; two
saved by 0.4.0 are kept for later versions to do the same.

Added

• Comparisons within a workspace (wave 4, slice 1; C1–C3). The Compare view (after Map) puts
  two sets of scores side by side: two replicates of a run, two conditions, or two runs (a
  rescoring, or a MaveDB record's published scores against its counts scored again). It starts
  with the pair a workspace most likely asks for, and Swap exchanges them.

  • A compatibility report comes first, each item ok, qualified or blocked:
    • the targets: the same sequence, or two stretches of one UniProt entry (each with its
      accession and offset), matched on the entry's coordinates; no common reference blocks;
    • the level: a nucleotide run read at the protein level against a protein-level side;
    • the variants scored on both sides, and those on one side only (fewer than 10 in common
      block);
    • the directions: opposite ones compare the second side negated;
    • the assays;
    • the scales: on different or unknown scales (published scores are on their record's own),
      only the correlations are given;
    • independence: replicates sharing a sample, a replicate inside its condition, one table
      scored twice, or a record's published scores against its own counts.
  • The agreement of the variants scored on both, each with its 95% interval:
    • Pearson's r and Spearman's ρ (Bonett and Wright's interval);
    • Lin's concordance correlation, with its accuracy, scale shift and location shift;
    • Bland–Altman's bias and limits of agreement, and the trend of the differences with the
      means;
    • the scatter plot (y = x drawn on one scale) and the Bland–Altman plot; a variant clicked is
      shown in the inspector and ringed.
  • Exports: the matched variants (*_comparison.csv), and the report and statistics with
    each run's output hash (*_comparison.json).
  • Remote control: compare (the sides by name) and export of comparison; set_mode
    shows compare.
  • Guides: the BRCA1 saturation genome editing example's last step compares its counts,
    scored, with the published scores; the guide page Comparisons.

• Comparisons across the map (wave 4, slice 2; C2). The Compare view has three tabs:
  Agreement, Maps and Disagreement.

  • Filters, by confidence and depth: leave out variants of low confidence on either side,
    those with an SE above a maximum, or those with fewer input reads than a minimum. The report
    says how many each filter left out. A side with no SEs or counts (published scores) is not
    filtered on them, and the report says so.
  • Maps: the first side's map, the second's, and the map of their difference (first − second,
    for two sides on one scale), panned and zoomed as one (two stretches of one protein lined up
    on its coordinates). A variant clicked is selected in each. Each exports as SVG.
  • Disagreement:
    • the variants that differ beyond their uncertainty: each difference's z from both SEs, and q
      by Benjamini–Hochberg, for two independent sides on one scale;
    • the dispersion, which says whether the SEs describe how far the two differ, and warns when
      they don't (GRB2's replicates differ 8 times as much as their counting SEs say);
    • the disagreement by position, as bars and the ten that differ most, each position with 3
      variants or more tested.
  • Exports: the variants compared with their z, p and q; the positions (*_comparison_positions.csv);
    the report with the discordant variants, the dispersion and the positions; the three maps.
  • Remote control: compare takes low_confidence, max_se, min_reads and show (the
    tab), and returns the discordance and the positions; export writes comparison-positions
    and comparison-map (map: first, second or difference).
  • The DHFR example has a sixth step: −Lon against +Lon, low confidence left out (r 0.52 →
    0.77), its discordant variants (201, 186 lower with Lon), its positions, and its maps.

• The map component tells others its pan and zoom, and takes theirs, so that maps shown together
  move as one.

• Other sources and scales (wave 4, slice 3; C1, C3).

  • A MaveDB score set compared without opening it. Under Other sources in Compare, a score
    set's URN fetches its record and published scores (only the URN is sent), kept beside the
    workspace and in its archive (an annotation, mavedb-scores). Its scores are read as published,
    as opening the record would, on the record's own target. MaveDB records no direction: say what
    a higher score means when adding it, or under Sides (in the history). Its scores are also a
    track beside the map.

  • Another assay of the same protein: matched on one sequence, or on UniProt's numbering.
    PTEN's abundance against its lipid phosphatase activity agrees only in part (ρ 0.37).

  • A predictor: AlphaMissense (from AlphaFold DB), or a predictor's file (EVE, ESM1b, any
    table), placed on the run's protein as its track is. Compared by rank (Spearman's ρ; Pearson's
    r, Lin's concordance, Bland–Altman and the tests of disagreement withheld), and by its classes
    in a new Classes tab:

    • the measured scores in each class, with the synonymous and nonsense medians for reference;
    • the AUC of telling the tolerated class from the damaging one, with DeLong's interval.

    AlphaMissense's and EVE's scores are compared negated. EVE's table gives its classes.

  • Scale:

    • as scored;
    • stated to be on one scale (two score sets of one study and one pipeline);
    • each side rescaled by its own anchors: nonsense median 0 and wild type 1, or synonymous
      median 0 and nonsense median −1.

    Rescaled, two assays get Lin's concordance, Bland–Altman, the difference map and the tests of
    disagreement. The report names each anchor, and the tests carry the anchors' uncertainty. GRB2's
    Run 1 against its record's published scores: r 0.997 on two scales; rescaled, ρc 0.996 and a
    bias of 0.009.

  • Exports: *_comparison.csv gains compared_a and compared_b (each score as compared); a
    predictor's classes (*_comparison_classes.csv); the report adds scale, classes and each
    side's source.

  • Remote control:

    • compare takes a score set's URN (fetched and kept first) or a predictor by name, scale,
      direction and show: classes;
    • export writes comparison-classes;
    • add_track takes mavedb-scores with a urn.

  • The PTEN example's guide compares its abundance with the phosphatase activity score set, not
    opened, and with AlphaMissense by class (its record and calibrations now one step). The GRB2
    example says what its comparison with its record shows.

• Robustness to analysis choices (wave 4, slice 4; C4). Below a run in Score, Check robustness
  scores it again across other reasonable choices, in the score worker (DHFR's 48 analyses in about
  3 s): each alternative alone, then combinations drawn with a fixed seed. CytoWeave's
  specification-curve pattern, lib/robustness.js.

  • What is varied, where the design allows it:

    • the pseudocount (0.1, 0.5, 1);
    • the normalization;
    • the model of uncertainty (DiMSum's error model with replicates scaled and shifted;
      ordinary least squares, or the first and last time points, and a regression's SE);
    • the combination of replicates (moderated, REML, fixed effects, their mean);
    • low-depth measurements removed, two replicates at least, every time point;
    • each replicate left out.

    Fixed effects are not tried where the replicates differ more than their SEs say, and the pane
    says why.

  • For each variant and each difference between conditions: its effect (against the wild
    type's), rank, SE, inclusion and class (lower than, like or higher than the wild type, q < 0.05)
    in every analysis. Its verdict:

    • robust;
    • fragile: a choice moves its effect beyond its 95% interval and changes its class, the choice
      named;
    • depends on its uncertainty;
    • borderline;
    • its effect's size depends on a choice;
    • not always scored.

  • Also reported:

    • how many calls hold in every analysis and in 90% of them;
    • each alternative's effect (the classes it changes, effects moved, variants dropped, the
      typical move, rank correlation);
    • the least tolerant positions;
    • a variant's robustness in the inspector.

  • Exports and remote control: *_robustness.csv, *_robustness_positions.csv and
    *_robustness.json; remote control's check_robustness, and export of robustness and
    robustness-positions.

  • The DHFR example's guide checks Run 1: of its 377 differences between the conditions, 54
    hold in every analysis. The guide page *Robu...

MaveScape 0.3.0

Wave 3 of the roadmap: public data in and out, through a fixed list of
services that only the program contacts. A target is checked against its UniProt entry; any
published MaveDB score set opens by search or URN, its scores as published and its counts to score
again, and several of one target open together as conditions to compare. The whole of MAVE-HGVS is
read (nucleotide variants for the protein changes they make; targets from GenBank files and
transcripts); a run becomes a MaveDB deposit that MaveDB's own validators accept; annotations line
up beside the map as tracks; and there are thirteen examples. Workspaces saved by 0.1.0 and 0.2.0
open and reproduce their runs; three saved by 0.3.0 are kept for later versions to do the same.

Added

• Public data through one list of services (wave 3, slice 1). The MaveScape program fetches
  public data for the page, which contacts nothing else, from a fixed list of hosts (MaveDB,
  UniProt, RCSB PDB, PDBe, AlphaFold DB, NCBI E-utilities, Ensembl, gnomAD), each with the paths
  it may be asked for, checked as every request is sent, redirects included. Requests carry
  public identifiers. Each answer is cached with its retrieval record (the service, the URL, when
  it was retrieved and last confirmed, its ETag and release), checked again after 30 days, and
  served from the cache, marked stale, when the service cannot be reached. Answers have size
  limits, applied after decompression; brief outages are retried. --offline serves cached copies
  only and sends nothing; --no-fetch switches public data off; --cache-dir moves the cache
  (by default <user cache dir>/MaveScape). A request that would send a sequence is made only
  once you have seen exactly what it sends and confirmed it, and the cache keeps its answer
  without the sequence. docs/NETWORK.md
  lists every host and request and what each sends. The cache and the download, limit and serve
  parts of the fetcher are adapted from Proteoscope 0.10.0.
• A target checked against its UniProt entry (wave 3, slice 1). Experiment, Target: Check
  against UniProt fetches the entry the target's accession names and shows where the target (or
  the protein a DNA target encodes) sits in it, how it differs, and what the entry would change:
  the offset, the accession and gene, the species, the known differences. Use these sets them;
  either way the check is recorded with the workspace (entry, release, date and placement), shown
  in the target pane and the inspector, and named in the methods, which cite UniProt. Recording a
  check that changes nothing leaves the design and its runs as they were. A tag or linker hanging
  over an end is allowed and named; a target that fits equally well in several places keeps its
  offset; an inactive accession is reported with the entries that replaced it. A target with no
  accession can be found by its exact sequence (Find in UniProt by sequence…), after
  confirming that the sequence may be sent. The remote action check_target (with apply)
  does the same for scripts and sends only the accession.
• MaveDB, opened by search or URN (wave 3, slice 2). Open from MaveDB (the Start page, the
  workspace menu, ⌘K) searches MaveDB's published score sets, 100 at a time, or takes a URN or a
  MaveDB address; mavescape urn:mavedb:… (or --mavedb) opens one at start, or in the MaveScape
  already running. A record is shown before it is opened: its license and what it allows (with a
  warning for one that restricts use: CC BY-NC-SA, or the record's own terms), citation, target (with its UniProt offset), what it
  holds, the assay in MaveDB's controlled terms, and its published calibrations, each class with its
  range of scores and, for a clinical calibration, the evidence strength it assigns (as published,
  for research). Opened, it becomes a workspace: its published scores as a run of their own, its
  counts (when deposited) with a design drafted from their column names, the record kept with the
  workspace and named in the methods. The experiment's keywords give the design's readout and
  library method. Records, tables and searches are cached, so a score set opened once opens again
  offline. Remote actions search_mavedb and open_mavedb.
• Published scores, read as published (wave 3, slice 2). A design of model scores reads a
  table's scores, standard errors and 95% intervals as they were published, into a run (the model
  published) for the map, QC, the inspector and every export, never rescoring them. Variants the
  table gives no score, and rows repeating an earlier row's variant and scores (read once), are left
  out with their stages; classes, an exclusion list and a maximum SE can be set. Draft the design
  reads any table with a column of scores this way; the Experiment view names its columns of scores,
  SEs and intervals. QC judges what scores alone show (the controls' separation, the scores'
  resolution, coverage of substitutions with a score), and says the findings about counts are not
  assessed. What the analysis can do, for published scores: the map, exploration and comparison
  ready; rescoring and QC of the counts needing the counts, and where they may be found (MaveDB,
  when it keeps them; else the paper's supplement, the authors' repository, or the raw reads the
  record names).
• An example opened from MaveDB: PTEN's VAMP-seq abundance (urn:mavedb:00000013-a-1), scores
  alone, downloaded when opened and checked against its checksum, with its record and six
  calibrations. Ten examples now.
• Full MAVE-HGVS, and what a nucleotide variant does to the protein (wave 3, slice 3). Every
  form of MAVE-HGVS is read, intronic and UTR positions and names prefixed by their target
  included. Each nucleotide variant of a DNA target is applied to its sequence and both coding
  sequences translated: its class is what it does (synonymous, missense, nonsense, start or stop
  lost, an in-frame deletion, insertion, duplication or deletion-insertion, a frameshift, a
  multi-variant; a splice site, intronic, a UTR) and its protein change is named in MAVE-HGVS, as
  biocommons hgvs names it. A nucleotide library's synonymous and nonsense variants are found by
  translation; its scores export carries each variant's protein change.
• Nucleotide runs on the map (wave 3, slice 3). A run of nucleotide variants is drawn at the
  protein level: the variants that make the same protein change are one cell, merged as DiMSum
  merges them (each score weighted by 1/SE²; a variant changing one amino acid and leaving another
  codon synonymous left out). The inspector lists a cell's nucleotide variants, each scored, and a
  nucleotide variant's protein change. A new export, Scores at the protein level, writes them
  (protein_scores.csv from mavescape run too).
• Not on the map (wave 3, slice 3). Beside every map, the variants a map of substitutions
  cannot show (frameshifts, insertions and deletions, multi-variants, splice-site, intronic and UTR
  variants), each with its class, protein change and score, in order along the target and by class.
• Targets from GenBank (wave 3, slice 3). A plasmid or construct map (.gb, .gbk, .gbff,
  .genbank, .ape; SnapGene, Benchling, ApE and Geneious export it) or a RefSeq record makes a
  target: the coding feature is chosen when there are several, and its translation checked against
  the record's. A plasmid's target is its coding sequence on its strand (joined across introns); an
  mRNA's the whole record, numbered from its coding start, its UTRs on it. Where the target came
  from is kept with the workspace, shown in the Experiment view and the inspector, and named in the
  methods.
• MaveDB score sets whose target is a transcript (wave 3, slice 3). A RefSeq transcript is
  fetched from NCBI as GenBank, an Ensembl one from Ensembl (its current version, said where the
  record names another, every variant's reference base checked against it); a transcript named
  beside its protein is one target. A score set of several targets opens one, chosen, at a time,
  the others' variants set aside. A genome named as the target is not fetched, and says so.
• MaveDB's mapped variants (wave 3, slice 3). Keep MaveDB's mapping to the human reference
  fetches a record's mapped variants and keeps them beside its tables (in the archive too): the
  inspector shows each variant's HGVS on the reference, its GA4GH VRS identifier and its ClinGen
  allele; the methods cite them. open_mavedb takes target and mapped; inspect_variant
  gives protein, nucleotideVariants and mapped.
• An example of nucleotide variants: BRCA1's saturation genome editing (urn:mavedb:00000097-0-2;
  Findlay et al. 2018), opened from MaveDB with its counts, its target the RefSeq transcript fetched
  from NCBI: the map at the protein level, the splice-site variants beside it, and the deposited
  counts scored against the published scores. Eleven examples now.
• A run as a MaveDB deposit (wave 3, slice 4). Deposit in MaveDB…, in a run's Export menu,
  writes the run as MaveDB takes a score set: scores.csv and counts.csv as MaveDB's upload
  reads them (every variant in strict MAVE-HGVS on the target; a run's score, SE, 95% interval,
  replicates and status, its counts by sample; published scores passed through), what each column
  is (score_columns.json, count_columns.json), and the experiment and score set as MaveDB's API
  takes them (experiment.json, score_set.json): MaveScape's methods as the analysis, the
  design's readout and library method as the experiment's keywords in MaveDB's vocabulary (the MAVE
  ...

MaveScape 0.2.0

Wave 2 of the roadmap: every common experiment design, each checked
against an independent reference (time series, sorted bins, barcodes, DiMSum's error model, two
conditions), headless runs and remote control; then what the scores mean: what the assay measures,
findings in context, intervals that hold the truth, what each analysis can do with what is there,
and nine examples. A workspace saved by 0.1.0 opens and reproduces its runs; one saved by 0.2.0 is
kept for later versions to do the same.

Added

• Remote control (wave 2, slice 1). mavescape --remote-control lets programs on this computer
  drive the open window through /api/remote/action: get_state, new_workspace,
  open_example, open_files, set_mode, focus, draft_design, set_design, score,
  qc_findings, select_variants, inspect_variant, render_map and export (scores, counts,
  QC, provenance, methods, references, the map, a selection or the workspace archive). Each action
  happens in the window, its changes go into the history and can be undone; names are forgiving, and a wrong
  one is answered with the choices. GET /api/remote/tools lists the actions with their arguments.
  MaveScape writes its address and a token to remote.json in its data folder (readable by its
  owner only, removed on exit); reading and writing files needs the token. Only programs on this
  computer, never other web pages, can send actions. The hub, the connection file and the export
  writer are ported from CytoWeave 0.8.0.
• Screenshots captured through remote control. docs/capture/capture.mjs builds MaveScape,
  runs each scene on an empty library in headless Chrome by remote actions, and writes it in the
  light and dark themes to docs/images/ (optionally auditing each with axe-core). Ten scenes: the
  start page, import, the design and its draft, scoring, QC, the map, a saved selection, the map by
  standard error, and the exports.
• The website (docs/site/, published on GitHub Pages from the gh-pages branch): home,
  install, science (the validation, with its numbers) and a guide of eleven pages (getting started,
  the examples, opening your data, the design, scoring, QC, the map and the inspector, the record,
  scripting, troubleshooting), with the screenshots in both themes. The build checks every link,
  anchor and screenshot. The README shows the map's screenshot.
• The import wizard accepts what it detected when asked (remote control's open_files), and
  leaves the wizard open for review otherwise.
• Time series scored by regression (wave 2, slice 2). A time series of three or more time
  points is scored by default from every time point: each variant's score is the slope of its
  normalized log count on time scaled to 0–1, by weighted least squares as Enrich2 computes it
  (ordinary least squares and the log ratio of the first and last samples are the other choices),
  on unevenly spaced times. A variant is fitted on the time points where it was counted, at least
  three with the first among them; fewer than the replicate has are flagged low confidence. The
  slope's SE is scaled by the residuals and, by default, never below what counting alone predicts;
  the Enrich2-compatible preset keeps Enrich2's. Equal to Enrich2 2.0.2's WLS and OLS to
  5 × 10⁻¹³ on BRCA1's two assays and a new time-series fixture, and to statsmodels to 5 × 10⁻¹⁴.
• Time-series quality control: "Time points used" and "Fit of the time courses" (how far the
  time courses scatter about their lines against counting noise), with plots; the variant inspector
  draws each replicate's time course and its fitted line.
• "Missing = 0" per sample in the Experiment view (missingMeansZero in the design), for tables
  that write variants that dropped out during selection as missing; scoring and QC read the counts
  the same way, and the run records it.
• A third example: a simulated time series with known effects (five times over eight
  generations), and time series in the simulator, with an optional bottleneck at every passage.
• Sorted bins (FACS) scored (wave 2, slice 3) by the weighted average of the bins' values
  (VAMP-seq), with an analytic or seeded-bootstrap SE, or by the censored log-normal
  maximum-likelihood fit from the bins' gates (Peterman and Levine 2016), reads reweighted by the
  cells sorted into each bin. Each replicate is scaled so that nonsense scores 0 and the wild type 1
  (VAMP-seq), or the median of its lowest 5% 0 (MultiSTEP). A VAMP-seq preset and the mean of
  replicates (SE = SD/√k). Factor IX's published scores are reproduced from its counts to
  10⁻¹⁵, and the maximum-likelihood fits equal fitdistrplus's to 3 × 10⁻⁷.
• The design records each bin's gates and the cells sorted into it, edited in the Experiment
  view.
• Sorted-bin quality control: "Occupancy of the bins" and "Cells sorted per variant", and
  replicate agreement, variance beyond counting and outlier replicates from the bins' weighted
  averages, replicates compared within their tile. The inspector shows a variant's distribution
  over the bins beside the wild type's.
• A fourth example: a simulated sort-seq experiment with gates, cells and known shifts.
• Tables of barcodes (wave 2, slice 4). A count table whose rows are barcodes, opened with the
  barcode-to-variant map that names each barcode's variant: MAVE-HGVS or lab names, dms_variants'
  substitutions, or whole variant sequences (Enrich2's map) named against the target. A barcode the
  map gives two different variants is left unmapped and listed, never resolved by guessing. The
  design names the column of barcodes (library.barcodeColumn); the source keeps the counts, the
  map and how they were put together, and assembles them again whenever it is read.
• Barcodes scored two ways: summed per variant, then scored (Enrich2; dms_variants by
  substitution), or each barcode scored against its replicate's normalizers (dms_variants by
  barcode) and a variant's barcodes combined within the replicate by REML, fixed effects or their
  mean. Every barcode is compared with its variant's others (its departure over √φ, φ being how much
  more a replicate's barcodes disagree than counting explains), and outliers are found one at a
  time. Two filters: a minimum of barcodes per variant, and the barcode filter, which leaves
  outliers out. Equal to dms_variants 1.6.0's func_scores by barcode and by substitution to
  5 × 10⁻¹³. The inspector lists a variant's barcodes in each replicate; a run's barcodes export
  one by one (CSV).
• Barcode quality control: "Barcodes the map names", "Barcodes per variant", "Agreement of a
  variant's barcodes" (φ and the split-half r) and "Outlier barcodes", with plots.
• More layouts recognized at import (D12): dms_variants' variant_counts (made one row per
  library and barcode, a count column per library and sample) and Enrich2's counts files (one per
  sample, its elements named in MAVE-HGVS, or barcodes with its map).
• A fifth example: a simulated barcoded library with a map in conflict and outlier barcodes.
• A million rows (D9, S12). validation/bench.mjs imports a million-barcode table and its
  million-line map in 3.5 s (budget 15 s, the process at most 830 MB of a 1 GB budget) and scores
  it in 1.3 s; validation/browser-bench.mjs does the same in the window in headless Chrome (3–4 s,
  the browser's memory up by about 600 MB at most). Both run in CI.
• DiMSum's fitness and error model (wave 2, slice 5; S9). For an input and an output,
  Scored by offers DiMSum's model (Faure et al. 2020), as DiMSum 1.4 computes it: fitness with
  no pseudocount (an optional dropout pseudocount for outputs of 0), each replicate scaled and
  shifted to agree with the others, and an error model with a multiplicative term for each input
  and output and an additive term per replicate, carried into every variant's SE; replicates are
  merged by inverse variance. The error model is linear in its terms, so MaveScape fits it exactly
  on every variant (bounded least squares) where DiMSum averages 100 nonlinear fits of bootstrap
  samples, and reports the 10th–90th percentiles of a seeded bootstrap. A DiMSum-compatible
  preset; the run lists each replicate's scale, shift and terms, and its methods give them.
  Against DiMSum 1.4's own functions on GRB2, DiMSum's demo and a fixture: the same threshold and
  variants fitted, the scales and shifts within 5 × 10⁻⁷, the error model within 5 × 10⁻⁶ of
  DiMSum's own fit on every variant and inside its percentiles, and every fitness, σ and merged
  score within 10⁻¹² given DiMSum's parameters. On simulated bottlenecks, its 95% intervals hold
  the true effects 93–96% of the time (counting alone, 67–69%).
• Where the bottleneck is (Q4). "Variance beyond counting" fits DiMSum's error model to the
  counts and says whether the excess is before selection or after it, with a plot of the terms.
  The GRB2 example now shows its bottleneck at the inputs (20–38× counting) and scores with the
  DiMSum-compatible preset in its guide.
• Remote control's score takes the dimsum preset and returns each replicate's fitted model.
• Two conditions compared (wave 2, slice 6; S10). With two or more conditions, each condition
  is compared with the reference: every variant measured in both gets a differential score with its
  SE, 95% interval, p and Benjamini–Hochberg q. Three methods, under Conditions compared by:
  limma's moderated t on voom log counts with a term for each input library and for selection in
  each condition, as mutscan's calculateRelativeFC computes it (the default where it applies:
  two populations, relative to the wild type or the synonymous vari...

MaveScape 0.1.0

MaveScape's first release, wave 1 of the roadmap: from a
two-population count table to QC, scores checked against Enrich2, an interactive variant-effect
map and a saved, reproducible record.

Added

• The program and its window (wave 1, slice 1). One self-contained program (mavescape) for
  macOS, Linux and Windows, x64 and ARM64, that serves its embedded web app on 127.0.0.1 (port
  8820, or the next free one) and opens it in a desktop window. A second launch hands its files to
  the open window. The host, its security (Host-header check against DNS rebinding, same-origin
  API, Content-Security-Policy, cross-origin isolation) and its content-addressed workspace
  library are adapted from CytoWeave 0.8.0; the web app also runs from any static web server, with
  the library in the browser.

• The workbench shell. Views in the order of an analysis (Start, Experiment, QC, Score, Map;
  each says what it will do until it is built), a dataset tree, an inspector, a bottom drawer with
  the history of the analysis and the session's log, a status bar, the command palette (⌘K), undo
  and redo, light and dark themes and color-vision-friendly colors.

• The build commit in the status bar and /api/info: release builds embed it, other builds
  take Go's version-control stamp.

• Installers (install.sh, install.ps1) that check the download's SHA-256 and version, and a
  release workflow that builds six binaries with their checksums.

• The experiment design (wave 1, slice 2). A versioned schema (mavescape-design v1,
  docs/schemas/design.v1.json) and web/lib/design.js, which checks a design against its table
  and describes it in plain language. One schema represents two-population, time-series, FACS-bin
  and score-only experiments, samples shared between replicates, tiled libraries (overlapping too),
  several experiments in one table and known differences between a construct and its reference.
  Every column of a table is a sample's or set aside with a reason: none is dropped silently.

• Import (wave 1, slice 3). Open count or score tables (CSV or TSV, gzip too; per-sample
  files together) and the target's FASTA. The import wizard says what it found (layout, rows,
  delimiter, line ends, encoding), lets you choose the variant names and the count columns,
  suggests each column's role from its name (input, output, time, bin, tile, replicate; shown,
  never applied), checks every variant name against the target and lists, by line, every problem
  that blocks scoring: the same variant on two rows (however written), counts that are not numbers
  or are negative, rows of the wrong width. Missing counts are never read as 0. Tables are kept in
  the library by SHA-256; a mapping can be saved as a template. MaveDB's tables, DiMSum's (whose
  variants are whole sequences, named against the wild type) and generic tables are recognized.

• MAVE-HGVS (web/lib/hgvs.js): the whole grammar, agreeing with mavehgvs 0.8.1 on every one of
  16,959 test strings, and a lenient mode for lab and legacy names (A12V, _wt, p.Ala12*,
  repeated or unsorted components), which keeps the original beside the canonical name.

• The Experiment view (wave 1, slice 4). Say what each column of the counts is: a sample, a
  technical replicate of one (summed), a copy of a shared sample's column, or not used (and why);
  and each replicate's samples: input and output, each time, or each bin, with conditions, tiles,
  controls and the target's offset and identifiers. A design starts from MaveScape's draft from the
  column names, or from a sample sheet (one row per sample: column, role, replicate, condition,
  time or bin, tile, batch; DiMSum's experiment design file works as one), and is checked and
  described in plain language as you edit. Designs export and open as *.design.json.

• A history that cannot be rewritten quietly. Every material change (an import, a target, the
  design) is written to the workspace's history, each entry chained to the one before by SHA-256;
  the drawer lists it and says whether the chain holds.

• Scoring (wave 1, slice 5). The Score view turns the counts and the design into functional
  scores with standard errors: log ratios normalized to the wild type, complete cases, all reads
  or the synonymous median, with a pseudocount; technical replicates summed, biological
  replicates scored separately and combined by REML random effects, fixed effects or Enrich2's own
  estimator (an "Enrich2-compatible" preset reproduces Enrich2 2.0.2's numbers); heterogeneity
  (Q, I², τ²) and leave-one-replicate-out sensitivity for every variant; optional rescaling
  (nonsense 0 and wild type 1; synonymous 0 and nonsense −1). Filters are ordered and visible (a
  filter bar and the filter flow), and a filtered variant keeps its counts and replicate scores
  with the stage that left it out; nothing unscored is shown as 0. Conditions are scored apart.
  Scoring runs in a worker, with progress and cancel.

• Runs that can be repeated. Each run is kept unchanged with its table's SHA-256, the design,
  the parameters, the software version and the hash of its output; the same inputs always make
  the same run. Reopened, a run is recomputed and checked against its output hash. The run says in
  sentences how its scores were made.

• Drafts that keep experiments apart. A table holding two assays (BRCA1's E2 binding and
  yeast two-hybrid) drafts into two conditions instead of one experiment.

• Quality control (wave 1, slice 6). The QC view says whether the experiment supports
  reliable scores, finding by finding: every sample has counts (blocking when not), sequencing
  depth, low counts before selection, missing counts, variants missing after selection (a table
  that writes dropouts as missing), coverage of the designed substitutions (a grid by position),
  replicate agreement, variance beyond counting (a bottleneck), outlier replicates, and from a
  score run the separation of the controls, the resolution of the scores and the variants
  scored. Each says pass, review, fail or not assessed (and why), with what it found in numbers,
  its threshold and rationale, what it concerns and its plot; the overall status is shown beside
  the list. QC runs from the counts alone, before scoring, or of any score run. Thresholds can be
  changed, and each change goes into the history.

• Simulated experiments (web/lib/simulate.js): a library, bottlenecks, selection with
  replicate noise and sequencing, seeded and labeled simulated.

• The variant-effect map (wave 1, slice 7). Positions across, the 20 amino acids and stop
  down, colored by score (blue for loss, red for gain, or purple and orange; white is the wild
  type), or by SE, replicates used or input count. Missing, filtered, low-confidence and
  not-designed cells are each drawn their own way, never in the wild type's color; reference
  residues are outlined and hold the synonymous variant. The median of each position is shown
  above and of each substitution at the right, with target and reference numbering and an
  overview of the whole target. Pan, zoom, hover; click, ⌘-click and Shift-drag to select; the
  keyboard moves through the cells and announces each. Selections can be saved by name. The map
  exports as SVG and PNG, is described in words, and lists every cell in a table.

• The variant inspector. A variant chosen on the map, in its table or in the Score view shows
  its identifiers as written and canonical, its score with SE and 95% interval (or why it has
  none), its flags, each replicate's counts and score, every sample's counts, the other
  substitutions at its position, the sequence around it and the run it comes from.

• The workspace archive (.msz, wave 1, slice 8). One file with everything needed to reopen
  an analysis on another computer: the workspace (targets, design, score runs, selections, QC
  thresholds, the chained history), each run's scores, the methods with references, and the
  tables (or only their checksums). Saved, reopened and saved again it has the same bytes; opened,
  every file is checked against the manifest's SHA-256 and the history's chain, and anything that
  does not hold is reported. Workspace menu → Export.

• Exports. From a run's Export menu: scores and the counts it scored, in MaveDB's columns (they
  import again without loss, and MaveDB's upload layout is now recognized at import); QC per
  sample and per variant; the run's provenance as JSON; the methods paragraph, written from what
  the run did, with numbered references and their BibTeX. From the map: the selected variants as
  CSV or JSON.

• Examples. Two on the Start page, each opened as a new workspace with a first score run and a
  guide in the inspector (its question, steps, what to expect, source and license): the GRB2
  SH3 domain (the Human Domainome's CC0 counts from MaveDB) and a simulated experiment whose
  true effects are known (and compared with its scores). Simulated data are labeled as such.

• Blank layouts and docs/FORMATS.md. Annotated count table, sample sheet and target FASTA to
  fill in, from the Start page; every file MaveScape reads and writes, described.

• The workflow strip. Above every view, the analysis as steps (counts, target, design, score,
  QC, map, record), each done, next, needing attention or still to do, and the next step said in
  words with its button: "Draft the design" drafts it in one click. It says what is wrong when a
  step is blocked: a table of scores rather than counts, problems that block scoring, a design to
  fix, a design changed since the last run, a FASTA opened without its count table.

• Starting MaveScape while one is a...