Brick Work 1.0.1

A fix release: fresh containers set themselves up on first start and no longer log the gunicorn control-socket error. The schema stays 4.2, so a 1.0.0 collection needs no upgrade step, and going back means starting 1.0.0 on the same file. The published image is ghcr.io/ulef1005/brick-work:1.0.1; a new container no longer needs the console brickwork setup step. Back up brickwork.db and secret.key before you upgrade, as always.

• Containers set themselves up on first start (#266). A new container creates and seeds its missing collection automatically; existing installs are unchanged and the console brickwork setup step is no longer needed with this version. The new brickwork setup --if-missing flag skips any existing collection file.
• No control server error at container start (#265). Gunicorn runs with its unused control socket disabled, removing the "Control server error" permission-denied line.
• Facts for AI assistants. The Pages site now serves /llms.txt (the llmstxt.org convention), built by scripts/build_site.py from scripts/site/llms.md: what Brick Work is and is not for, requirements, install, data, keys, imports, API and MCP, what it contacts, with the release's version filled in and links to the docs as raw Markdown. The README has a short For AI assistants section that points to it. tests/test_llms_txt.py checks that every linked file exists and every placeholder is filled.
• What it contacts names the picture downloads. The README's What it contacts now says that pictures of the items you add come from BrickLink and Rebrickable as plain downloads, with no key, as the note under its screenshots already did.
• A video tour. A 1:36 walkthrough on YouTube (watch) shows the collection, Set Inspector, Part Runner and Matchmaker on the demo's invented collection, with a chapter card and captions for each. The README's link bar and its demo line link it, and the landing page has a Watch the tour button beside Try the demo. Its opening and closing scenes are generated with Google Veo, as the video and its description say.
• Set cards show each copy's status again (#258). On Collection › Sets every card said Not checked, also for a copy that is complete, incomplete or sealed; the filter chips above the list were right. The card read the status in a form the list stopped sending with the 4.0 data model (0.6.0). It now shows Complete, Incomplete, Sealed or Not checked for each copy, one pill per status when a set has several copies.
• Install on your computer with Docker Desktop. A new how-to, Install on your computer with Docker Desktop, takes a Windows or Mac user without a server or Git from installing Docker Desktop to the first sign-in: a folder, two files (compose.yaml of the release and data/.env with the password), three commands, and what to do when a step fails. Tested on macOS with Docker Desktop 4.75; Windows is not tested yet. The README's install section and the Pages landing page link it.
• The README says who it is for on its first screen. The paragraph under the tagline now says who Brick Work is for, how it relates to Rebrickable and Brickset, and which sites and apps it brings a collection over from. The paragraph on the database files and ids it replaces moved, unchanged, to Works with the sites you already use.
• Discussions with forms. The repository's Discussions are on, and three categories have their own form in .github/DISCUSSION_TEMPLATE/: Show and tell (your collection, where it runs, what you use, where you came from, what got in the way), Q&A (question, version, where it runs, what you tried) and Ideas (the job, which kind of collector, how you do it today; a clear idea becomes an enhancement issue). Each asks you to leave out personal data.
• A social preview picture. docs/img/social/social-preview-1280x640.png is the picture GitHub shows when the repository link is shared: the lockup, the lead line and the README's Sets and Part Runner captures on the invented collection.
• The install steps follow the release. tests/test_install_docs.py fails when the README's or the landing page's git clone --branch, or the Docker Desktop guide's compose.yaml link, names another version than brickwork/version.py, so a release commit bumps them with the image tag.
• The check job runs in about a third of the time (#254). The tests run in parallel (pytest -n auto --dist loadgroup, pytest-xdist; the Chrome and screen-gate tests share one group), the screen gate runs on its own after them in one Chrome session, as its baselines were made, and a pull request that changes only documentation runs the docs check and the site build instead of the whole gate (scripts/check_scope.py). The standalone smoke test no longer runs twice. No test was removed or loosened; ADR 0024 has the numbers.

Brick Work 1.0.0

The first release after milestone B: its maintainer's real collection was set up from scratch through Get started on a test install, and every workflow ran on it. The schema stays 4.2, so a 0.9.0 collection needs no upgrade step, and going back to 0.9.0 means starting it on the same file. It is the first release whose compose.yaml pulls the published image, ghcr.io/ulef1005/brick-work:1.0.0 (amd64 and arm64, with build provenance and an SBOM): install and upgrade with docker compose pull; 0.9.0 and older still build with docker compose build (Upgrade Brick Work). Back up brickwork.db and secret.key before you upgrade, as always.

• The README describes 1.0.0 and introduces the crew. A new section, The crew, above Where we stand, gives each named Workbench workflow a paragraph: Part Spotter, Set Inspector, Part Runner and Matchmaker, with links to their guides; it replaces the short list of three. Where we stand describes release 1.0.0 (milestone B passed, the first release that pulls the published image), and the shipped list names Part Spotter, Storage and the tutorials.
• The upgrade guide shows how to check the published image (#190). Upgrade Brick Work now gives the two gh attestation verify commands for a pull-first release: one for the build provenance, one for the SBOM attached to the image, and what a failure means. The README names the SBOM check too.
• Tutorial: finish a half-built set (#247). Finish a half-built set is a second learning path in the docs, on the same invented collection as the demo: check a half-built copy in Set Inspector, put the missing parts on a wishlist, receive a parts order against them and watch the copy turn complete. It links Check a set's parts, Manage wishlists and Receive a parts order. Its pictures come from scripts/site_shots.py (new tut- stems), light and dark; the docs site now ships docs/img/tutorials/.
• Tutorial: your first set, start to finish (#246). The tutorials page had no tutorial. It now has one: install from the README, the Get started first run (catalogue, keys optional), add one set, check its parts and see what is missing and where it shows up. See Your first set, start to finish.
• Tutorial: build from your bulk (#248). Build from your bulk is a learning path on the user docs site: set up storage with drawers, collect the missing parts of several sets in one pass with Part Runner, then let Matchmaker show the sets your loose stock finishes. Phone and desktop pictures, light and dark, come from scripts/site_shots.py (new stems bulk-*).
• Tutorial: script your collection (#249). Script your collection is a learning path on the user docs site: create an API token, read and change the collection with the API and the command line, then connect an assistant over MCP and ask it about the collection. Every command and output was run on the invented showcase collection.
• The SBOM attestation uses actions/attest (#190). The release workflow's SBOM attestation ran actions/attest-sbom, which GitHub has deprecated; it now runs actions/attest v4.2.2 (pinned by SHA) with the same subject, SBOM and registry push.
• No empty band under the phone's bottom navigation in the browser (#245). The bottom bar always reserved at least 34 px below its icons, so in Safari, where the browser's own toolbar already sits at the bottom, an empty strip showed under it. The bar now reserves only the space the phone reports: nothing in the browser, the home-indicator space in the installed app. Page content, sheets and save bars still sit just above the bar. The approved phone (390 px) screenshots change by that strip.
• The demo's picture note fits its tile (#197). On the demo, a tile with no picture said where the app gets pictures (Loads from BrickLink when you add the set), even in a list row's small thumbnail, where the sentence spilled out of the tile. The note now goes only into a picture box (.bc-picture, .bw-picture, .check-picture, .scan-tile) at least 120 px wide; any other tile keeps the app's short No image. The demo page check fails if a note leaves its tile.
• The copy of the upstream changelog is gone (#237). docs/upstream-CHANGELOG.md, the upstream project's release history kept from the fork, is removed; this changelog links the upstream repository for releases 1.4.2 and older. The credit in the README and THIRD_PARTY_NOTICES stays.
• The Add search field sits right under the ways to find (#221). On Manage › Add, step 1 put What and Where above the Search, Paste, File and Photo tabs and the search field, so on a phone the field you type into sat below the first screen. The field (or the file and photo choosers) now follows the tabs directly, then What and Where in one row (stacked on a phone), then the results and Review. Nothing else changed, and the Tab key follows the new order. See Bring your collection in from another app.
• The install and upgrade steps for 0.9.0 say docker compose build (#238). The README and Upgrade Brick Work told you to check out v0.9.0 and run docker compose pull, but that tag's compose.yaml builds the image from source and names no published one, so the pull fetched nothing useful. For 0.9.0 the steps now say docker compose build, and going back to 0.9.0 or older does too. The pull-first install, and the provenance check of the published image, start with the first release cut after 0.9.0. The tag itself is unchanged. Back up and restore and the Pages landing page say the same.
• The Pages landing page no longer lists Collection sync as planned (#239). Its roadmap row said sync was planned although the page's own section says it is available for Rebrickable and Brickset; the row now reads Collection sync with BrickLink, the part that is still planned. The page also said the catalogue uses your own keys; it now says what the README says: the catalogue comes from Rebrickable's public download and needs no key, and your keys add prices, pictures and sync.
• An order e-mail line for a Technic figure in an unknown colour is no longer placed without a colour (#239). A line such as "Red Technic Figure ..." for an old Technic figure that the catalogue holds as a part was placed as that part in no colour even when the e-mail's colour name was not known here, where an ordinary part says The colour name is not known. The figure now takes the no-colour path only when the line names no colour; a named colour that is not known leaves the line for you to match, with that message.
• Lists say the right noun before the page's script runs (#239). The Instructions list's subtitle and Show button said "instructions" until the script replaced it with "booklets", and the Wishlist said "1 wishlist" or "3 wishlist". Both now read "booklets", "1 wish" and "2 wishes" from the first paint, with the same nouns the script uses for every list.
• The Wishlist chips have their gap, and Undo shows once (#224). On Planning › Wishlist the list chips (All lists, Wishlist and your own lists) touched each other; they now have the 8 px gap of the other chip rows. After a save the line read Saved · Undo with an Undo button under it, so Undo showed twice. It now reads Saved with the Undo button beside it on one line, as in Set Inspector. See Manage wishlists.
• Get started and Statistics sit at the top of Tools & Admin (#219). Manage › Tools & Admin now opens with two cards on the soft accent tint, Get started (with how many steps are done) and Statistics, side by side; on a phone they stack. The whole card is a link. The other groups follow in their usual order. See Settings and maintenance.
• Statistics charts read at a glance (#220). Tools & Admin › Statistics drops the cards: two charts sit side by side on a wide screen and one under the other on a phone, each row one line (label, bar, value). All four charts share one scale, so a bar means the same number of copies everywhere, with one note under them instead of one per chart. Each title states its point from your data ("Only 5 copies are complete", "Harbour is the biggest theme, 3 copies"), the headline reads "9 of 25 copies are incomplete", and completeness is in status order (Complete, Incomplete, Not checked, Sealed). After six rows a long tail folds into one outlined row such as "14 more themes". See Settings and maintenance. The approved Statistics screenshots change with it.
• Jump search is calmer (#216). In the search that opens from the top bar (Jump to a set, copy, figure or part, also ⌘K), the highlighted result row is now a soft neutral grey-beige with normal text instead of a clay-tinted fill, and the search field has a thin clay outline instead of a heavy one. The colours follow the light and dark modes; nothing else about the search changed.
• Found 1 on the set page, a missing-only check and a three-step end of a check (#215, #222, #214). Every missing part card on a copy's page has Found 1, which lowers its missing count by one with Undo and leaves the loose stock alone; where the card has Take N, it is a text link under it. Check missing only, beside Check parts, starts a Set Inspector run over just the parts the last check left missing (Missing part n of N, each sh...

Brick Work 0.9.0

The first stability release (milestone 1.0): a stable schema with tested upgrades from 0.5.x, a written upgrade and backup guide, and the first published container image, ghcr.io/ulef1005/brick-work (amd64 and arm64; see Releases and the container image). A 0.8.x collection (schema 4.1) is upgraded in place when 0.9.0 first opens it read-write: three columns are added and nothing else changes. The upgrade is one-way: 0.8.x cannot open a 4.2 file and stops with a 3.3 file must be migrated; ignore that hint, which is meant for 3.3 files. So back up brickwork.db and secret.key before you upgrade, and to go back, restore that backup (Upgrade Brick Work, Back up and restore). catalogue.db is not touched.

• New items get their picture from every path that adds them (#183). Only Add queued the picture download; an item placed by an order line into loose stock, by Part to Inventory, by Import from BrickTracker, by a Collection sync pull or by Found in the Workbench showed No image until you pressed Refresh pictures. These paths now queue the Downloading images step for an item that has no picture for a colour you hold, once per item and never for an unidentified one. See Pictures and prices.
• Gear, Books and Catalogs get their own icons, simpler filters and a visible phone strip (#153). The sidebar entries for the three kinds no longer borrow the Parts icon: Gear is a shopping bag, Books an open book and Catalogs a catalog over a second page. Their lists drop the filters that only mean something for parts (Problems, Stock: In sets only and Theme), Group by no longer offers Theme, and the search box says Name or number. In the grid, a card without a picture shows its number once, in the picture tile, instead of again above the name; the list view keeps it on the name line, where a long ISBN stays readable. On a phone the top strip scrolls the current entry into view, also after the window is narrowed or the phone turned, so Catalogs no longer sits off the edge. Five approved phone screenshots change with it.
• Brickset's old New and Used values are marked legacy (#173). A collection moved from 3.3 keeps Brickset's set values from that time. Brick Work 3.3 read them from Brickset's website, and Brickset's API has none, so they are never refreshed. The item page's Price records now mark them legacy · Brickset 3.3, not refreshed, and so does the Estimate when it comes from one; the Prices screen labels them the same. Market prices stay BrickLink's. See Pictures and prices.
• An empty kind's page keeps its place in the menu (#171). Opening Gear, Books or Catalogs when the collection holds none, for example from a link, showed no active entry in the sidebar, and on a phone the bottom bar marked Manage and showed its links. While such a page is open, its kind now shows under Collection, marked as the current page. On other pages an empty kind stays hidden, as before.
• Upgrade, backup and restore are written down and tested (#80). New guide Upgrade Brick Work: what each version does to the schema, which step you run yourself (brickwork migrate4 for a 0.5.x collection), how to check the result and how to go back. The README has Upgrade and Backup and restore sections. A new test takes a 0.5.0-shaped (3.3) collection through migrate4 and the 4.0, 4.1 and 4.2 steps, counting rows and running brickwork check's checks at the end. Back up and restore now names the API v2 paths of the export and the check (the v1 paths answer 410).
• Schema 4.2. One in-place step adds three columns: who holds a job (#167) and why an order line was not placed (#155). A 4.1 collection is upgraded the first time it is opened, as 4.1 was; Undo of changes made before the upgrade works as before. See Schema notes.
• Order e-mails: more lines get suggestions, and an undone import can be pasted again (#155). A line no item matches exactly now offers Could be candidates from the BrickLink item lists: the longest list name that starts the line's name (a seller's note such as "micro scratches" written after it), then names that hold all of its words (an item BrickLink renamed). They are suggestions only; you still choose. The API's order line has unplaced_reason, in words, for a line that is not placed. Undoing an import and pasting the same e-mail or XML again brings the document back as a draft, where it was reported as already imported. Export orders with One per order lists only orders that have saved lines. See Receive an order.
• A job left running at a restart runs again (#167). If the app stopped mid-job and, after the restart, the old process number belonged to another program, the job could stay running for good, and a catalogue job would refuse every new one as already running. A job claim now records the machine's boot and the start of the process that holds it, and a claim whose process is not that one is taken over. Jobs left running by 4.1 are taken over at the first start on 4.2. A call that was being sent when the process was killed is counted again when the step restarts: restart between jobs, or once the day's budget is used up, to lose none (Sources).
• Brickset's minifigure CSV (#146). Add › Minifigure › File reads Brickset's minifigure export: with Loose the figures you own loose (Brickset's loose count, so the figures in your sets are not added twice), with Wishlist the figures marked wanted. Before, it was refused with CSV needs part_num, set_num or minifig_num. See Bring your collection in from another app.
• Clearer CLI, MCP and order messages (#152). brickwork mcp calls http://127.0.0.1:3333/api/v2 by default, the install's own port (was 5000), and a URL that answers with the web app says so instead of returning the page. brickwork settings set incomplete_discount_pct with a word gives the range message. A second brickwork wishlist undo of the same change says Already undone. python -m brickwork.store4 jobs names an item job's item (was item None). Importing a placed BrickLink order whose items BrickLink has purged says so and suggests pasting the e-mail (was No order lines were found).
• What is this? and the import banner (#142, #145). Workbench › What is this? now lights Part to Inventory in the sidebar, the Workbench tool that also identifies a part by photo (was Tools & Admin). After Import from BrickTracker, the banner counts loose items by line, as the preview does, with the pieces beside them: 351 loose items (435 pieces), or just the lines when they agree. Before, it showed the pieces as items.
• Workbench lists show their count (#174). Recent saves on every Workbench tool, and the Part Picker's Pick for which sets? list, showed <span class="mono" data-count role="status"></span> as text where the number of shown rows belongs. They now show the count.
• Focus stays in a sheet you have just opened (#174). Closing a sheet with Escape and at once opening another could move the focus back to the sidebar, out of the new sheet. Focus now goes back to where it came from only when no sheet is open.

Container image: docker pull ghcr.io/ulef1005/brick-work:0.9.0 (amd64 and arm64; also tagged 0.9, 0 and latest), index digest sha256:6937babe2906bcac03dd40bcdcb0da1801428e3d8eae3560c0351db2959d123c, with build provenance and SBOM attestations (gh attestation verify oci://ghcr.io/ulef1005/brick-work:0.9.0 --owner Ulef1005).

Brick Work 0.8.1

Two fixes found while setting up and testing milestone B. No schema change: a 0.8.0 collection opens as it is, and going back to 0.8.0 needs no restore. Keep the new secret.key with brickwork.db in your backups.

• Orders with items only BrickLink has (#154). An order line naming an instruction booklet or a BrickLink-only part (some sticker and printed parts) could not be matched, so the order could not be reviewed or saved. When the BrickLink item lists are loaded (Tools & Admin → BrickLink item lists → Load lists), such a line now gets a new item of Brick Work's own, named as BrickLink names it, when the order is read and when you match the line by its number. An e-mail's "(Instructions) for Set 7946" names the set's one booklet (7946-1). A number another item already holds is never made a second time. Undoing the import leaves the new item, unused. See Receive an order.
• Key entry works on a fresh install (#144). Without BW_SECRET_KEY, Brick Work now makes its own encryption key on first use and keeps it in secret.key beside brickwork.db (mode 600), so Get started step 2, Catalogues & keys and PUT /sources/{source}/key no longer need a setting. BW_SECRET_KEY, when set, still wins and no file is made. If the data folder cannot be written, key entry stays disabled and the message says to set BW_SECRET_KEY (with the command that makes a key) or make the folder writable. A damaged secret.key fails closed and is never shown or replaced. Keep secret.key with brickwork.db in your backups: without it the stored source keys cannot be decrypted and must be entered again (the database export leaves them out anyway). See Back up and restore and Settings.

Brick Work 0.8.0

Milestone A, onboarding: a fresh install reaches its own collection through one guided flow, Get started. No schema change: a 0.7.0 collection (schema 4.1) opens as it is, and going back to 0.7.0 needs no restore. See Bring your collection in from another app and Settings and maintenance.

• No key yet is not a failure (#139). A step that only lacks a key (a BrickLink price, Brickset's set data) now ends as done and waiting for the key, so a job no longer shows failed on an install where you skipped the keys. Jobs says Waiting for a key · runs once it is stored. Storing the key puts those steps back in the queue, and so does a start with a key set in the environment. A key the site refuses still fails.
• BrickLink part numbers that name several parts (#140). BrickLink files some Rebrickable parts under one number: 3001 also names the old mould 3556. An XML line for such a part now takes the part with the same Rebrickable number and says so in the review. Without one, it names the candidates. Before, it was refused as Colour needs manual matching although the colour was known.
• Bulk actions are one job (#127): Refresh pictures, Bulk refresh prices and fetching missing booklets show as one row in Jobs, with its progress (done, failed, cancelled, to go), the failed items with their reasons, and Cancel for what is left. Your own work runs first: an Add's import and part list, or a single Update price, go before the batch's next item, so a new set no longer waits up to 45 minutes behind a picture refresh. The per-source budgets hold as before. See Settings and maintenance.
• Get started (#83, milestone A): the first run is one flow of four steps, in this order: Load the catalogue, Set up your keys (optional), Bring your collection in and See how the inventory works. Every step can be skipped for now and taken back. The flow resumes at the first open step, and after the first run it opens again from Tools & Admin › Get started, with how many steps are done. Before, the keys came first and the BrickTracker import was a fourth step. The catalogue step explains what the catalogue is (what it holds, Brick Work ids, what comes later), and once it is done shows how many items and colours it holds and the date of its files (#85). The keys step carries the key cards of Catalogues & keys: what each key gives, a link to where it is made, Test and save, and the site's reason when it refuses one; it says what is missing without keys (#84). Step 3, Bring your collection in, asks where your collection lives today: a Rebrickable or Brickset account (Collection sync), a BrickLink XML file, Import from BrickTracker, another app's BrickLink XML or Rebrickable CSV, or by hand. Each opens its existing path, which offers ‹ Back to Get started. There, a summary counts what came in, how many copies still lack condition and completeness, and links each imported from … tag. Brickset's My Sets CSV is read by Add (File): owned sets with their count, split by new and used, or wanted sets to a wishlist; a file without the columns it needs is refused by name (#12). Add opens on a mode given in its link (?mode=file). New guide: Bring your collection in from another app (#86). Step 4, See how the inventory works, is five short cards (sets and copies, completeness, loose stock and lots, the workflows at the table, an assistant), each linking to the screen it explains, with the important words in bold; Got it marks it read (#87). See Settings and maintenance.

Brick Work 0.7.0

A wish gets a maximum price with box, which brings schema 4.1. A 0.6.0 collection (schema 4.0) is upgraded in place when 0.7.0 first opens it read-write. The upgrade is one-way: 0.6.0 cannot open a 4.1 file, so back up brickwork.db before you upgrade. To go back, restore that backup (Back up and restore).

• Schema 4.1. A wish has a maximum price with box (#131). On a wish's page, Edit has Max price with box and its currency beside Your max price. The price card's footer shows Your max price and Max with box, each a button to its field, or not set. Only a set wish has one. In the API, a set's price with box is compared with the max with box, or with your max price when that is empty: the Wish has max_price_boxed, max_price_boxed_currency and under_max_boxed. A 4.0 collection is upgraded in place when the app starts (or at the first write); a read-only instance (BW_READ_ONLY) or a read-only open refuses a 4.0 file until it has been opened read-write once. Undo of a change made before the upgrade still works. Every wish's ETag changes once at the upgrade, so an API client re-reads a wish before its next edit. The wish card keeps the set's estimate beside the two maxima, and the wishlist CSV export has two new columns, Max with box and its currency, before Note. A stale 4.0 file (made before #124) is refused before the upgrade writes anything, and an upgrade that cannot finish says to open the file again, never to migrate it. The BrickLink wanted list has no such field, so the XML export and import leave it out. See Collection model.
• First run says how long loading the catalogue takes: about a minute. Measured on a Raspberry Pi 5 from an empty data folder: 51 s, most of it building the catalogue (#126).
• Faster (#133, #134), measured on a benchmark collection: the jump search by a number 204–262 ms → 29 ms, the item page 185 → 79 ms, the wish page 149 → 58 ms, the Matcher 164 → 71 ms, and app start about 1,000 → 660 ms. A test fixes the outputs of these paths, so the speed-ups change no result.
• Set estimate no longer looks like a link when it does nothing: without edit rights the footer label is plain text (#131).

Brick Work 0.6.0

The data-model release: the collection moves to schema 4.0 with a separate local catalogue, and the API to v2. Breaking: API v1 answers 410 except /api/v1/health; clients move to /api/v2 (API v2). A 0.5 collection is moved with brickwork migrate4 on a copy first (CLI); the 3.3 file is never changed.

• Add says what each step does: numbered steps (Find and select, Review and add, Added), Select instead of Add to list on a search result (tap again to unselect), a bar that keeps Review in view, and an Add button that names where the items go. An item you already own or wish waits for Add another copy or Skip before Add is offered; before, Add was offered and the save failed. The wishlist options show only for the wishlist, and the item types wrap on a phone.
• The site's API reference shows API v2 (#125).
• An order keeps its currency when its document has no total (M.12, #114). An order e-mail has only line prices, so its order now stores EUR and the line prices show it instead of Currency not recorded; a total still needs its currency. Orders stored before get the currency from their raw document when the app starts. See Receive an order.
• brickwork check and the Database page check that the two files belong together (M.12, #114): the collection is bound to the catalogue, every catalogue item and colour in the collection has the same born key there, every part list it names exists, and the digests agree. Each is a named check; a failure names the fix. API v2 /database/check is unchanged. See Back up and restore.
• First run needs no key (M.12, #114). Sets on an empty install offers Download the catalogue (or Build from today's files when today's download is on disk, or Activate the catalogue for a file that is there but not switched on): one background job fetches Rebrickable's files, builds the catalogue, creates and seeds the collection file if it is missing, and activates and binds the catalogue. Add by number and Check Set Parts then work with no key. Keys became an optional step. See Settings and maintenance.
• Part lists on the copy page and in Add (M.10 A). The Part list card names the list a copy uses and offers Switch with what changes and which marks will not carry over; a copy can ask for BrickLink's list and waits on the fetch (Cancel stops it); a copy built before a re-download says what changed; retired lines are kept in a collapsed note; a figure line names where its parts came from. The Add review has a Part list picker (with Use this for new copies of this set), warns about a part with no known picture, and offers Fetch from Rebrickable or Add as unidentified for a number not in the catalogue. A missing picture is a quiet dashed tile in light and dark. See Choose and switch a part list.
• main is the 4.0 line: the app runs on the 4.0 store; API v1 answers 410 (except /api/v1/health) until API v2 (M.11).
• The collection lists, the item page, the wish, lot and purchase-place pages and the jump search run on the 4.0 store. An item page is /collection/item/<id>; the old number URLs redirect to it. Screens show the Rebrickable number first with the BrickLink number beside it where it differs, a BrickLink-only item marked, and an unidentified item by its name; search takes both numbers. Conditions and completeness are words on every screen.
• Check Set Parts and the collection's writes run on the 4.0 store: a check keeps its answers by part line, so switching a copy to another part list keeps a check in progress; checks in progress before 4.0 start again. Editing, archiving, restoring and Undo (one receipt per save), own photos and captions, new part lots and the loose-stock merge on edit work as before. A figure's own parts are checked at /workbench/check-parts/<copy>/figure/<line>. Own photos are served at /manage/images/<id>.
• The Workbench runs on the 4.0 store: Part Picker, Matcher (Give and Take), Found it, instruction booklets, Part to Inventory (the page, its save and Undo), Storage with its history, and the printable lists with their CSV. A move writes one receipt and a stock_transfer row naming it. Matching is by item: a part, a figure, or a set's booklet or box meets the loose stock of the same item and colour, and an item still marked to check is matched like any other (the Needs a check list is gone). Instruction booklets are added by the numbers of booklets you already hold or the BrickLink item list names. Photo recognition in Part to Inventory comes back with Identify.
• Pictures, prices and keys run on the 4.0 store. The import job fetches a picture (from the Rebrickable catalogue, BrickLink and the Rebrickable API, in the order of the setting; parts try the catalogue first), Brickset metadata and retail price, and BrickLink prices for every colour a part is held in; calls are counted per source and day. An item with no BrickLink number ends the price step as unidentified instead of failing. The Prices screen works by item id and its Update buttons queue the same step. Fetch from Rebrickable now makes the copies (or the wish) the Add row asked for when the job is done, with its own Undo, and says so on the Add page. Updating from 3.3 turns the default picture order into the new default and splits a changed one into the catalogue and the API. See Pictures, prices and where they come from.
• Planning, wishlists and money run on the 4.0 store. Complete sets ranks the copies with a gap by what a repair gains per unit spent, from the cached BrickLink quotes and the repair settings; a pin and the settings are saved and undone as events. Its Export names every line by BrickLink number and colour; an item BrickLink has no number for is left out of the file and named in the message instead of stopping the export. The Wishlist screen, the named lists (create, move, copy, archive, restore, Undo) and the BrickLink XML and Rebrickable CSV exports work by item id; a wish that cannot be named in the chosen format is left out and listed in the export summary. A wish id is now a uuid. Part-out value, retail on the wishlist, wish progress, exchange rates (a rate or the ECB's, converted figures marked ≈) and manual prices (Undo voids the observation) work as before.
• Orders and Identify run on the 4.0 store. An order document (BrickLink XML, the store's e-mail, the BrickLink API) is placed line by line on items through the BrickLink type, number and colour number, looking in your collection's links and the catalogue together; a key that names several items is never guessed: the line stays unmatched, offers its candidates under Could be, and you choose. Review, counting, allocation to a copy's gap or to loose stock, hold, reconcile, the short list and the CSV export work as before; every save is one event with Undo, and an undone import keeps its document and lines as provenance. A total comes with its currency, and a currency can stand without a total (the e-mail's EUR; M.12). A set line cannot be allocated to loose stock (add the set as a copy). What is this? and Part to Inventory recognise a photo through Brickognize and list a number that names several items apart instead of choosing one. Manage → Add takes a photo again: it offers the matches, adds nothing until you choose one, and keeps the photo only with Keep photo.
• Tools & Admin runs on the 4.0 store: Settings (currencies, retail country, the source order, freshness rules; a save is one event with Undo), Catalogues & keys (sources with their budgets, write-only key cards, and a Catalogue card that says what is loaded and names the command when the catalogue is missing or not activated), Values, Jobs, Bulk refresh prices, Statistics, Database (the check keeps its result as maintenance:database_check; the export is the collection file), Instruction files (a PDF belongs to a set; a booklet shows the files of the set with its number), Identify history and API tokens. A new collection starts with the freshness rules of 0.5. The catalogue is built on the server with python -m brickwork.store4, not from the browser; the app's catalogue command is the same operation. brickwork migrate4 is python -m brickwork.store4 migrate; the brickwork wishlist commands take wish ids as text. The BrickLink catalogue XML loader and the colour load are gone with the catalogue builds.
• Unresolved items (identity admin) runs on the 4.0 store: the list holds the local items that may be a catalogue item, the links and statuses to check and the items with no number, and each row offers its decisions (merge, confirm or reject a link, link a BrickLink number, keep as unmatched, move to another kind), each with Undo. A merge moves every reference of a local item onto the catalogue item in one step and unmerge puts all of it back exactly. See Resolve unresolved items and merge items.
• Collection sync and Import from BrickTracker run on the 4.0 store (M.8j). A pull places each item by its kind (a set as copies through the part-list preselection, other kinds as loose stock) with one receipt and Undo; a send names an item by its Rebrickable or BrickLink number and lists an item with no number as not on the site; the link is carried by the migration and the first sync compares everything. The BrickTracker import is rewritten on Rebrickable numbers: copies through Add's path with BrickTracker's marks on the part lines, loose parts and figures as stock, lots, wishes and flags, one receipt, one Undo. brickwork migrate and the "Build a new database instead" form are removed...

Brick Work 0.5.0

The first public release: a self-hosted web app for a brick collection that helps at the table, not only in the inventory. It is pre-1.0; the schema and the API can still change between minor versions.

• Collection: sets, minifigures, parts, instructions and boxes, with copies, storage, purchase details, statuses, tags and notes, in one SQLite file. Every list is searchable, filterable and sortable.
• Check Set Parts: count a copy's parts at the table, in inventory, colour or largest-first order, with a missing pass, Undo and resume.
• Part Picker: choose unfinished sets and get the parts you can pull from your sorted loose stock; Complete sets shows which sets that stock can finish.
• Matcher, Part to Inventory and What is this?: match loose stock to the sets that need it, and identify parts and minifigures from a photo (Brickognize) with what you already own of them.
• Orders: import a BrickLink order, an email or an XML file, count what arrived and allocate it to sets or loose stock.
• Planning: wishlists with a maximum price per wish, named lists and BrickLink XML or Rebrickable CSV export; prices from BrickLink, Rebrickable and Brickset with your own keys, including a part-out value.
• Storage, printable lists, statistics and an installable web app with light and dark themes.
• For scripts and assistants: a versioned REST API with scoped tokens and an Undo link on every change, an admin CLI and an MCP server.
• Import an existing collection from an older tracker database, read-only.
• Self-hosted with Docker Compose. No telemetry and no account with this project; no catalogue data or images are bundled, each install uses its owner's keys.

Source and compose files only; there is no container image for this release. Install: see the README.

The full list of changes is in CHANGELOG.md.