Zenith 0.1.2

Changed

• GitHub mode signs in with GitHub.
• In the web app, Remember the sign-in can now keep you signed in to GitHub in this browser until you sign out, so reopening Zenith does not ask again.
• Accounts, teams and sharing are on in public releases.
• The web app has its own address.
• zenith exits 2 for an unknown option, a bad flag value or a missing argument, as the exit-code table says.
• In the desktop app, the GitHub sign-in box reads "Remember on this computer".
• The shortcut sheet has a Close button with a tooltip, and no longer leaves blank space under its lists.
• Dialogs open near the top of the window, so one that grows (Open another project) no longer moves its title.
• Dialog titles use the same weight as the sheets' titles.
• The status line's close is an X with a tooltip, like every other close.
• The time stamps in the Library and Teams sheets show their full date in the standard tooltip.
• The invite expiry notice has one close when it lists one line, and names the invite by its role.
• An admin invite always waits for an owner or admin to approve whoever opens it: Approve automatically is off for the admin role, and the cloud refuses it, so a leaked admin link alone never lets anyone in.
• The import and expiry notices stand beside the desktop panel instead of over it.
• Team safety codes and device verification codes are 20 digits in five groups of four, from a slow hash, so a server can no longer make a key of its own that shows a real team's code.
• After a member leaves or a device is taken off, nothing new is published, shared or proposed until an owner or admin makes a new team key, and the status line says so.
• The database rules keep an admin from deleting every device's team key or replacing the recovery record's key without a key change.
• A share manifest that does not name its projection, from before 2026-10-11, is refused.

Upgrading from 0.1.1

• The documentation site counts page views
• Full sim with SimLoop
• The Inspector is one calm panel
• The field's tile seams show the tiles' interlocking tabs
• Inspector rows, the Waypoints list and the command palette read more plainly
• Update the robot runtime with the editor.
• Copy the new BIOBUZZ field file.
• Path speeds now come from robot.json on the robot.
• zenith sim --json

Added

• A new auto made from DSIM starts where DSIM's robot starts
• Export an auto as an OpMode you own, not recommended
• ZenithRobot can run your code around the routine
• deploy.opModeBase lets generated OpModes extend your own class
• Share presets with your whole team through the project
• A command that drives the robot by itself drifts to its rejoin pose, as a ghost, and an envelope can preview a shorter run
• Full sim speed: Basic, Fast and Ultrafast.
• The robot runtime's trace writer records contacts, the ledger and events.
• Optimize path offers the turn onto the path, and takes heading holds
• New paths start at the previous path's end heading, and a new auto's first path uses your default heading
• Settings has a search
• Settings, the first run and the dialogs say one clear thing each
• Crossing the centre line in auto is an error
• Optimize path is easy to find, and Optimize every path
• Add a clear path to here, and the Optimize card's alternatives
• Route around and Find a faster heading
• The Optimize card
• The Optimize path worker and its host
• The Optimize path switch, its settings and the candidate colour
• Optimize path's structural moves

Editor

• Optimize path.
• Add a clear path to here.
• Turn on the spot.
• Path chains grow, shrink and join.
• Waypoints in the editor.
• Waypoint pins on the field.
• The Waypoints list.
• A Settings window.
• Robot and Commands settings.
• Feature switches and presets.
• Your own keys.
• Heading for new paths.
• A Code tab beside Problems.
• Set up Zenith in a robot repository.
• New auto in the web editor.
• Save the example as a full project or just the auto.
• Play from here, and the running steps light up.
• The BIOBUZZ field is drawn by the editor.
• Pollen and nectar counts on the field.
• Clip ghosts.
• Download a picture of the auto.
• Undo and Redo in the toolbar, and tooltips on touch.
• Mouse back and forward buttons
• Row hints and descriptions.
• Set a value's provenance by hand.
• The start pose can be dragged and turned on the field
• Move the start to the nearest legal spot.
• Report a bug.
• A resizable Ledger panel
• Beta notice.

Seasons, checks and the sim

• Crossing the centre line in auto is an error.
• A per-robot clearance and the CLEARANCE warning.
• A slanted bar obstacle, strut, in field format version 3.
• New findings.
• More one-click fixes.
• Transfer steps.
• Nectar in the ledger, and a ledger for the whole field.
• Conditions the preview reads from the ledger.
• Full sim speed: Basic, Fast and Ultrafast.
• Envelopes.

Partners

• Partner files.
• Alliance view.
• Proposed changes.
• Imports.
• Host mode
• Live run

CLI, MCP and GitHub

• zenith optimize <auto> --step <id>
• Heading holds for Optimize path.
• zenith import-commands
• Connect a robot repository to GitHub in one step.
• Sign in with the GitHub CLI, and zenith open.
• @horizon36596/zenith-core additions.

Robot runtime

• The trace writer records contacts, the ledger and events.
• Path speeds are checked at init.

Documentation

• Full sim with SimLoop.
• Guides for when accounts launch:

Changed

• The Ledger draws the pieces instead of listing them.
• The desktop app's sim, deploy and git panel works like the rest of the app.
• The desktop menus use the palette's words.
• Opening a robot repository says the same thing every way you open it
• The desktop app says when a newer version is out.
• Shorter share screens.
• One look for empty, loading and offline.
• The first run and the tour leave the example as they found it.
• The start screen shows only what is there.
• One name for each thing.
• What's this from the Help menu is a mode.
• Report a bug works with accounts off.
• The palette and the toolbar say why.
• Settings opens each section at its top, and searches best match first.
• A preset file that will not import says which file and why
• Bad files say what is wrong and what to do.
• Cloud failures read the same everywhere.
• Optimize results say at a glance whether a run helped.
• Optimize every path counts a failed path apart.
• Add a clear path here refuses a blocked spot at once
• The Code tab with errors says "No code while the auto has 4 errors."
• A loaded trace names the run one way.
• The instant sim says why its total differs
• The Full level's tooltip on the web says to run the sim command in your robot repository.
• Delay my start now says what it left and how to take it back
• Loading a partner's share file that is already loaded replaces it
• The Partners panel with no partner loaded shows "No partners loaded"
• With the Ledger switch off, a shot from a spot the rules do not allow, or one the turret cannot aim, is listed in Problems, drawn on the field and counted.
• A path that runs into several parts of one structure offers Route around once
• Route around is no longer offered for crossing the centre line
• Step edits say what they did.
• A new path or group starts with no error.
• Shift-click selects a run of steps.
• Step ids follow the waypoint name rule.
• A turn on the spot reads as a turn.
• One name for each action.
• The marker menu can change the command.
• Menus look the same everywhere.
• No focus ring after a click.
• Partner findings look like Problems rows.
• Smaller wording fixes.
• The Code tab says that the robot does not run the class it shows
• A SolversLib auto that fails at init now ends and resets the scheduler
• The Inspector is one calm panel.
• Angles read plainly.
• The steps list, the timeline and the status line.
• The toolbar, tools and field menus.
• The Problems panel and the Code tab.
• Settings, the first run and the dialogs say one thing each.
• One Grid setting: Off, Tiles, 12 in or 6 in.
• A linear heading on a curve turns where the robot turns it.
• No pause between two path steps in the preview.
• The estimate counts the turns at path joints
• New path steps are named path1, path2
• The starter example plays BIOBUZZ the way a team would.
• The BIOBUZZ hive and human player follow the manual.
• The aqua target reticle is gone from the flowers
• The field pans with the middle mouse button
• One logo everywhere.
• Envelopes are rectangles.
• The desktop window has no gradient border
• One name for a partner's file: share file.
• An auto in an older format says so when it opens

Fixed

• Exported JSON Schemas use valid numeric bounds.
• Host mode says when it is saving, keeps the robot findable on a narrow window, and says a closed session once.
• The editor works in a narrow window.
• An offline send no longer says it was sent.
• A refused publish always says why.
• Reading the library or the team always ends.
• A Horizon admin's team delete removes its members.
• Every action answers on the status line, and old answers go away.
• "Example loaded, read only."
• Number fields say their range.
• Step names.
• Set up and Auto details fields.
• Set up a folder that already has autos.
• **A folder that did not...

Zenith 0.1.1

Fixed

• CLI on Linux and macOS. The zenith command installed from npm exited without doing anything,
  because npm links a bin there as a symlink and the CLI did not recognise itself through it. It now
  resolves the link. Windows was not affected. CI now packs and installs the npm packages and runs
  their commands on Linux on every change, which is where this showed.
• npm. 0.1.0 was not published to npm, because this fault stopped its publish run. 0.1.1 is the
  first version of the @horizon36596/zenith-* packages there.
• A timeoutS on a group step. The robot runtime used to honour a timeoutS on a sequence,
  parallel or branch, which the file format does not give those kinds and the editor drops, so a
  hand-written file ran differently on the robot from the way the editor planned it. Both runtimes now
  ignore it and show a Zenith warning line in init telemetry naming the step (AutoFile.warnings).
  Put the timeout on a step inside the group, or bound the group with a deadline whose deadline is a
  wait.
• Waypoints in a mirrored routine. mirrorAuto kept a waypoint reference as it was, so a mirrored
  file drove to the waypoint itself where the robot, running the original as the other alliance, drives
  to its mirror. Given the project's waypoints, mirrorAuto now writes a referenced pose as the
  mirrored waypoint's numbers. A caller that saves the result has to pass them.
• BLUE files in the editor. A file's alliance is the alliance its poses are written for, and
  the robot runtime mirrors a file only when it runs as the other alliance. The editor, zenith render
  and the MCP render mirrored whenever the view was BLUE, so a BLUE file opened on RED's half, the
  opposite of where the robot drives it, and a point drawn on a BLUE file was stored mirrored. They now
  follow the runtime: a file is drawn as it is when viewed as its own alliance, and mirrored only when
  viewed as the other, with every edit made there mirrored back. The start rules read a BLUE file's
  start against BLUE's own half and BLUE's loading zone, and zenith new --alliance BLUE writes its
  skeleton on BLUE's half. The file format is unchanged.

Zenith 0.1.0

The first public release.

Added

• Editor, web. The Zenith editor as a static web app at
  https://libraries.horizon36596.org/zenith/app/, public, with no sign-in needed to use it. Draw
  paths with headings, attach commands, and see timing and findings update as you drag. Local mode
  opens a robot repository folder and saves in place in Chrome and Edge.
• Editor, desktop. A Windows installer and a portable exe on GitHub Releases, built from the same
  UI. Adds native folder open, file watching, the high-fidelity sim button with an automatic overlay,
  deploy, and commit, push and open a pull request. Not code-signed yet, so SmartScreen warns on first
  run.
• Playback levels. Three levels, chosen under the timeline's scrubber: Ideal (the
  default) follows the planned path exactly on the estimate's clock and turns or drives across any
  gap between steps; Instant sim is the preview sim; Full sim plays a loaded
  high-fidelity sim trace. The robot, the timeline and the readouts say which level they show.
  idealTrajectory and idealPoseAt in @horizon36596/zenith-core compute the ideal level.
• Headings by Pedro's names. The editor names each heading mode the way Pedro Pathing does:
  Tangent, Reverse tangent, Constant, Linear, Facing point and Piecewise, with the plain meaning and
  the Pedro call in each mode's tooltip. The values in the file did not change.
• Heading arrows. The selected path shows its heading as arrows on the field, which you drag to
  turn it: a Constant's two arrows turn together, a Linear's start and end turn apart. They snap to
  15° steps like points do.
• Piecewise headings. A piecewise heading mode gives each stretch of a path its own mode, as
  ranges of t from 0 to 1. Split a range on the inspector's track or with Split heading here on
  the path's right-click menu, and drag a boundary's tick along the path. The runtime follows it with
  Pedro's piecewise interpolator. It moves the auto formatVersion to 3; version 1 and 2 files load
  and are migrated.
• Direct dot drags. Any path's dot can be dragged straight away, without selecting its step
  first; the drag selects the step, and one undo puts the dot back.
• Tour. A first-run tour of six stops, then an optional tour of every feature. It is
  non-modal: every control in the editor works while it runs, and its card keeps clear of what it
  points at and of any open menu, tooltip or dialog.
• One tooltip at a time. Opening a tooltip closes any other, and keyboard focus opens a
  tooltip only when it came from the keyboard, not from a click.
• Step kinds. Path, command, wait (for seconds or until a condition), sequence, parallel (all,
  race or deadline) and branch (if/else).
• Checks and findings. Continuity, perimeter, keep-out, heading, capacity, legal approach, start
  legality and timing checks, each with a plain-language explanation and, where one exists, a
  one-click fix.
• Instant sim. A deterministic follower sim in the core that re-runs on every edit and drives
  playback, the hover robot and the timeline.
• Provenance. Every number in robot.json and field.json carries a provenance label, shown and
  ranked in the editor.
• CLI. @horizon36596/zenith-cli, which installs the zenith command: init, new,
  validate, estimate, render, codegen, deploy, diff, sim, calibrate and
  propose --dry-run. Every verb takes --json and none of them prompts.
• MCP server. @horizon36596/zenith-mcp, which installs zenith-mcp: the same work as MCP tools,
  plus structural edit primitives so an agent never hand-edits JSON.
• Libraries on npm. @horizon36596/zenith-schema, @horizon36596/zenith-core,
  @horizon36596/zenith-seasons, @horizon36596/zenith-season-biobuzz and
  @horizon36596/zenith-github, published with provenance.
• Robot runtime, on Ivy or SolversLib. The Java runtime that plays an auto file on the robot
  through Pedro Pathing v3, on JitPack as com.github.Horizon-36596:zenith. It builds the file into
  a command tree on either of two command libraries, both first-class: Ivy, Pedro Pathing's own
  (com.pedropathing.ivy:pedro:1.1.1), with the classes in org.horizon36596.zenith.ivy, or
  SolversLib (org.solverslib:core:0.3.6), with the classes in org.horizon36596.zenith.solverslib.
  The classes a team uses have the same names in both packages, and what names no command library,
  such as Args and RobotClock, is shared in org.horizon36596.zenith. One artifact holds both, and
  a team declares only the library its robot code uses. A new auto needs no Java edit. On either
  library, if a command left running from init blocks the routine at start, the OpMode fails and
  names what blocked it rather than doing nothing. See
  the robot runtime page and "Choosing a command library" on the docs site.
• deploy.commandLibrary in zenith.json. "ivy" or "solverslib", the library the robot code
  uses. Zenith picks neither, and writes no Java until it is set: zenith codegen refuses without it,
  and so do zenith deploy and the desktop app's Deploy when zenith.json has a codegen section,
  because only then do they write OpMode stubs. zenith deploy writes stubs for the named runtime and
  names it on the first line of its output, the desktop app's deploy preview names it, and
  zenith codegen writes that runtime's form of the readable class. zenith init --command-library ivy
  or --command-library solverslib writes it into a new project; without the option, init leaves it
  out and says so.
• Alliance mirroring, headings included. A file run as the other alliance is mirrored through the
  team's ZenithRobot.mirror, poses and headings together, decided in one place
  (AutoFile.mirrorsInto). A constant heading and the start of a linear sweep go through the
  mirror, a facePoint point goes through it, a sweep keeps its size and turns the other way under a
  reflection, and every piecewise range is treated the same way. The runtime reads how headings move
  and whether turns reverse from the team's mirror, so a point symmetry and a reflection both work, and
  a mirror whose headings disagree with its positions fails at init. The editor's mirror to the other
  alliance keeps a linear sweep's size and direction the same way, and the robot tests check that a
  file run as the other alliance drives what the editor's mirror of it drives, on both runtimes, under
  a point symmetry and a reflection.
• Conformance suite. Every starter auto, and a fixture for every end rule, timeout, parallel mode,
  branch arm, marker kind, piecewise headings and three-deep nesting, runs through both runtimes in the robot
  tests, as its own alliance and mirrored, which fail unless every step, command and path starts and
  ends on the same loop on both.
• Generated Java examples. The starter's cycle-and-park auto (markers, timeouts, an end
  condition, a race, a deadline group with a sequence in it, and a branch) has what zenith codegen
  and zenith deploy write for it with each command library checked in under
  examples/starter/generated/, and a test fails if those files go stale.
• GitHub mode. Sign in with a fine-grained personal access token, edit on a work branch
  (auto/<autoName>/<login>), and propose a pull request whose body carries a rendered SVG, an
  estimate table and the end-of-routine ledger. Review mode draws the base and head of a pull request
  together from a #/review/<owner>/<repo>/<number> link.
• BIOBUZZ season plugin. The field file and rules for BIOBUZZ presented by RTX (FTC 2026-27):
  hives, tip table, flowers, garden and pollen, the legal-approach rule and the start rules.
• Starter example. A generic mecanum robot with one front intake, round PLACEHOLDER numbers, the
  BIOBUZZ field, waypoints and teaching routines that cover every step kind.
• JSON Schemas. Published at https://libraries.horizon36596.org/zenith/schema/v1/<kind>.json.
• One version. Every package, the desktop app and the Java runtime carry the version set in the
  root package.json; zenith --version and the MCP server report it.
• Documentation. The docs site at https://libraries.horizon36596.org/zenith/: getting started,
  the editor guide, a newcomer's guide to autonomous paths, the file-format reference, checks, sims,
  the robot runtime, choosing a command library, the CLI, agents and MCP, seasons, GitHub, and the FAQ.

Changed

• Schema ids. The $schema ids moved to
  https://libraries.horizon36596.org/zenith/schema/v1/<kind>.json, where the docs site serves the
  schemas. Files that still carry the development ids under zenith.horizon36596.org/schema/v1/ load,
  because the loader reads them as aliases, and are written back with the new id. The data format
  did not change, so no formatVersion moved.