What each product is, its version and where to start, then every page on this site with what it is for, the pages you only reach by a link included. The build that publishes the site writes this section from the pages themselves, so a new page, button or version is listed here the moment it goes live, with nothing to update by hand. This copy was written 2026-10-18 07:02 UTC. The buttons on every page are on Every button, and what changed lately in each product on What’s new.
privacy statement version 15 (2026-10-18)
SymphonyBoard and Symphony Setup: install them on a repository, press Create on the form they open, and the repository becomes one where many Claude Code sessions, routines and GitHub Actions workers share the work without stepping on each other.
changes with every build of this site
Drive a Symphony repository from the browser as yourself: the board, the queue, the workers, the checks, the pull requests, the assistant, the Claude tokens the workers run on, and what the work costs.
version 1.4.1
The extension that puts Symphony's install one click away on a repository's page on github.com and says when a repository is ready.
version read from GitHub when the page opens
The skills, /board and the push guard for a repository that was not made from the template, installed from the symphony-marketplace plugin marketplace.
version read from GitHub when the page opens
The claim protocol as a Python library with no dependencies: how work is claimed, done in the open and finished, the board, the protocol check and the push guard's rules.
version 23.0.0
The Chrome extension that starts a Claude Code worker on the university's compute grid from one panel, on the Chrome Web Store.
version 5.0.0
Beethoven's edition for Visual Studio Code.
By the tab it sits under, in the order of the menus. A page marked “reached by a link you are sent” is in no menu, since it is meant for the person given its address; it is listed here so nothing on the site is out of reach.
One shared repository, any number of Claude Code sessions, driven by students or running on their own. OpenSpineConsortium builds the protocol and the tools that keep them from colliding, and runs its spine imaging research on them.
Install the Symphony GitHub App, press Create, merge the pull request: your repository gets a queue, a board and a claim protocol that any number of Claude Code sessions work by, on their own accounts.
Drive your Symphony repositories from one console, as yourself, from your browser: launch the workers, the board, the checks and the metrics; the board, the queue, the pull requests, the workers, the Claude accounts, and a box to ask Claude.
The Claude accounts a Symphony repository's workers run on are now the Tokens tab of the control panel: each slot's use with its resets, which slot auto takes, adding an account, and which worker runs on which.
What running Claude Code teammates costs under Symphony, measured on your own repository, set beside what the same work costs under the other ways of running coding agents on GitHub.
What Symphony can be used for, told for someone who has never heard of it: several Claude sessions on one code base, a team on their own accounts, work that carries on overnight, papers revised from reviewers' comments, jobs on a university cluster and volunteer projects.
What the Symphony protocol does in general, set beside the tools people already use for coding agents, task tracking, automation, document review, cluster jobs, volunteer projects and agent frameworks.
What the Symphony browser extension collects (nothing), sends (nothing), keeps on your device (one short-lived note) and reads from a github.com page, and the two permissions it asks for.
What the two Symphony GitHub Apps, SymphonyBoard and Symphony Setup, can read in a repository, what they write there, what the developer receives (anonymous aggregates under a salted hash) and keeps, and how to turn each of those off.
Ask in claude.ai and a Claude Code worker on the Wayne State grid does the work, on an H200 when it needs one.
The Beethoven Trial Edition License Agreement: the terms accepted once in the extension's signing dialog, including the dispute section.
What stays in your browser, what your portal sees, how Beethoven signs in to your portal and what it keeps if you save your password, what happens when you sign in to Claude, what Anthropic receives, what the maintainer receives, and what is never collected.
Getting help with Beethoven, how it works step by step, your grid sign-in (typing it, saving it under Windows Hello or Touch ID or not, unlocking, forgetting it, Chrome's own box), when the grid is out of reach, your grid code, what an earlier version may have left, the notice address, disputes, refunds and outages, security reports and your records.
Ask for access to Beethoven with your Wayne State AccessID; the lab lead approves requests by hand, and Beethoven installs from its Chrome Web Store listing.
What Beethoven is, what it never does, the permissions it asks for (webRequest and webRequestAuthProvider for the grid sign-in among them) and exactly what its one sign-in listener answers, how it reaches the cluster through the university's portal behind its VPN, how it checks for withdrawn versions without running remote code, and how to try it against the mock portal.
Beethoven for VS Code sets up your laptop for the Wayne State grid and keeps a Claude Code worker running in your own grid account, reachable from VS Code and from the Claude app.
The Beethoven for VS Code Trial Edition License Agreement: the terms accepted once in the extension's signing dialog, including the dispute section.
The Beethoven for VS Code Full Edition License Agreement, accepted in the signing dialog when a Full Edition key is registered.
What Beethoven for VS Code keeps on your laptop, what goes to your own grid account and to services you already use, and what may go to the maintainer.
The open-source packages bundled into Beethoven for VS Code, each with its own licence as that licence requires.
The maintainer's list of people approved to use Beethoven.
Ask the lab lead for read access to named folders of the lab's storage on the Wayne State grid.
Five things to have, three steps, and your first question to Claude Code on the Wayne State grid.
OpenSpineConsortium builds openly licensed datasets and reproducible benchmarks for spine and pelvis medical imaging, with a focus on anatomical variants and clinically grounded AI.
Where the consortium's work is presented, and by whom: the MANS annual meeting, the Preston M. Hickey Medical Student Symposium and the AACA annual meeting, 2026.
A free, hands-on morning on building spine-imaging AI, from reproducible Python and SLURM workflows to training your own neural networks on the WSU grid.
What success looks like for the consortium: near-term deliverables, the longer arc, and the CNS 2026 abstracts.
Long-course endurance racing: IRONMAN 70.3 La Quinta and The Louisiana Marathon.
The consortium's open datasets, the reference atlas, the specimen gallery, the surgical hardware, the Spine MRI teaching series and the spinopelvic CT and X-ray demos.
CTSpinoPelvic1K: 802 abdominal CT records with the spine, sacrum, hips, femora, per-level ribs and surgical hardware segmented in one frame, with the reference atlas and the benchmarks built on it.
Lumbar and lower thoracic morphometry by level from 802 CT records, with the distribution attached: median, interquartile range and 5th-95th percentile for body height, endplate width, canal dimensions, pedicle width, disc height and trabecular attenuation.
Surfaces rendered from the released CTSpinoPelvic1K segmentations on a turntable, and the shape of the cohort.
The surgical implants in CTSpinoPelvic1K, each labelled as its own structure and rendered from the released segmentation.
An open five-part teaching series on reading spine MRI: timelines of cord compression, cervical cord compression, lumbar central stenosis, nerve root and foramen, and the anatomic checkpoints that decide whether you are naming the right level.
Four timelines from published cohorts: how long compression takes to become myelopathic, when damage stops being reversible, what recovery looks like after surgery, and how often to see people.
Cervical spine MRI: which sequence is which, an eight-step read, the five findings that change management, and three artefacts that will fool you.
Grading the dural sac by what is inside it: the Schizas system, why morphology beats measuring area, and a drill.
Two zones, two grading systems, two sequences: Pfirrmann in the lateral recess, Lee in the foramen, and the muscle finding that localises the level.
Where the cord ends and whether you are counting the right level: conus position, transitional anatomy, and when the conus itself is the lesion.
Interactive PACS-style viewer for CTSpinoPelvic1K with on-click pelvic incidence, sacral slope, pelvic tilt and lumbar lordosis from OpenSpineToolkit.
Lateral radiograph tab of the OpenSpineConsortium spinopelvic demo: vertebral corner landmarks, sacral slope and lumbar lordosis, with a YOLO-Pose model running in your own browser on your own film.
The consortium's contributors, clinicians, computer scientists and medical students building computational spine imaging together, and the institutions they come from.
OpenSpineConsortium is an open, GitHub-native research collaboration: lightweight governance and four principles.
OpenSpineConsortium as a medical-education model: self-rated competence before and after, headline outcomes and what participants said, from the participation survey.
Celebrate Life: on Saturday, October 24 from 5 to 7 PM, an indoor field at the Detroit City Fieldhouse, 3401 E Lafayette St, Detroit, is reserved for a soccer game for pediatric hematology and oncology patients under 18, coached by professional players from Southeast Michigan, held with the Detroit City FC Halloween Trunk or Treat. Free, no RSVP required.
Every product the consortium makes, its version and where to start, and every page on this site with what it is for, written afresh on every build.
Every button and button link on every page of the site, by page, read from the pages themselves on every build.
What changed lately in each of the consortium's products: the merged pull requests of the public repositories, read live from GitHub, and each product's own list of changes.