tigertag 1.0.6 → 1.2.0

package/CHANGELOG.md

@@ -3,6 +3,193 @@
 All notable changes to this project will be documented in this file.
 Format based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 
+## [1.2.0] — 2026-09-30
+
+### Added
+- **Unified playground**: `tools/playground.html` is now one page, byte-for-byte identical in the
+  JavaScript and Python SDKs. Each `tools/server.*` implements the same server contract
+  (`docs/playground-api.md`): `GET /api/version` (now `{ version, sdk, label, repo, install,
+  server, style }` — the page takes its SDK names, links and the `create()` code style from it),
+  `POST /api/parse` / `/api/build` (snake_case `create()` fields, `measure_available`) /
+  `/api/diff`, `GET /api/catalog/info` / `<id>`, `POST /api/catalog/refresh`, `GET /api/db/info`,
+  `POST /api/db/update`, `GET /api/db/table/<file>`, `GET /api/nfc/events` (Server-Sent Events,
+  chips already present replayed on connect), `POST /api/nfc/read` / `burn` / `plan`. The page
+  talks to the readers through SSE + HTTP on both servers (the JS server keeps its WebSocket transport for older pages; `TIGERTAG_PLAYGROUND_NO_NFC=1` starts it without readers).
+  `scripts/check_playground_sync.js` fails when the two copies differ (the local checkout next to
+  this one, else GitHub `main`); the test suite runs it and skips it when neither is reachable.
+  From the other SDK's page: gradient colour preview, read-only manufacturing date, refusal of an available quantity above the initial one, Studio Manager download buttons, error toasts, tables loaded from the server (`/api/db/table`).
+- **Tag index / tag count** (protocol v2.2). Page 0x0D byte 3 (payload offset +39),
+  previously reserved padding, is now parsed and written as `tagInfo` (u8):
+  high nibble = tag index, which of the item's TigerTags this one is, from 1 (0 = unknown);
+  low nibble = tag count, how many TigerTags the item carries — a filament spool, a resin
+  bottle…, as given by idType (0 = unknown, 1 = single tag,
+  2 = twin tag, … 15). The hex reads "index/count": `0x11` single tag, `0x12` / `0x22`
+  twin tag, tag 1 / 2 of 2, `0x02` twin tag with index unknown, `0x00` unknown.
+  - `tag.tagInfo`, and read-only getters `tag.tagCount` / `tag.tagIndex`.
+  - `TigerTag.create({ tagCount, tagIndex })` (default `0` = unknown); `asInit()` writes `0x00`.
+    Values outside 0–15 throw `RangeError`.
+  - `patch()` accepts `tagInfo`, `tagCount` and `tagIndex`; `patchFromRawDict()` /
+    `fromRawDict()` accept `tag_info`.
+  - `validate()` warns when tag index / count are outside 0–15, when index > count (count > 0),
+    and when count is 1 with index > 1.
+  - `toRawDict()` gains `tag_info`; `toDict()` gains `tag_count` / `tag_index`
+    (`null` when unknown) next to `twin_tag_pairing_id`; `pretty()` prints a `Tag` line
+    (`Tag          1 of 2`) after `Twin tag ID`; `describe()` adds "Tag 1 of 2 on this filament."
+    when known (the idType label, lowercased; "item" when the type is unknown).
+  - `tagInfo` is not covered by the ECDSA signature — setting it never invalidates a signed tag.
+
+- Playground: "Tag index" / "Tag count" inputs (0–15, 0 = unknown) passed to
+  `TigerTag.create()` via `/api/build`; the client-side encoder / decoder handle byte +39;
+  the decoded view shows a `Tag` row after `Twin tag ID` ("1 of 2", "? of 2", "unknown");
+  the raw hex view labels page 13 byte 3 as the tag index / count (e.g. `(0x12) tag 1 of 2`);
+  imported `.bin` files and scanned chips fill the two inputs; presets and API loads reset them to 0.
+- Playground server: `/api/parse` and the `card:detected` WebSocket event include
+  `validate` (the `validate()` warnings), shown in a new "Validation" card.
+- Playground: an info bubble on "Tag index" and "Tag count" explains both values;
+  the repository list points to Tiger-Scale-V3 and adds TigerSpool-RFID, TigerPOD,
+  TigerSystem-Docs and TigerTag_Firebase_Integration.
+- Playground ecosystem panel: photo cards for Tiger Scale V3, TigerSpool, TigerPOD Mini
+  and the mobile app.
+- Playground: TigerTag favicon (`assets/favicon.svg`, with `assets/apple-touch-icon.png`).
+- Playground SDK Input panel: `create()` | `HEX` | `Pages` tabs. `HEX` shows exactly what
+  Burn writes (144 bytes, pages 0x04–0x27, uppercase); `Pages` lists them page by page in
+  write order with the Raw Read annotations (page 0x0D byte 3 → `tag 1 of 2`). Copy copies
+  the active tab (`Pages` → one TSV line per page). The "→ Burn result" section is kept.
+- Playground twin tag mode: when two or more readers hold a chip (sorted by name → #1, #2, …),
+  Tag count is locked to the number of chips and Tag index to "auto", with a note naming
+  each reader's tag ("#1 <reader> = tag 1 of 2"). Generate builds one payload per reader — same
+  data, same Timestamp (computed once in the page and passed to `create()`), tag index 1…n
+  (`0x12`, `0x22`) — and SDK Input shows
+  one section per reader. SDK Output gets `#1` / `#2` buttons to switch between the chips.
+  Burn asks for confirmation listing each reader, UID and tag, then writes each reader's own
+  payload; the "x/y written" counter and the burn result aggregate across the writes.
+  Loading a `.bin` or a scanned chip clears the twin plan.
+- Playground server: `burn:write` accepts an optional `reader` field (a reader id / name, or an
+  array of them) to write to those readers only; without it every reader holding a chip is
+  written, as before (`tools/burn_targets.js`).
+- Playground "Chips on the readers" card: for the chips currently on the readers, checks they
+  belong to the same item (same Timestamp), carry identical data apart from byte +39, and that
+  the tag numbering is complete (e.g. "Numbering complete: 1/2 + 2/2", "tag 2/2 not on a reader",
+  or "Tag index / count unknown" for tags written before protocol v2.2). The server replays the
+  last chip read on each reader to a newly connected page.
+
+- Playground Read / Burn modes: a header switch "Read" (default) | "Burn".
+  Read shows only what the readers read (or an imported `.bin`), under a blue "Read result"
+  banner naming the reader and UID (or the file), with the "Chips on the readers" card; Burn
+  is disabled and twin tag locking is off. Burn shows only what Burn will write, under an
+  orange "Burn preview — not written yet" banner listing the target readers (and each one's
+  tag i of n); a chip placed on a reader never replaces the preview, and Burn writes the
+  stored preview, never the last payload read. Generate switches to Burn, Import .bin to Read;
+  each mode keeps its last view. In Read mode, removing the chip whose result is shown switches
+  to another chip still on a reader, or clears the view (an imported `.bin` stays). Reader
+  events start only after the reference database has loaded.
+
+- Playground burn never writes a signature and never leaves a stale one: `burn:write` always
+  writes pages 0x04–0x27 (36 pages) — the tag data on 0x04–0x17, then `00 00 00 00` on every
+  signature page 0x18–0x27, whatever the payload (TigerTag, TigerTag+, or data read back from a
+  signed chip). Only a certified manufacturer can issue a signature, and a copied one would be
+  invalid since it covers the chip UID; the playgrounds only read signatures to verify them.
+  Pages 0–3 and 0x28+ are never touched. The page plan lives in `tools/burn_plan.js`
+  (unit-tested; accepts 80 or 144 bytes); `burn:result` reports `pagesWritten: 36` and
+  `signatureDropped` when the payload carried a signature. The playground sends the full
+  144-byte image, the HEX / Pages tabs show all 36 pages with the zeroed signature, and the
+  caption and confirmation say so ("the signature read from the chip is not copied" when the
+  data came from a signed chip).
+
+- No emoji anywhere: `SignatureResult` labels are plain words (`VALID`, `INVALID`, `NOT SIGNED`,
+  `NO PUBLIC KEY — …`, `NO UID — …`, `NO CRYPTO — …`), `pretty()` prints `signed (not verified)`
+  instead of a check mark, and the scripts print `OK` / `FAILED`. The playground uses small inline
+  SVG icons (read, burn, raw read, upload, download, play, check, x, warning, cloud, hourglass,
+  close, refresh, external link…) in buttons, banners, tabs, badges and cards, and plain words in
+  tooltips, confirmation dialogs and console logs. The README, llms.txt and the SVG badges no
+  longer use emoji either.
+
+- **TigerTag+ from the official catalogue** (`src/catalog.js`): `TigerTag.fromCatalog(productId,
+  { uid, tagCount, tagIndex, timestamp, db, catalog })` builds a ready-to-burn TigerTag+ from
+  `id_catalog.json` (14 000+ products); `TigerTag.fromCatalogEntry(entry, options)` does it from an
+  entry; `catalogEntry(productId)` returns the display metadata (title, brand, SKU, barcode, image).
+  RFID_Data mapping: `data1` = diameter, `data2`/`data3` = nozzle min/max, `data4`/`data5` = dry
+  temp/time, `data6`/`data7` = bed min/max, `id_aspect2` null → 0, colours 2/3 from `color_r2…b3`
+  or `color_info.colors`. The catalogue (~12 MB) is not bundled: `loadCatalog({ url, cacheDir,
+  maxAge, force })` downloads it on first use and caches it in the user cache folder (override:
+  `TIGERTAG_CACHE_DIR`), checks for a new version once the copy is older than 1 day (`maxAge`), falls back to the cached copy when offline and fails with a clear error
+  when there is none. It changes every day: `refreshCatalog()` checks for a new version now
+  (conditional download with ETag / Last-Modified — an unchanged catalogue answers 304) and
+  `catalogInfo()` reports `downloaded`, `count`, `fetchedAt`, `checkedAt`, `url` and `etag`.
+- Playground: one "Load a TigerTag+ product" block — a single Product ID field, a source toggle
+  "Offline · Catalogue" (bundled / cached catalogue, no internet) | "Online · API" (live
+  api.tigertag.io data), remembered in the browser, and one Load button; both sources fill the
+  form, switch to Burn and build the preview (twin tag with two readers), share one message area
+  and suggest the other source when a product is not found / the API is unreachable.
+- Playground: decluttered — on screen only short labels, values, buttons and status words
+  ("Catalogue · 14 164 · 1 oct.", "Tables · 25 sept.", "Burn preview · not written · twin tag ·
+  2 chips"); every explanation moved into info bubbles (TigerTag+ intro, data sources, catalogue
+  and tables details, Read / Burn banners, HEX / Pages captions, "Chips on the readers" checks,
+  field hints, twin tag readers, Init, demo presets). Bubbles are placed to stay inside their
+  panel and the viewport.
+- Playground: "Load from catalogue" in the TigerTag+ tab — a product ID fills the whole form from
+  the catalogue, shows title, brand, SKU and image, switches to Burn and builds the preview (twin
+  tag with two readers); "Update catalogue" downloads the latest version; a status line shows
+  "Catalogue: 14 164 products · updated <date>" or "not downloaded yet". Server endpoints
+  `GET /api/catalog/<id>`, `GET /api/catalog/info`, `POST /api/catalog/refresh`.
+
+### Fixed
+- Playground: Generate now passes an explicit Timestamp to `create()`, so the decoded view
+  shows the real Twin tag ID and manufacturing date instead of `null` / 2000-01-01.
+- Playground: the `create()` call shown in SDK Input is the exact call sent to `/api/build`
+  (inactive color 2 / 3 slots are no longer sent while hidden from the displayed call), so
+  the text shown always reproduces the bytes.
+
+- **Reference data always available offline, kept fresh automatically**: the product catalogue
+  ships in the package as `database/id_catalog.json.gz` (~1 MB, gunzipped at load; package
+  1.1 MB) next to the 7 tables. `TigerTagDB` picks, per table, the newest of the downloaded copy
+  in the data dir (`dataDir`, `TIGERTAG_DATA_DIR`, default: the per-user cache folder shared
+  with the catalogue) and the bundled copy. `await TigerTagDB.open()` / the constructor's
+  background check (`db.ready`) look for new tables at most once a day (one request to the
+  TigerTag API, GitHub mirror as fallback, only the changed tables downloaded, ~5 s timeout,
+  never throws). `offline: true` / `TIGERTAG_OFFLINE=1` / CLI `--offline` mean zero network
+  calls; `autoUpdate: false` disables only the automatic check (`autoSync` is a deprecated
+  alias). `await db.update({ force, catalog })` forces it and returns the changed files;
+  `db.info()` reports where every table comes from (custom / downloaded / bundled), the last
+  check, the data dir, the offline flag and the catalogue. CLI: `tigertag update [--force]
+  [--catalog] [--data-dir PATH | --db PATH]`. The catalogue loader shares the data dir, the
+  offline switch and the bundled `.gz` fallback, so `TigerTag.fromCatalog()` works offline.
+- Playground: "Update reference tables" button with a status line ("Reference tables: 7 (n
+  downloaded, n bundled) · data <date> · checked <date>"), server endpoints `GET /api/db/info`
+  and `POST /api/db/update`; the catalogue status line names the bundled copy.
+- Playground: Read mode shows no SDK Input panel and Burn mode no SDK Output panel at all (not
+  even the fold rail) — three columns instead of four; switching mode opens the visible panel.
+- Release pipeline: `scripts/sync_databases.js` also refreshes `database/id_catalog.json.gz`
+  (only when its content changed); the daily `sync-databases.yml` commits it and `publish.yml`
+  runs the sync (then the tests) before `npm publish`, so every release ships the day's data.
+
+### Changed
+- Protocol version is now **TigerTag Open Source v2.2** (backward compatible: tags written
+  before v2.2 read `0x00` = unknown).
+- `toBytes()` writes `tagInfo` at +39 instead of a hard-coded `0x00`.
+- **Behaviour change**: a custom `dbPath` is used exclusively — a missing table file now throws
+  a clear error instead of silently falling back to the bundled copy; `new TigerTagDB()` now
+  checks for updates once a day in the background (into the data dir — never into the package
+  folder; disable with `autoUpdate: false` or `offline: true`); `db.sync()` is an alias of
+  `db.update()`, and `tag.syncDb()` / `tigertag --sync-only` without a folder update the data dir
+  instead of rewriting the bundled `database/` folder.
+
+## [1.1.0] — 2026-07-10
+
+### Changed
+- **License changed from GPLv3 to Apache-2.0.** The TigerTag protocol
+  specification is now published as an open standard: CC-BY-4.0 for the
+  specification, CC0-1.0 for the reference database, Apache-2.0 for code, with an
+  irrevocable, worldwide, royalty-free right to implement it in any product, open
+  source or proprietary. Apache-2.0 carries an express patent grant.
+  See <https://github.com/TigerTag-Project/TigerTag-RFID-Guide/blob/main/LICENSING.md>.
+
+### Fixed
+- `package-lock.json` was left at `1.0.1` while `package.json` declared `1.0.6`.
+
+> Versions published to npm up to and including `1.0.6` remain under GPLv3.
+> This change applies from `1.1.0` onward.
+
 ## [1.0.6] — 2026-05-22
 
 ### Fixed
@@ -57,7 +244,7 @@ Format based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 - Playground: **Available qty auto-link** — the Available Qty field automatically mirrors Initial
   Qty until the user manually edits it. Link is restored on preset load, API fetch, or NFC scan.
   Removes the old "(0 = same as initial)" convention.
-- Playground: **Raw Hex Reader** (`🔬 Raw Read` button) — reads all 144 bytes (pages 4–39) from
+- Playground: **Raw Hex Reader** (`Raw Read` button) — reads all 144 bytes (pages 4–39) from
   every connected reader that holds a card and displays them in a structured table: page number,
   byte offset, four individual hex bytes (B0–B3), big-endian u32 decimal, and field label. The
   signature pages (24–39) are visually dimmed and preceded by a separator row.
@@ -66,7 +253,7 @@ Format based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
     displayed side-by-side (flex row). Panels use the same rail UX as SDK Input / Output.
   - **Copy hex** button per panel — copies one line per page (`0x04 B0 B1 B2 B3`) to the clipboard.
     Includes page hex prefix on each line for direct cross-reference with NFC documentation.
-    Button shows `✓ Copied!` (green, 1.5 s) after a successful copy so the user gets clear feedback.
+    Button shows `Copied` (green, 1.5 s) after a successful copy so the user gets clear feedback.
   - **Annotated Field column** — each field cell now shows decoded values inline:
     `(value) field_name · (value) field_name · …`. Values are read directly from the raw bytes
     (no extra server round-trip). customMessage pages show the decoded ASCII chars `("azer")`.
@@ -105,7 +292,7 @@ Format based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
   Works for TigerTag+ chips only (filament / resin types). Cache-busted with
   `v=<timestamp>` on each call. `toRawDict()` and `toDict()` now include an
   `img` field exposing all URLs.
-- Playground: **Burn** button (`🔥 Burn`) — writes the generated payload to every
+- Playground: **Burn** button (`Burn`) — writes the generated payload to every
   connected ACR122U / PC-SC reader that currently holds a card. Writes 20 pages
   (pages 4–23, 80 bytes) sequentially via `reader.write()`. Result reported per
   reader via WS (`burn:result`) with success/error detail; `burn:done` signals

package/LICENSE

@@ -0,0 +1,202 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright 2025-2026 TigerTag Corp.
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+