Update Tags

Update Tags

Overview

Two layers, one direction of truth:

• Source (input) — .claude/.dev/problem_lists/*.py. Each defines tag_name + problems_list of (problem_number, "Title") tuples. These are the canonical membership lists. __init__.py exposes them via available_lists.
• Output (sink) — src/leetcode_py/cli/resources/leetcode/json/tags.json5. JSON5 with comments. Lists problem-name strings per tag, plus sub-tag references like { tag: "neetcode-150" }. Consumed by the CLI at runtime.

update_tags.py diffs the two and prints discrepancies. It never edits files — a human resolves each line at the correct layer.

The Core Decision (read before touching anything)

The script prints two kinds of lines. They have different fix locations:

Iron rule: Missing → edit tags.json5. Removed → check the problem's _tags.list first — fix source if membership confirmed, else delete from tags.json5. Never guess the direction. For batch-created problems, confirm with source-list membership by problem number (see circularity gotcha below).

The "Removed" Trap (where data gets lost)

A "Removed" line means tags.json5 lists a problem the source list doesn't. Do not reflexively add a tuple to source — a "Removed" line is two opposite cases, and you must decide which before touching anything:

Decide via the problem's own metadata. Read src/leetcode_py/cli/resources/leetcode/json/problems/<name>.json → the _tags.list array is the problem's self-declared roadmap membership. It is a stronger signal than the tags.json5 entry you're auditing — a problem knows which roadmaps claim it.

• flagged tag ∈ _tags.list → the problem considers itself a member; the source list just hasn't caught up. Add the tuple to source.
• flagged tag ∉ _tags.list → the tags.json5 entry was likely added by mistake. Do not propagate it to source. Confirm with the user, then delete the entry from that tag's array in tags.json5.

GOTCHA — _tags.list is circular for batch-created problems. The _tags.list field is written at creation time by whoever created the problem. If the stamp was wrong there, this check "confirms" the wrong membership and directs you to pollute the source list — which permanently cements the mistake (a later sync commit did exactly this and bogus tuples had to be reverted by hand). For problems created via the batch/problem-creation flow, ground truth is source-list membership by problem number, not _tags.list: grep (number, across .claude/.dev/problem_lists/*.py. Number present in that list's file → member; absent → not a member, regardless of what _tags.list claims. If the number is in NO source file except neetcode.py (the 943 all-queue), the problem is queue-only: _tags.list should be ["neetcode"] and the tags.json5 roadmap entries are the bug.

The script deliberately refuses to auto-delete ("not included in update") so a human makes this call. Both wrong directions are permanent: deleting a real entry hides it (source lacks it, so Missing never fires to restore); adding a bogus tuple to source cements a mistake the script can no longer flag. The _tags.list check is what tells you which direction is safe.

To get the number + exact title: same JSON → problem_number + problem_title (proper-cased, e.g. "Last Stone Weight II"). Note problem_name is the snake_case slug — do NOT use it as the title. Match the casing already used in that source file.

Inheritance Asymmetry (expect false positives)

tags.json5 inherits — { tag: "neetcode-150" } inside neetcode-250 recursively pulls in all of neetcode-150. Source lists do not inherit (neetcode_250.py does not auto-include neetcode_150.py).

Consequence: a "Removed" line on an inheriting tag (e.g. neetcode-250) is frequently a false positive — the problem enters existing only via the inherited sub-tag reference, and the source-side set has no matching inheritance. Example tell: a problem flagged "Removed" for neetcode-150 but not for neetcode-250 means its tuple is in neetcode_250.py but missing from neetcode_150.py.

Fix is still source-side: add the tuple to the source list(s) that should contain it. If the same problem is "Removed" across multiple tags, add the tuple to each relevant source file.