# Every CI badge in Yosemite Crew points at the dev branch, and 28 of its 32 quality cells are the same link > YosemiteCrew/Yosemite-Crew is a TypeScript monorepo for animal health with a veterinary practice management system at its core. It is unusually well defended on paper, with four SonarCloud projects, five secret and vulnerability scanners, unit tests for its own CI scripts and a certificate expiry check. It is also carrying a branch mismatch in its badges and a quality table where almost every cell resolves to the same page. **YosemiteCrew/Yosemite-Crew** — Open-source operating system for animal health - Repository: https://github.com/YosemiteCrew/Yosemite-Crew - Website: https://yosemitecrew.com - Stars: 2,019 · Forks: 84 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/yosemitecrew-yosemite-crew ## A PIMS at the core, with apps and packages around it The positioning is stated twice in slightly different words. The readme calls it an open-source operating system for animal health, with a veterinary Practice Information Management System at its core, and the subtitle calls it a veterinary PIMS at the core with connected apps, integrations and community skills around it. Three audiences are named: veterinary teams, the families they care for, and the developers extending both. The tree backs the shape of that claim. There is an apps directory and a packages directory rather than a single application, which is what a core product with satellites around it looks like. The quality table names four projects in total, and their identifiers are the backend, the frontend, the mobile app and the desktop app, so the four deployables are separate analysis targets rather than one codebase measured four times. The word skills is doing specific work here. The readme's own navigation has a User skills entry and a Contribute entry side by side, so the extension surface is presented to two different readers: people who install a skill and people who write one. ## Both workflow badges are built for the dev branch, and main is the default There are two workflow badges at the top of the file, one for the main CI workflow and one for the supply chain workflow. Both of them carry the same query string, and that query string asks for pushes on the dev branch. The repository's default branch is main. So the two badges whose job is to tell you whether the project is green are reporting on a branch that is not the one you get by default. That may well be deliberate, if dev is where all work lands and main is cut from it, but nothing in the badge says so, and a reader arriving at the repository has no way to tell which branch they are looking at. A release process file sits at the root, so the question of which branch releases from is documented somewhere. It is simply not documented in the badge. ## Eight metrics times four projects, and almost every cell is the same address The code quality table has eight metric rows and four project columns. The rows are the quality gate, coverage, bugs, code smells, reliability, security rating, vulnerabilities and duplicated lines. The problem is in the links rather than the labels. In each of the four columns, the seven rows below the quality gate resolve to exactly the same address as the quality gate row itself. So the row labelled coverage does not go to a coverage page, the row labelled vulnerabilities does not go to a vulnerability page, and a reader comparing two metrics is looking at the same new-code summary eight times. Every one of those addresses is also a new-code summary rather than a whole-project view, which is a reasonable choice for a project under active development and a misleading one to read as an overall health figure. The column headings and the project identifiers also disagree slightly: the second column is headed Platform with Frontend in brackets while its identifier says Frontend, and the mobile column is headed Mobile App while its identifier carries a different abbreviation. ## Five secret scanners, and unit tests for the CI scripts The security surface is unusually wide, and it is worth taking inventory because most of it is invisible in the readme text. There is a gitleaks configuration and a gitleaks ignore file. There is a secretlint configuration and a secretlint ignore file, plus two secretlint rule packages as dev dependencies, one of which exists specifically to keep dotenv files out of commits. There is a grype configuration for vulnerability scanning, a grant file, and a shell script under a security directory that takes four subcommands: generate a software bill of materials, scan, produce a licence report, or do all three. On top of that sit three purpose-built checks. One compares dependency overrides against a stored advisories file, one checks whether those overrides have drifted, and one checks TLS certificate expiry. There is also a script that scans staged files for secrets before a commit, and a script that freezes a UI scorecard. The part that stands out is that the checks are themselves tested. The manifest has a script that runs the Node test runner across four directories of tests belonging to the CI, security, roadmap and mobile tooling. So the scanners are not just configured, they have regression tests, which is rarer than it should be. ## A private root manifest driving Turborepo, with CDK in the dev toolchain The root package manifest is private and holds no name or version, which is the normal shape for a workspace root. Every task is delegated to Turborepo: build, dev, start, lint, test and type-check all run as turbo run against the named target. There is a single verify script that chains lint, type-check, test and build in that order, which is the command to run before opening a change. The package manager is pnpm, with a workspace file, a lockfile and an npmrc, and a patches directory, meaning dependencies are patched in-tree rather than forked. The Node version is pinned in a file at the root. Formatting is Prettier across TypeScript, TSX and Markdown, and there are separate check and write forms. Two things in the dev dependencies are worth a second look. AWS CDK and its constructs library are there at a pinned 2.270.0, so infrastructure definitions live in the same repository as the application. And react-doctor is present with its own config file and its own command, which is a React diagnostics tool wired into the same script namespace as the security checks. ## Three beta tags in one day, two of them for different components The three most recent tags are all beta and all component-scoped. Two are for the PIMS, at 2.5.2 and 2.5.1, and one is for the backend at 2.5.2. The two 2.5.2 tags sit about six minutes apart, and the PIMS 2.5.1 tag about an hour before them. So the backend and the PIMS carry independent version numbers that happen to be aligned here, and the release unit is the component rather than the repository. That is the right shape for a monorepo with separately deployable apps, and it also means there is no single number to ask about. A reader who finds 2.5.2 has to know which component they are looking at. None of these tags drops a beta suffix, and the visible history contains no stable tag, so the versioning scheme in evidence is pre-1.0 and per-component. A release process document sits at the root alongside the readme, the security policy and the contributing guide. ## The licence file is called License.txt and the platform field says nothing The repository ships a file named License.txt at the root, with a badge at the top of the readme pointing at it. The platform's own license field for this repository reads as unknown rather than naming a licence. Those two facts sit side by side without either one contradicting the other on the page, which means a tool that reads the metadata sees no licence and a reader who clicks the badge sees one. Given that the surrounding governance is otherwise thorough, with a code of conduct, a security policy, a contributing guide, a release process document and a dependency licence report generated by the supply chain script, the gap is the kind that is usually an oversight in the repository settings rather than a decision. Two smaller gaps are worth naming in the same breath. The product walkthrough is a bare video address with no link text and no embedded player, so it renders as a long URL rather than as a demonstration. And the overview's first feature bullet ends partway through its first word, so the list of what the PIMS actually does is not readable from the readme at all. A separate current-capabilities document is linked from the contents list, which is probably where that list lives. ## Conclusion Yosemite Crew is worth a look if you work on veterinary software and want an application whose owners treat supply chain and quality gates as part of the build rather than as a quarterly exercise, because the tooling here is several layers deeper than the readme advertises. Three things to check before adopting or contributing. Read the quality table carefully, because the rows do not report what their labels suggest and every figure is a new-code summary rather than a whole-codebase one. Establish which branch you are on, since the badges are built for dev while the default branch is main. And if you are evaluating it for production clinical use, look for the current-capabilities document the readme links, because the readme's own feature list stops partway through its first entry. ## FAQ ### What is Yosemite Crew? An open-source operating system for animal health with a veterinary Practice Information Management System at its core, plus connected apps, integrations and community skills around it. It is written in TypeScript and is aimed at veterinary teams, the families they care for, and the developers extending both. ### How do you run the checks in the Yosemite Crew repository? pnpm run verify, which runs lint, type-check, test and build in that order through Turborepo. Security checks are separate: check:secrets runs secretlint with secret masking, check:staged-secrets runs before a commit, check:override-advisories and check:override-drift compare dependency overrides, check:tls tests certificate expiry, and a supply chain script offers sbom, scan, licenses and all. ### What does the CI badge tell me about Yosemite Crew? Both workflow badges, for the main CI and for the supply chain, are built with a query for pushes on the dev branch. The repository's default branch is main, so the badge state is not about the branch a visitor gets by default. ### How is Yosemite Crew versioned? Per component and in beta. The three most recent tags are pims-v2.5.2-beta, pims-v2.5.1-beta and backend-v2.5.2-beta, with the two 2.5.2 tags six minutes apart, so the backend and the PIMS carry their own numbers. A release process document sits at the repository root. ### Does Yosemite Crew publish code quality metrics? It has a SonarCloud table with eight metrics across four projects, named Backend, Platform with Frontend in brackets, Mobile App and Desktop. Every row in a column links to a new-code summary page, and the seven rows below the quality gate resolve to the same address as the quality gate itself. ### What tooling does the Yosemite Crew repository use? pnpm workspaces driven by Turborepo, with ESLint, Prettier, commitlint and lint-staged through Husky. Secrets and vulnerabilities are covered by secretlint, gitleaks and grype configurations, with SonarLint and SonarCloud for analysis, git-cliff for changelogs and react-doctor for React diagnostics. AWS CDK and constructs are also dev dependencies. ## Sources - [Issues](https://github.com/YosemiteCrew/Yosemite-Crew/issues) - [Project website](https://yosemitecrew.com) - [README](https://github.com/YosemiteCrew/Yosemite-Crew/blob/main/README.md) - [Releases](https://github.com/YosemiteCrew/Yosemite-Crew/releases) - [YosemiteCrew/Yosemite-Crew on GitHub](https://github.com/YosemiteCrew/Yosemite-Crew) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/yosemitecrew-yosemite-crew