dtourolle 0da0a9f16c fix(ci): derive traceability denominators from requirements.md (DR-093)
The coverage gate divided traced counts by hardcoded literals (UR/39,
IR/24, DR/48, JA/3, TOTAL_REQS=114) that had fallen out of date as
requirements grew to 211. It reported 158% coverage — JA alone printed
800% — so the 50% threshold was mathematically unreachable and the job
could not fail. Coverage could have collapsed to 30% and CI would still
have printed a green tick.

Real coverage is 86%. The number was fine; the gate was dead.

extract-traces.ts now owns both sides of the fraction:

- countDefinedRequirements() counts an ID only where it leads a markdown
  table row, ignoring the "Traces To" column and prose. IDs are
  deduplicated because requirements.md lists every UR twice (§1
  definition + §3 matrix), which would otherwise report UR as 121/61.
- computeCoverage() uses the intersection of traced and defined IDs, so
  a TRACES comment naming a deleted or typo'd requirement is reported as
  `orphaned` rather than inflating the ratio past 100%. UT/IT test
  identifiers are excluded as a separate taxonomy.
- CI reads .coverage.percent and fails on <50% or >100%; a >100% reading
  is now a hard error rather than the condition that hid this bug.
- New `bun run traces:coverage` runs the same computation locally.
- scripts/ added to the scan roots — the coverage tool was invisible to
  the matrix it generates.

Tests written first (15, over fixtures so they don't drift as
requirements are added). vitest include widened to scripts/** so build
tooling is covered by the normal suite.

Verified empirically rather than by inspection: forcing the threshold to
99% fails; adding a requirement lowers coverage 86%→85%; a TRACES: DR-999
lands in `orphaned` without changing `covered`.

traceability-ci.md documented the same stale numbers and would have let
the broken arithmetic be reconstructed — replaced with a pointer to the
live command.
2026-07-30 10:30:08 +02:00
2026-01-26 22:21:54 +01:00
2026-07-28 23:08:05 +02:00
2026-01-26 22:21:54 +01:00
2026-07-28 23:08:05 +02:00
2026-06-27 17:43:08 +02:00
2026-01-26 22:21:54 +01:00
2026-01-26 22:21:54 +01:00
2026-01-26 22:21:54 +01:00

JellyTau logo
JellyTau

A cross-platform Jellyfin client built with Tauri, SvelteKit, and TypeScript.

Business logic lives in a Rust backend; a UI-rich Svelte frontend handles presentation and talks to it over Tauri's IPC. Targets Linux (libmpv) and Android (ExoPlayer).

Getting Started

This project uses bun as its package manager.

# Activate the Rust environment (fish shell)
source "$HOME/.cargo/env.fish"

# Install dependencies
bun install

# Run in development
bun run tauri dev

# Type-check the frontend
bun run check

# Build for Linux
bun run tauri build

# Build for Android
bun run tauri android build

For the full set of build, test, and Android helper scripts, see scripts/README.md.

Documentation

Topic Location
Architecture overview & subsystem docs docs/architecture/
Requirements, traceability & technical debt docs/requirements.md
Build & release process docs/build-release.md
Docker builds docs/build/docker.md
Traceability tooling & CI docs/traceability.md, docs/traceability-ci.md
Release checklist docs/release-checklist.md
UX flows docs/ux-flows.md

VS Code + Svelte + Tauri + rust-analyzer.

License

MIT

S
Description
A jellyfin client with Tauri
Readme MIT
79 MiB
2026-08-22 08:10:12 +00:00
Languages
Rust 49.1%
TypeScript 26.6%
Svelte 17.1%
Kotlin 4.9%
Shell 1.7%
Other 0.5%