Files
yonluandClaude Opus 5 3d375adab1 feat(downloads): bound auto-pick by bitrate, and take a good copy
Three faults, one subsystem, and the middle one is why a request that
looked obviously satisfiable came back refused.

**The guardrails were in megabytes, which cannot mean anything.** 300 MB
is a generous FLAC single and a suspiciously small boxset, and whoever
fills the field in has no idea which release the pipeline will apply it
to. `MinKbps`/`MaxKbps`/`PreferredKbps` are the same statement divided
by how long the music is, so one number holds across a nine-minute EP
and a three-hour opera. The runtime comes from `Download.Expected`,
which every anchored request already carries, so this costs no lookup;
the rate is audio bytes over that, falling back to the mean stated
per-file bitrate when the runtime is unknown. Artwork is excluded from
the numerator, or a folder with 30 MB of scans reads as a better rip.

An unknown runtime *passes* the window rather than failing it: the
window is a statement about quality, and refusing everything the moment
MusicBrainz is missing a track length would be a silent embargo.
`MaxFileSizeMB` survives as a separate ceiling, still in megabytes on
purpose -- it is a question about disk space, and it has to apply to a
candidate whose bitrate cannot be worked out at all.

**Auto-pick required daylight over the runner-up**, 0.08 on the
combined score, and so fired hardest in the case it was never written
for: a popular album turns up five *correct* copies, all matching the
tracklist at 95%+ and differing only in format and seeders, their
scores land within a point of each other, and it refused forever on the
grounds that the choice was the user's. It was not. There was no
question about what to fetch, only about which copy -- and abundance is
the condition under which that matters least. A candidate no longer has
to beat the field, only clear the bars on its own terms; where several
do, ranking puts the one closest to the preferred bitrate first.

That tie-break needed the preference to carry weight or it would have
been decorative in a new unit: `BitrateFit` was 0.05 against format's
0.42, so asking for 320 and being handed a FLAC every time was the
designed behaviour. When a preference is set the weights shift to fit
0.40 / format 0.20 / bitrate 0.10, taking it off the two heuristics
that exist as stand-ins for the preference the user has now given.
Health and priority are untouched. And the fit spans 0.5 to 1.0 rather
than 0 to 1, so a preference can promote the copy that matches it and
can never push the others under `minQuality` -- turning "I like 320"
into "never take anything else" silently is what `MinKbps`/`MaxKbps`
are for, out loud.

**And a refusal quoted numbers that passed.** The request list built its
message from `ranked[0]` -- the best candidate *before* the guardrails
and before the lead check -- so a request killed by the size window, or
by having too many good copies, reported "best of 12 found is not a
confident enough match (match 96%, quality 88%)". `AutoPickVeto` names
the gate that actually refused, and `AutoPickable` is that returning
empty.

Existing configs: the old `MinFileSizeMB`/`PreferredFileSizeMB` are not
migrated. A number meaning "300 MB" cannot be reinterpreted as a rate
without knowing the album it was aimed at, so carrying it over would be
inventing an intent nobody expressed. Those two fall back to no window,
which is the permissive default and what a fresh install gets;
`MaxFileSizeMB` carries over unchanged, because a ceiling on bytes
still means exactly what it did.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MeQt5hgXg5YGoNZQ9ozG7L
2026-08-17 22:10:51 -04:00
..
2025-03-28 11:43:14 -05:00

YellowJacket Frontend

This directory contains the frontend for YellowJacket.

Dependencies

There are a couple of tools that are required to build and use the frontend.

  • vite for
    • transpiling typescript
    • bundling the final "package" that is useb by the webview
    • running a dev server with hot-reloading
    • configured with the vite.config.ts file in this directory
  • pnpm for managing frontend dependency packages

There are a handful of dependency packages that we use directly in the frontend.

Lastly, there are some dependencies that only benefit development

  • tsserver comes bundled with vscode and can be used as an LSP with other editors using typescript-language-server
    • Used for autocomplete, syntax highlighting, etc.
    • This can be configured with the tsconfig.json file in the root of the project
      • NOTE: your configuration should align with the vite config so you get in-editor feedback that aligns with how the build will be done.

Development

Ideally, you would use the frontend in the wails app as the frontend depends on the Go bindings generated by Wails. You can do this by running wails dev in the root of the YellowJacket repo.

If you want to run the frontend standalone, make sure the Wails go bindings have been generated with wails generate modules. Then, you can run pnpm dev to run the vite dev server. For more information on what commands are available, refer to package.json.

Code

Web Components

Our frontend is based off of Web Components, a standard that provides native browser encapsulation of components that can include HTML, CSS and Javascript all together. Instead of writing these components manually in Javascript, we utilize lit as a wrapper library.

Typescript

To better integrate with our tooling and to provide a better developer experience with strong typing, we have written all functional frontend code in Typescript. Vite serves as our Typescript transpiler.

Important Files and Directories

NOTE: most of these directories have aliases defined in tsconfig.json and vite.config.ts so that we may refer to them by shorthand when importing.

  • index.html and index.js is the entrypoint for the frontend. The first page that loads.
  • wailsjs/go Go code bindings generated by wails reside here
  • wailsjs/runtime the Wails runtime code needed to use Wails features
  • src all app code resides here
  • src/assets static assets like fonts, images and icons
  • src/components lit components that are used to compose the application
  • src/pages pages that serve as other entrypoints for the application that can be navigated to