Syncyard 0.4.0

Syncyard 0.4.0 — release notes

Status: published 2026-11-09 under P8 publication
exception P8-X1 (recorded in PROGRESS.md). The Linux legs
publish ahead of the full field matrix on the owner's
2026-11-09 directive, because the linux-aarch64 agent was
blocking the sbc-inference host. This is a publication
exception, not acceptance: the 11 field-gated named tests
and the rest of P8 acceptance remain open, and the release
gate's matrix step stays red for them.

Release assets: the eight Linux binaries are attached with
target-suffixed names (syncyard-daemon-linux-x86_64,
syncyard-daemon-linux-aarch64, and likewise for cli, agent
and tray), plus MANIFEST.json.

One train, one version: the gatekeeper package, the Rust
core, and the gh syncyard extension all ship as 0.4.0.

The train

Component	Artifact	SHA-256
Rust daemon, linux-x86_64	syncyard-daemon	ff489997a11c2f8821ff56715a6ab26ed54aa61e9feff092b3ebbe8ff6ac3640
Rust CLI, linux-x86_64	syncyard-cli	2095bf42be854c68849b8ee098e8b4c58483357f6674738e70b7fc6320fb6370
Rust agent, linux-x86_64	syncyard-agent	3bd1a3ea19e8558299b381325f997b0f0f4278cdfaf84e6e0608f46314e338eb
Rust tray, linux-x86_64	syncyard-tray	9331f6aa6341d917d9b980c616984534128678cbb9e2a65bd51b5ac2b589fe4a
Rust daemon, linux-aarch64	syncyard-daemon	46dae02413d8dc68f64962c5e26cc0c250bc09e0f5571f97b63a412fd1e28791
Rust CLI, linux-aarch64	syncyard-cli	599019323a4bd2b1b5bdc63615774c4b3c9698cbf0799513f170c8738bf820ec
Rust agent, linux-aarch64	syncyard-agent	c305abcbfb77bdd620ff9dd0d33890aaa61a1d705eac3504407e5a9264e09e23
Rust tray, linux-aarch64	syncyard-tray	aa9cc36e09291e67f7a9aea962e4a27fbdde95d02890b2b30e2354b9b0e0c40a
Extension (already released)	gh-syncyard v0.4.0	https://github.com/AXIOVEX/gh-syncyard/releases/tag/v0.4.0
Gatekeeper package (PyPI)	syncyard-0.4.0-py3-none-any.whl	9b25511676adb21b968b2f72ac92cbf0f31dcf55cefcfad1ea37933f319b8082
Gatekeeper package (PyPI)	syncyard-0.4.0.tar.gz	5e48b23656a9447920e25ca8da50f6bfcd0a4e1bfff7d4706262ecdd98a6c462

Full machine-readable manifest: MANIFEST.json, attached
to this release and mirrored in the repo at
rust/release/manifest-0.4.0.json.

What 0.4.0 is

The Rust core implementing specs 034–039 alongside the
Python gatekeeper it will replace at cutover:

• Daemon — RAM-authoritative queue state, 60 s
  write-behind flush with read-back verification, single
  writer with fencing, two-phase ledgered dispatch,
  write-wave freeze (never corrupt), boot reconciliation
  from an off-VM witness store, signed tray control with a
  kill switch, capability registry and placement, resource
  envelopes, the REP reporting pipeline, FIX repair
  machinery with budgets, UPD update discipline, and
  door-workflow commit-SHA pinning recorded per job.
• Agent — windowless payload execution with streaming
  progress, verdicts from payload exit codes
  only, job-start credential preflight, container run-spec
  posture (non-root, read-only rootfs, cap-drop ALL, no
  Docker socket), the macOS platform layer (capability
  probe, launchd service generation, sleep-honest state).
• Tray — the presentation rules as data:
  identity stamp on every surface, connection honesty,
  signed job control; macOS menu-bar and COSMIC/Wayland
  surface policies included.
• CLI + extension — the full verb surface routed per
  engine; gh syncyard parity proves the routing against
  the contract.

Platform status (honest)

• linux-x86_64: full build, full test suite green.
• linux-aarch64: full build (musl, statically linked),
  all four binaries.
• macOS (aarch64 + x86_64): cargo check green for the
  whole workspace. No runnable darwin binary in this
  candidate — linking requires the macOS SDK, which the
  Linux build VM does not have. The first darwin binary
  comes from the CI macos-latest leg or a Mac build host.
• Windows (x86_64-pc-windows-gnu): cargo check green.
  The daemon/agent socket transport is Unix-only in this
  build and refuses by name elsewhere; the Windows
  named-pipe transport is named future work.

Gates at assembly time

• Test suite: 207 passed / 0 failed at closeout (see PROGRESS.md P7).
• Traceability: 147 of 158 named tests in suite; the 11
  remaining are the recorded field-gated list (live-host
  proofs), listed verbatim in PROGRESS.md.
• Coverage: all five crate bars MET at closeout
  (contract 95.50 / daemon 90.10 / cli 87.03 /
  agent 88.06 / tray 91.52), measured with the LLVM
  pipeline and verdicted by syncyard-tracegen coverage;
  full table in PROGRESS.md P7.
• PyPI upload is an owner act and has not happened; the
  extension release v0.4.0 is live (above).

Syncyard Tray 0.4.4.0

Tray liveness heartbeat (ratified hardening batch H1): the tray reports every 30 seconds, the gatekeeper judges agent-alive/tray-dead, and the packaged watchdog relaunches a dead tray with a persisted cap. Includes the status window, queue line, launch update check, and consoles viewer from 0.4.3.0.

Syncyard Tray 0.4.3.0

Tray 0.4.3.0: update check at launch (balloon announcement, install stays the owner's click), the four-state queue line in the menu, the Status window (per-lane queues, running and waiting jobs, machine and update state), and the read-only consoles viewer replacing the removed window-hunting Show item. Built on TRISTEN-DESKTOP from merged main fa01575 (PRs #73 and #74); exe sha256 9363f716fb980729f6e389a9a1af8521ccee2b0ccfd6373987c6c914985cf3c2.

Syncyard Tray 0.4.2.0

Menu lifetime fix (PR #71): the context menu strip is never replaced or disposed, so menu clicks no longer kill the tray with ObjectDisposedException, and Check for updates works again. Built on TRISTEN-DESKTOP from repo main b480d01 with source hashes verified in the build job; exe sha256 0c3b82cb231f3e1010078052b02cabc36ef9c8c42ba95e92b4f8bdcc9f78ac55.

Syncyard Tray v0.4.1

Tray 0.4.1.0: tooltip text composes short parts under the 63 character limit (parts dropped whole, never chopped), and the menu header is trimmed from five grayed status lines to three. Verified installed on TRISTEN-DESKTOP and TRISTEN-LAPTOP 2026-11-04. Exe 150,016 bytes, sha256 481895a2721025639643ac8640f9a7b3995052a39998d3d17d37913dd572a8d6.

Syncyard Tray 0.4.0.0

First self-updating tray build: Check for updates in the tray menu, SHA-256 verified swap with rollback, build stamp 0.4.0.0, exit forensics, per-machine runner root. Built on TRISTEN-DESKTOP from AXIOVEX/syncyard main 56b14a8 (source sha256 57a3f099c89797580fe850dba253ccd23b0842fc41ea793079b348c65eff6afb); installed and verified on TRISTEN-DESKTOP and TRISTEN-LAPTOP 2026-11-04.

Syncyard 0.3.0

Added

• Phase 5 docs (T017 + T018, 2026-10-31):
  SECURITY.md is now the shipped security posture — the
  invariant verbatim (the same sentence every skill
  edition carries), the posture in plain language (CI on
  GitHub-hosted runners only; self-hosted runners reachable
  solely behind the gatekeeper's workflow_dispatch; the
  gatekeeper's verified-write and exactly-once dispatch
  rules; the backchannel as dev/recovery only, carrying no
  job traffic), and adopter checklists for token scoping and
  runner isolation — alongside the existing reporting policy.
  README.md opens with the two-minute story requires (the problem, the scars that shaped the design,
  what Syncyard deliberately does not do), the security
  section links SECURITY.md above the quickstart, and
  per-host quickstarts cover Windows, WSL2 (via a Windows
  host), Linux, macOS, and Docker — including the fleet rule
  that cross-job payloads are never staged in a WSL venue's
  /tmp (it does not persist between jobs; stage in the WSL
  home directory or the job's working tree instead).
• — shutdown protection and recovery (owner
  direction, 2026-10-31): a host-side shutdown guard that
  delays a non-forced shutdown while active work drains
  (bounded checkpoint window, going-down record written
  first with the affected run ids, outbox notification),
  boot recovery that returns runners without an interactive
  logon (boot shape is an owner gate — service-mode would
  amend the runner rule), a generalized supervised-work
  vehicle from the production anchor pattern, gatekeeper
  reconciliation of every interrupted run against GitHub's
  terminal state, and a recovery report that states loss
  plainly. The spec's protection level is delay + drain +
  checkpoint + notify, never prevent — forced shutdowns and
  power loss are named outside the envelope. Specified only
  in this change; implementation follows in phases.
• Phase 4 — the agent skills pack:
  skills/ ships eight editions generated from one shared
  source (skills/_source/contract.md via
  skills/build_skills.py) in the Amendment 1 ranking —
  Meta Muse (primary), Claude Code, GitHub Copilot, OpenAI
  Codex/ChatGPT, Cursor, Google Gemini/Antigravity,
  generic-agent, and a CLI-only fallback. Each edition carries
  the security invariant verbatim; the T016 currency
  battery (skills/test_skills.py, in CI) pins every edition
  to the repo VERSION, the invariant, and the shared source
  (drift fails the build).
• — public release program (owner direction,
  2026-10-30): configurability as a single config file (lane
  count/names, watermarks, budgets, endpoints, transport
  ceiling), a tested host matrix (Windows, WSL2, macOS, Linux,
  Docker), permanent backchannel hardening (self-test, stale
  alarm, chaos battery), an agent skills pack with Meta Muse
  as the primary vehicle, per-requirement test batteries, a
  shipped security posture, and release 0.3.0 when green. A
  GitHub gh-adoption pitch brief is prepared under and is not sent without the owner's explicit word. Specified
  only in this change; implementation follows in phases.
• Amendment 1 (2026-10-30): ships Syncyard as
  a GitHub CLI extension (AXIOVEX/gh-syncyard, thin Go
  dispatcher, official precompile action); agent-skill
  editions ranked by market share (Meta Muse primary, Claude
  Code, Copilot, Codex/ChatGPT, Cursor, Gemini/Antigravity,
  generic). Phase 1 slice 1: config/syncyard.example.yaml +
  gatekeeper/config.py loader/validator with the
  test_config.py golden battery (25 checks, all passing);
  additive — the gatekeeper does not read config yet.
• Phase 7 SHIPPED 2026-10-31:
  AXIOVEX/gh-syncyard v0.1.0 — the GitHub CLI extension.
  Thin Go dispatcher over the installed gatekeeper
  (lookup: $SYNCYARD_GK / $SYNCYARD_HOME / ~/syncyard /
  ~/.syncyard / beside the binary / ./gatekeeper);
  precompiled binaries via the official precompile action;
  install proof: gh extension install AXIOVEX/gh-syncyard
  then gh syncyard status against the live fleet.
• Phase 1 slice 2 (T003/T004, 2026-10-31): the
  gatekeeper now reads its effective configuration at
  startup — lane set, runner labels, per-lane concurrency,
  watermark tables, budgets, and dispatch knobs all bind
  from syncyard.yaml deep-merged over the built-in
  defaults (the pre-config constants verbatim); invalid
  config fails closed with a named error.
  gatekeeper/test_golden.py proves byte-identical
  dispatch decisions under defaults vs the fleet config,
  and runs in CI.
• Phase 1 COMPLETE (T005, 2026-10-31): the fleet
  gatekeeper now runs on the configuration system — wired
  code deployed behind a queue snapshot (534 records,
  open-set 5) with exact reconciliation, and the fleet
  syncyard.yaml in place beside the gatekeeper.
• Phase 2 begins (T006, 2026-10-31): hosts declare
  the transport workflows they serve (execute/grab) and
  their identity markers (a per-type contract); the
  gatekeeper routes by host and refuses, at submit/adopt,
  any job addressed to a venue that does not serve its
  workflow — no silent fallback. Config validation covers
  the new shape; the golden battery pins the routing
  matrix across the fleet hosts plus a config-only macOS
  host.
• T007 (2026-10-31): the shipped transport
  workflows are generalized — a lane input addresses the
  runner, hardcoded label lists are gone, and each file
  states its host contract; execution bodies unchanged
  from the proven production shape. New contract battery
  in CI pins dispatch-only triggers and lane binding.
• Phase 2 COMPLETE (T008/T009, 2026-10-31):
  native Linux and macOS transports (one shared script
  body, drift-checked), a Docker transport (caller image,
  declared mounts, results land on the host for grab
  return), and gatekeeper --image/--mounts submit
  options with host-config image fallback — all pinned by
  golden argv checks and a hosted smoke battery
  (ubuntu + macOS + a docker-required job).
• Phase 3 COMPLETE (T010–T013, 2026-10-31): the
  backchannel agent self-tests at start-up and reports
  the result in every heartbeat; gk status shows the
  heartbeat age with a stale alarm past five minutes;
  a 16-check chaos battery (duplicates, corruption, STOP,
  kill/restart) runs the real agent in CI; and the
  recovery runbook ships the four cases with
  pre-written command bodies.
• — failsafe backchannel (owner override order,
  2026-10-29: Syncyard must have a failsafe backchannel for when
  Syncyard itself is down or blocked, with a dedicated channel
  just for Syncyard development in the Desktop Access chat).
  A dedicated channel syncyard-dev in the private repo
  tbitcs/syncyard-backchannel (channels/syncyard-dev/cmd.json,
  out.json, heartbeat.json), reserved exclusively for
  Syncyard development/recovery by the Desktop Access chat — no
  program job traffic, ever, and no other chat may post to it.
  The desktop agent (backchannel/agent.sh) runs as a WSL
  systemd user service independent of the runners, the tray, and
  the gatekeeper, syncs over git (no REST quota), executes only
  new, hash-verified command ids, honours a STOP kill switch,
  and never writes gatekeeper queue records. The VM-side client
  (backchannel/bc.py, stdlib only) sends through the GitHub
  contents API (works during VM write waves), refuses to
  overwrite an unacknowledged pending command unless --force,
  and verifies every send by read-back; offline tests live in
  backchannel/test_bc.py. Named recovery use cases: restart
  the packaged tray in the owner's session, read tray.log,
  restart a runner lane, read-only network diagnostics.
• Periodic Syncyard status-check duty, fleet-wide: every agent that uses Syncyard checks status before
  submitting desktop work and at least once per hour during an
  active desktop campaign (gk status, otherwise the
  backchannel heartbeat/status); a stale heartbeat (>5 min) or a
  down tray/runner is reported to the Desktop Access chat, never
  worked around. SKILL.md carries the duty and a Failsafe
  Backchannel section.
• Job protection on any Syncyard change:
  begin with a queue snapshot (record count, aggregate sha256
  of queue files, open-job list) and end with reconciliation —
  the open-job set after must equal the set before, or every
  difference is named and explained. No job may be lost
  silently.

Fixed

• Gatekeeper record updates are atomic swaps:
  a job record's file is only ever replaced by renaming a fully
  verified temp file over it — the record path is never opened
  for writing. The pre-direct-write fallback truncated
  the standing record before verification could fail, which is
  how records were lost in the 2026-10-28 write waves despite
  verified-retry. A failed save now leaves the prior record
  standing untouched (or nothing, for a new record — no husk
  can exist), sweep-internal saves go through a safe wrapper
  that ledgers save_failed and continues the pass, and a job
  whose pre-dispatch save fails is skipped rather than
  dispatched unrecorded. Proven by the fault-injection battery
  in gatekeeper/test_fr013.py.
• Gatekeeper refinement (same night): the failed-write
  cleanup removes only content that is not a valid record (0-byte
  or partial husks); a failed UPDATE leaves the last valid record
  standing and fails loudly. The first cleanup compared bytes and
  deleted a live record on a failed dispatch update - found and
  fixed under the pause-first fix discipline.
• Gatekeeper durable writes: every queue, ledger
  and control-file write is now write-verify-retry — unbuffered
  write, read-back byte verification, bounded retries with backoff,
  loud failure when unverifiable. The loader skips unreadable
  records with a warning, and a submission reports queued only
  after the loader verifies the record written. Defect escalation
  2026-10-27: the host VM intermittently refuses writes and can
  silently drop a buffe...

Syncyard 0.2.0 — failsafe backchannel

Owner-directed release (Tristen Pierson, 2026-10-29 override order).

• failsafe backchannel. A dedicated channel, syncyard-dev, in the private repo tbitcs/syncyard-backchannel, reserved exclusively for Syncyard development and recovery by the Desktop Access chat. No program job traffic.
• Desktop agent (backchannel/agent.sh): WSL systemd user service on TRISTEN-DESKTOP, independent of the Actions runners, the tray, and the gatekeeper. Git-protocol sync (no REST quota), sha256-gated commands, STOP kill switch, heartbeat every poll cycle.
• VM-side client (backchannel/bc.py): heartbeat / status / send / wait via the GitHub contents API — works during VM write waves and Actions outages.
• Fleet duty (SKILL.md): every agent checks Syncyard status before submitting desktop work and at least hourly during active desktop campaigns; a sick Syncyard is reported to the Desktop Access chat, never worked around.
• Job protection: Syncyard changes begin with a queue snapshot and end with reconciliation — no job lost silently.

Merge commit 2de1b16 (PR #15, CI green). The gatekeeper, lanes, and tray are unchanged in this release.

Syncyard Tray v0.1.0 (pre-release)

Syncyard Tray installer — r4 build (2026-10-28). Per-user install, no admin: installs to %LOCALAPPDATA%\Programs\SyncyardTray, HKCU Run autostart, Start Menu shortcut, registered uninstaller.

Asset: SyncyardTray-Setup-0.1.0.exe (179,944 bytes)
SHA-256: 7650013196d00ad42e3b03a50aea211d401c14e250f085ec64cebb593b2d7ad7

Pre-release for the T008 download-and-install verification. Project VERSION remains 0.1.1 (version hold in force).

Syncyard v0.1.1

Fixed

• Clients: unused polling-loop variable failed the ShellCheck CI step (SC2034); loops now use the throwaway variable. Behavior unchanged. Caught by the first CI run of the 0.1.0 scaffold.