KazumiRules: five API levels decide what a parser rule can do

Five API levels decide what a rule may ask the client to do

KazumiRules is not an application and holds nothing a reader can launch. What sits at its root is one JSON file per site, a generated index, and a table that ties every rule to a number. That number is the API level, and it runs from 1 to 5, with level 1 asking for Kazumi >= 1.0.0 and level 5 asking for Kazumi >= 1.9.3. A rule is gated twice, once by the client build the user runs and once by the level its author declared. The gates open unevenly, since level 2 already asks for Kazumi >= 1.3.0 and level 3 for >= 1.3.6, so three capabilities arrive within the first two upgrades and then nothing changes until level 5 at >= 1.9.3. A rule written at level 1 still parses on a newer client, but it cannot request anything beyond the first column of the table, so older rules keep older behaviour instead of breaking outright. The arrangement costs something when a rule stops matching its site, because the failure can come from the site, from the parser, or from a gate the author never cleared, and nothing in the repository separates the three cases. Nor does the table say what a client does with a level it does not know, so a rule written for a build ahead of the user's is left undefined territory.

Level 3 hands out Referer and the legacy parser in one step

POST queries arrive at level 2, where a rule may send search requests as POST instead of GET, and the project points at mandao.json as the worked example of that path. Level 3 is where the table changes shape: Referer support switches on and a legacy parser appears in the same row, built on an iframe src-based approach that the feature note says can outperform the common JavaScript hook-based parser in certain scenarios, with xfdm.json named as a case where it helps. Because the two land together, a rule that wants nothing but a Referer also inherits a second parsing strategy it never asked for. Level 4 then adds no new column at all, repeating level 3 exactly, which makes the numbering a marker of client capability rather than a menu of independent switches a rule author can pick from.

HLS ad filtering waits for Kazumi 1.9.3

HLS ad filtering is the only capability tied to the top of the ladder. At level 5, which asks for Kazumi >= 1.9.3, a manifest can have its advertisement segments filtered before playback, cutting ad segments out without touching the main content delivery. Every level below it, including level 4 at >= 1.6.8, keeps POST queries, Referer support and the legacy parser while leaving ad segments in the manifest exactly as the site published them. That is a behavioural gap rather than a cosmetic one, because the same playlist reaches every user of a site and only the declared level decides whether the client trims it. No note in the repository ties the gate to a date or a breaking change, so the version requirement in the table is the only thing a rule author can check before choosing a level. The footnotes in that table mark only two of the four columns, with Post Support carrying an asterisk and Legacy Parser Support a dagger, so HLS ad filtering arrives without a note explaining what it filters or how a manifest is judged.

The Available Rules table covers less than the root listing

The table headed Available Rules carries 17 rows, each with a name, a rule version and a date, and its span runs from AGE at 1.5 dated 2025-09-17 to LMM at 2.2 dated 2026-09-15. The repository root tells a longer story than that. Beside index.json, README.md and a .github/ directory sit files the table never names, among them 233dm.json, 80tv.json, MT.json and WYDM.json, and the visible listing stops at mitang.json in the middle of the alphabet, so nothing here claims to be complete. Four rows, printed as the table carries them:

| AGE | 1.5 | 2025-09-17 |
| giriGiriLove | 2.4 | 2026-08-09 |
| LMM | 2.2 | 2026-09-15 |
| mgnacg | 1.0 | 2026-06-08 |

Because contributors are told not to edit README.md by hand, a missing or stale row is not something an ordinary pull request can put right.

One file type is accepted and two files are off limits

There is no install step here and no command to copy, because a rule corpus is data rather than a program. The repository carries no homepage and offers no download link for a client; what it offers is the pull request path, and it draws that boundary in three lines:

> Only submit or update rule files (*.json)
> DO NOT manually modify `index.json` or `README.md`
> These files will be automatically updated after your PR is merged

A first real contribution therefore means adding or correcting one JSON rule file for a named site and leaving the generated pair alone. The description invites contributions, yet the accepted surface is a single file type, so there is nowhere in the repository to record why a rule stopped matching or how a site behaves. No template rule, no schema document and no sample payload appears in the visible root listing either. Before writing the first rule, settle the three things the repository leaves undocumented: the schema a rule file must follow, the process that rebuilds index.json, and where the client reads that index from.

Two version numbers live in the same repository

Kazumi versions run 1.0.0, 1.3.0, 1.3.6, 1.6.8 and 1.9.3, and they gate the API levels. Rule versions in the table run 1.0, 1.2, 1.4, 1.5, 2.2, 2.3 and 2.4, and they move on their own schedule, since a rule sitting at 1.0 dated 2026-01-28 says nothing about which client build can read it. Folding the two columns into one number is the easiest mistake to make here, because the only place they meet is the level a rule declares. File naming is uneven as well: AGE.json, DM84.json, LMM.json and MXdm.json sit beside lowercase names such as aafun.json and gugu3.json, and the legacy parser note points at xfdm.json while the table tracks xfdmneo at 1.1 dated 2026-03-08. Whether both files exist cannot be settled here, since the root listing on show stops before the x names begin.

A Dart primary language on a repository that only accepts JSON

The project records Dart as its primary language, and no Dart file appears in the visible root listing. What that root does show is a wall of rule files, index.json, README.md and a .github/ directory. Read the two signals together and the picture resolves: this repository holds configuration for the Kazumi client, which lives elsewhere, and the Dart signal describes the project being served rather than what is stored here. Nothing in the tree offers a way to validate a rule before it is merged, with no schema file, no test directory and no fixtures at the top level. The repository is MIT licensed, its last push landed on 2026-09-17, and it has published no GitHub releases at all, so there is no version history to consult when a rule regresses and no documented way back to the previous text of a file.

Where a hosted rule corpus stops being the right tool

The corpus earns its place for a contributor with one specific site in mind and a client new enough to read the level that rule declares. It stops fitting in three cases. A rule at level 5 does nothing useful on a client older than 1.9.3. A maintainer who wants rules reviewed before they reach users finds no review trail, since the repository documents no validation step and no way to roll a bad rule back. An offline or audited setup is served worse still, because every parse depends on fetching a hosted file that can change without notice. The real alternative is to compile rules into the client rather than host them, and the difference is concrete: a built-in set cannot drift from the binary that reads it, but every site fix waits for a new app version, while a hosted corpus fixes rules without an app version and pays for that convenience with network reads and the exact drift the API level was built to manage.

Editorial conclusion

KazumiRules is a rules corpus to audit rather than a library to adopt. Contributors who can read a level table and leave the two generated files alone will get a pull request merged; users expecting turnkey support will not, because the repository ships no install path and no documented rule schema. Before trusting any rule here, match its API level against the Kazumi version you run and check whether the file appears in the Available Rules table at all, since that table covers only part of the root listing.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Predidit/KazumiRules on GitHub
4. README