Files
jellytau/scripts
dtourolle 38dd1129e5 feat(security): set a restrictive CSP and scope the asset protocol to thumbnails
`app.security.csp` was `null`, so the webview ran with no Content-Security-Policy
at all: any script that reached the web layer would have inherited the whole IPC
surface. There is no known injection path today (one app-owned `{@html}`, no
`innerHTML`/`eval`), so this is defence in depth rather than a fix for an open
hole.

`script-src 'self'` is the restrictive half — Tauri nonces SvelteKit's inline
bootstrap script at build time, so no `'unsafe-inline'` is needed — together with
`object-src`/`frame-src 'none'` and `base-uri 'self'`. `img-src`/`media-src`/
`connect-src` cannot be restrictive: the Jellyfin origin is typed in by the user
at run time and is routinely plain http on a LAN, so they allow `http:`/`https:`.
That is a wide grant for data, but it still bars `file:`/`filesystem:` and does
not touch script execution. A run-time policy naming the server exactly was
rejected: Tauri derives the header from immutable config when it serves the HTML,
so it would mean rebuilding config and reloading the webview on every server
change. `style-src` keeps `'unsafe-inline'` because Svelte compiles `style="…"`
attributes into markup; `worker-src`/`media-src` keep `blob:` for hls.js's
demuxer worker and its MSE object URL; `ipc:`/`http://ipc.localhost` keeps
`invoke` working. `devCsp` mirrors it with the eval/inline/websocket allowances
Vite's dev server needs.

The asset-protocol scope narrows from `$APPDATA/**` — the storage root holding
the SQLite database and the encrypted-token fallback file — to
`$APPDATA/thumbnails/**`. Since DR-137 moved downloaded media to the loopback
media server, `imageCache` is the only `convertFileSrc` caller left.

Needs manual verification on both platforms: thumbnails, online HLS video and
offline downloaded video cannot be exercised headlessly.
2026-08-16 22:58:53 +02:00
..
2026-01-26 22:21:54 +01:00
2026-01-26 22:21:54 +01:00
2026-06-20 15:32:32 +02:00
2026-01-26 22:21:54 +01:00

Development Scripts

Collection of utility scripts for building, testing, and deploying JellyTau.

Testing Scripts

test-all.sh

Run all tests (frontend + Rust backend).

./scripts/test-all.sh

test-frontend.sh

Run frontend tests only.

./scripts/test-frontend.sh          # Run all tests
./scripts/test-frontend.sh --watch  # Watch mode
./scripts/test-frontend.sh --ui     # Open UI

test-rust.sh

Run Rust tests only.

./scripts/test-rust.sh              # Run all tests
./scripts/test-rust.sh -- --nocapture  # Show println! output

Android Scripts

build-android.sh

Build the Android APK.

./scripts/build-android.sh          # Debug build
./scripts/build-android.sh release  # Release build

deploy-android.sh

Install APK on connected Android device.

./scripts/deploy-android.sh         # Deploy debug APK
./scripts/deploy-android.sh release # Deploy release APK

build-and-deploy.sh

Build and deploy in one command.

./scripts/build-and-deploy.sh       # Build + deploy debug
./scripts/build-and-deploy.sh release  # Build + deploy release

check-android.sh

Check Android development environment setup.

./scripts/check-android.sh

logcat.sh

View Android logcat filtered for the app.

./scripts/logcat.sh

Traceability & Documentation

extract-traces.ts

Extract requirement IDs (TRACES) from source code and generate a traceability matrix mapping requirements to implementation locations.

bun run traces                    # Generate markdown report
bun run traces:json              # Generate JSON report
bun run traces:markdown           # Save to docs/traceability.md
bun run traces:coverage           # Coverage gate — exits non-zero below 50%

The script scans all TypeScript, Svelte, and Rust files (plus scripts/) looking for TRACES: comments and generates a comprehensive mapping of:

  • Which code files implement which requirements
  • Line numbers and code context
  • Coverage summary by requirement type (UR, IR, DR, JA)

bun run traces:coverage is the supported way to check requirement coverage locally — it runs the same computation CI does. Coverage denominators are derived from docs/requirements.md at run time; they are never hardcoded. An ID that appears in a TRACES: comment but is not defined in requirements.md is reported as orphaned and does not count toward coverage (see DR-093).

Removed: check-req-coverage.sh, check-test-coverage.sh, and find-req-implementations.sh were deleted in July 2026. They read an undocumented @req: tag convention parallel to TRACES:, grepped src-tauri/ unscoped (hanging on ~40 GB of target/ artifacts), and in one case reported "all requirements implemented" from an empty result set. extract-traces.ts is the single source of truth for requirement coverage. See docs/specs/req-coverage-script-removal.md.

Example TRACES comment in code:

// TRACES: UR-005, UR-026 | DR-029
function handlePlayback() { ... }

See docs/traceability.md for the latest generated mapping.

CI/CD Validation

The traceability system is integrated with Gitea Actions CI/CD:

  • Automatically validates TRACES on every push and pull request
  • Enforces minimum 50% coverage threshold
  • Warns if new code lacks TRACES comments
  • Generates traceability reports automatically

For details, see:

Utility Scripts

clean.sh

Clean all build artifacts.

./scripts/clean.sh

NPM Script Aliases

You can also run these via npm/bun:

bun run test:all           # All tests
bun run test:rust          # Rust tests
bun run android:build      # Build Android APK
bun run android:deploy     # Deploy to device
bun run android:dev        # Build + deploy debug
bun run android:check      # Check environment
bun run clean              # Clean artifacts