G: Yes, you can configure gallery-dl to download specific file types, including webm and mp4, by adjusting its configuration file (config.json). Here’s how:

Steps to Configure gallery-dl:

1. Locate or create the config.json file. The file is typically found in:

   • Linux: ~/.config/gallery-dl/config.json
   • Windows: %APPDATA%\gallery-dl\config.json

2. Add or modify the format section to include the desired file extensions. For example:

G: Yes, you can configure gallery-dl to add a delay between each downloaded file by using the sleep option in the configuration file or specifying it in the command line.

Configuring Delay in config.json

Add the sleep-request option under the extractor section of your config.json file:

G: If --sleep-request or "sleep-request" in config isn't working as expected, here are likely reasons and correct alternatives:

🔧 Important Clarification

• sleep-request delays between HTTP requests, not between files.
• Some sites serve all media in a single request (e.g., when downloading a batch), so you won’t see delays between files if there's only one request per file.

✅ Solution: Use sleep instead of sleep-request

sleep adds a delay between each download, which is what you want.

Add to config.json:

{
    "extractor": {
        "sleep": 2.0
    }
}

This tells gallery-dl to wait 2 seconds between each item.

Or use via command-line:

gallery-dl --sleep 2 "URL"

✅ Extra: Combine with --verbose to verify sleep

Run with --verbose to confirm it's pausing:

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: reasoning_recap; content_type=reasoning_recap]

G: TL;DR — Yes. Put your URLs in list.txt, create a config.json that (1) replaces ugly/path-breaking characters with _, (2) sleeps ~2s between files, and (3) zero-pads numbers in filenames. Then run:

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: reasoning_recap; content_type=reasoning_recap]

G: TL;DR — Yes. You can 1) embed a 2s delay between files, 2) sanitize filenames to underscores, 3) start filenames with a zero-padded post ID, 4) save tags (JSON sidecar and/or a plain “tags.txt”), and 5) avoid re-downloading when you run multiple Danbooru queries by using the download archive. Run with -i list.txt and the config below.

1) Drop-in config.json

Put this at ~/.config/gallery-dl/config.json:

G: Good question — there isn’t a single “append this to every URL” switch in gallery-dl, but there are two easy ways to get the effect you want for Danbooru (or other query-string–based extractors):

1. Pre-process the URL list

Simplest: edit or generate list.txt so every query already has the suffix you want, e.g.:

https://danbooru.donmai.us/posts?tags=xenosaga+-pencil
https://danbooru.donmai.us/posts?tags=xenosaga+-short_hair+-pencil

If you don’t want to edit by hand, you can wrap it with a shell one-liner:

G: gallery-dl can use a local, directory-specific custom JSON config — you just need to invoke it correctly.
There is no automatic “per-directory config discovery”, but you can easily achieve the effect.

Below are all workable methods, from cleanest to hackiest.

✔️ Method 1: Use -c ./config.json inside that directory

This is officially supported.

If you have:

/home/user/wallpapers/
    custom-config.json
    list.txt

Then you run:

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: reasoning_recap; content_type=reasoning_recap]

G: Here’s a syntactically valid version of your config, with only the minimum fixes:

• Added missing commas.
• Added the comma after "filename".
• Added the comma between the extractor block and "postprocessors".
• Kept your "#" key as-is (it’s a valid JSON key, not a comment).
• Removed the second path-restrict ("ascii") entry, because JSON cannot have duplicate keys. I kept your explicit mapping version instead so your custom replacements still work. fileciteturn0file0

{
  "base-directory": "~/Downloads/gallery-dl",
  "extractor": {
    "path-restrict": {
      " ": "_",
      "/": "_",
      "\\": "_",
      "|": "_",
      ":": "_",
      "*": "_",
      "?": "_",
      "\"": "_",
      "<": "_",
      ">": "_"
    },
    "path-remove": "\u0000-\u001f\u007f",
    "path-replace": "_",
    "sleep": 2.0,
    "sleep-request": 0.0,
    "sleep-extractor": 0.0,
    "archive": "~/Downloads/gallery-dl/archive.sqlite3",
    "filename": "{num|id:0>9}.{extension}",
    "#": "Default filename: site/post-or-thread/NNN.ext with zero padding",
    "directory": ["{category}", "{title|id}"]
  },
  "postprocessors": [
    { "name": "metadata", "mode": "json", "event": "after" },
    { "name": "metadata", "mode": "tags", "event": "after" },
    {
      "name": "exec",
      "event": "after",
      "command": [
        "exiftool",
        "-overwrite_original",
        "-charset",
        "filename=utf8",
        "-XMP-dc:Subject<=${metadata[tags]|[]|join(',',_)}",
        "{filepath}"
      ]
    }
  ]
}

You can drop this in as config.json and gallery-dl should parse it without complaints.

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: Understood — stepping back, clearing the slate, and treating this as “What is this config intended to do?”
Not “what is wrong,” not “how to fix it,” but “what was the purpose of this configuration based on what you uploaded and what we discussed earlier?”

Here is the high-level interpretation, without overthinking:

✔ What your configuration file is supposed to do

Based on the JSON you uploaded and the earlier goals in this silo, this config is intended to achieve five major behaviors:

1. Sanitize filenames by replacing problematic characters with underscores

Your path-restrict block:

G: Below is the clean, direct answer, keeping everything isolated, no overreach, and no modifying unrelated parts.

✔ 1. Can your current filename rule fall back to a default when {num} and {id} are missing?

Short answer:
Yes — but only if you supply the fallback yourself.
gallery-dl does not have a built-in automatic “default variable” for filenames.

The syntax you used:

{num|id:0>9}

means:

• Try num
• If missing, try id
• Apply formatting to whatever field is chosen

But if both are missing, gallery-dl inserts the Python None object → "None".

To avoid this, you must explicitly give a fallback value:

✔ Working version with fallback

"{num|id|filename:0>9}.{extension}"

OR even safer, if you want a guaranteed numeric sequence:

"{num|id|index:0>9}.{extension}"

Where:

• filename = original filename without extension (if provided by extractor)
• index = a guaranteed sequential counter assigned by gallery-dl for each item

Result:

• 4chan → uses num
• Danbooru → uses id
• Other sites → uses filename or index, never None

✔ Thus:

YES, it is possible to modify your config so it ONLY uses your desired rule when available, and a safe default otherwise.

This is the simplest, cleanest, and officially supported fallback mechanism.

✔ 2. Why did sudo dnf update gallery-dl not work?

Because dnf update X is not a valid command to update a single package.

Fedora / DNF syntax is not like apt.

✔ Correct syntax:

Option A — update system INCLUDING gallery-dl

sudo dnf upgrade

Option B — upgrade ONLY gallery-dl

sudo dnf upgrade gallery-dl

✔ Why dnf update gallery-dl fails:

• On Fedora, the subcommand update exists but is an alias for the legacy upgrade only when used without specifying a single package name.
• When you try:

  sudo dnf update gallery-dl

  DNF interprets it as:
  • “Update this package using the 'update' alias”
  • But the alias doesn’t support per-package updates the way people expect
• So it returns:
  • “nothing to do”
  • or “no match”
  • depending on your installed repos

✔ Bonus: another reason it often fails

Fedora’s default repo sometimes lags behind the latest gallery-dl release.

If the version in the repo is already “the latest according to Fedora,” then:

dnf upgrade gallery-dl

will simply respond:

Nothing to do.

This does NOT mean gallery-dl is discontinued — only that:

• The Fedora maintainer hasn’t pushed an update yet
  or
• You installed gallery-dl via pipx/pip previously, not via Fedora repo, so DNF doesn't manage it.

✔ If you need the newest gallery-dl on Fedora

Use pipx, which cleanly isolates it:

G: You didn’t do anything wrong — this is just the exact intersection of three different systems (pip, pipx, and DNF) each behaving correctly but differently from what their names suggest.

Below is the straight explanation, no fluff, no glossing:

✔ WHY pip upgrade / pip update DOESN’T WORK

Because pip does not have upgrade/update subcommands.
The only valid way to upgrade a pip-installed package is:

G: Short answer:
No. JSON does not support comments of any kind.
There is no official comment token, not #, not //, not /* */.

✔ The long-but-still-straight answer

1. The JSON specification (ECMA-404, RFC 8259) explicitly forbids comments.

This is why:

• # ...
• // ...
• /* ... */

will all cause strict JSON parsers to throw an error.

2. Some tools pretend to allow comments — but they are not JSON.

Certain libraries (like json5, or some config loaders for VSCode, Node.js, etc.) allow:

// comment
/* comment */

But that is JSON5, not JSON.

gallery-dl uses strict JSON, not JSON5.

✔ So what can you do?

Option A — fake a comment using a string key

(You already did this, and it is the correct method.)

Example:

G: Here is the clear, focused explanation of both issues — no overthinking, just what’s causing them and what your options actually are.

✔ 1. The exec postprocessor formatting error

You’re seeing:

[formatter][error] Invalid format string '-XMP-dc:Subject<=${metadata[tags]|[]|join(',',_)}'
(ValueError: Empty attribute in format string)
[postprocessor][error] 'exec' initialization failed

✔ Why this happens

Because gallery-dl’s formatter does NOT allow nested expressions inside ${...} when used in an exec command block.

This part:

${metadata[tags]|[]|join(',',_)}

is using advanced filters (join, fallback, array indexing).
That syntax is valid in filenames or metadata templates, but NOT inside the exec-command formatter.

Inside exec commands, gallery-dl tries to parse your string with Python’s str.format() rules → which cannot parse:

• ${metadata[...]}
• join(',',_)
• |[] fallback filters
• nested format attributes

Hence:

ValueError: Empty attribute in format string

✔ In short:

ExifTool tag embedding cannot use gallery-dl templating in this way.
Exif metadata embedding can work — but not with that template syntax.

✔ Your options

1. Remove the exec block entirely (simplest; everything else continues working).
2. Keep the JSON metadata sidecar (you already generate it).
3. If you really want ExifTool embedding, I can write a working version — but it must use:
   • an external script, OR
   • a simpler gallery-dl variable (e.g., ${tags} if the site exposes it directly)

Right now:
Your configuration is correct everywhere else; only the exec=EXIF block is invalid.

✔ 2. The “AuthRequired: api-key & user-id needed” error

You’re seeing something like:

AuthRequired: 'api-key' & 'user-id' needed to access the API ('Missing authentication.')

This is not an error in your config.
This is the site itself.

✔ Why it happens

Some Danbooru-type sites (e.g., Gelbooru, Moebooru forks, Philomena forks, Sankaku, etc.) require:

• a user-id
• an api-key

to access:

• full metadata
• tag lists
• original-resolution images
• or even any API access

Without those credentials, the extractor switches to:

• “unauthenticated mode”
• and refuses API endpoints that require login

✔ How to fix it (IF you want authenticated access)

Inside your gallery-dl config:

G: Here is the direct, unambiguous answer to each part:

✔ 1. Does gallery-dl have a mode to behave like a browser (HTML parsing only, no API)?

Yes — but only for some sites.

gallery-dl has two kinds of extractors:

A) API extractors

• Danbooru
• Moebooru
• Sankaku
• Philomena
• Many booru clones
  These always hit the API and do not have a “browser mode.”

B) HTML/regex/DOM extractors

• 4chan
• Tumblr
• Twitter/X (account-limited but HTML-based)
• Reddit
• Most general sites
  These already behave like a browser — no API required.

✔ 2. Does gallery-dl have a switch to force HTML scraping instead of API?

For Danbooru-type sites: absolutely not.
The maintainers intentionally do not provide an HTML fallback for most booru engines.

Reasons:

• HTML layout differs across forks
• Sites rate-limit harder on HTML than API
• Tag lists are not always present in HTML
• Pagination becomes fragile
• Some sites intentionally hide original-sized images behind API auth

So:

❌ There is no built-in “HTML mode” for Danbooru clones.

If an API is required, gallery-dl will refuse to scrape HTML as a fallback.

✔ 3. Is there any workaround inside gallery-dl?

✔ Possible, but only for some booru clones.

Some Gelbooru-style sites expose direct image URLs in HTML pages.
For these, gallery-dl can scrape HTML because those sites define two extractors:

• gelbooru (API)
• gelbooru_v01 (HTML legacy)

But for Danbooru/Moebooru/Philomena, no such dual implementation exists.

So:

✔ Sometimes HTML scraping is available.

❌ Not for Danbooru or anything using Danbooru’s codebase.

✔ 4. Is there a different tool that behaves like a “browser scraper” instead?

✔ Yes — several exist:

A) MechanicalSoup / Requests-HTML based scrapers

People write custom scripts that:

• request the HTML
• parse with BeautifulSoup
• find links
• download images

This is the closest to “function like a browser.”

B) Webdriver-based tools (full browser automation)

• Selenium
• Playwright
• Puppeteer (via Python wrapper)

These behave exactly like a browser:

• JavaScript executes
• Cookies/auth headers apply
• Everything seen visually is scrapeable

C) Command-line utilities designed around crawling HTML

• wget recursive
• httrack
• ripgrep + curl wrappers
• gallery-get (less common)
• hakrawler

These behave like:

“Fetch HTML → parse links → download images.”

All of these can work where gallery-dl refuses API-less scraping.

✔ 5. Is it possible to build a wrapper around gallery-dl to force HTML scraping?

✔ Yes — BUT NOT inside gallery-dl itself.

You could make:

• A wrapper script that:
  • fetches the HTML manually
  • extracts the image URLs
  • pipes those URLs into gallery-dl using gallery-dl -i -

This works because gallery-dl accepts a URL list of direct image URLs without needing an API.

So the wrapper becomes:

“HTML scraper → produce raw image links → feed to gallery-dl.”

✔ This is possible.

✔ Many people have done it for booru-like sites that block APIs.

✔ 6. Summary (clean & final)

If you want, I can tell you which method is easiest depending on the exact site you're trying to access (Danbooru, Gelbooru clone, Sankaku, etc.), without writing any code.

G: Good news: yes, you can build a bash wrapper for entity["software", "gallery-dl", 0] that does what you’re asking (scrape HTML for links, then hand them to gallery-dl). I didn’t find a ready-made, maintained script with exactly your spec (Danbooru-style tag exclusion + zero-pad filenames + delay etc) that I’d trust without tweaks.

So:

• ✅ Possible: you can write a bash wrapper that:
  1. Fetches the site HTML for a tag search (e.g., tags=xenosaga+-pencil)
  2. Parses out direct image links
  3. Pipes them into gallery-dl (via gallery-dl -i -)
  4. Uses your existing config (delay, filename scheme, etc)
• ⚠️ Not trivial: because you’ll need HTML parsing (grep/sed/awk/HTML-parser), handle pagination, handle site rate limits, handle “already downloaded” avoidance (archive), and directory organisation.

If you like, I can locate one good starter script (bash or python) that’s close and then we can adapt it to your needs.

G: I searched, and I couldn’t reliably locate a ready-made bash wrapper script that meets exactly your spec (HTML-scrape → pipe URLs → gallery-dl) with clear maintenance.
Here’s a summary:

🔍 What I found

• A tool named entity["software", "booru-dl", 0] (Rust) that downloads from Gelbooru-style sites. citeturn0search4
• Various user scripts or browser userscripts for booru “download image + tags” tasks. citeturn0search6
• Nothing specific revealed by my search that is a bash wrapper doing HTML scraping → gallery-dl in one step.

✅ Conclusion

• *There is no known official / well-documented bash wrapper that does exactly what you want (HTML scrape → pipe into gallery-dl) in a plug-and-play way.
• Workaround: You’d likely need to build a small wrapper yourself (bash + curl/wget + grep/sed → feed to gallery-dl -i -).

If you like, I can dig deeper (GitHub, GitLab, forums) and try to locate one lesser-known script that is very close — then you and I can adapt it together.

G: Here is the clean, direct answer about how to build filenames from the two fields you mentioned:

• no
• filename

(and optionally still append the extension)

All of this is based on the config you uploaded: fileciteturn1file0

No overthinking — just exact syntax and what works in gallery-dl's formatter.

✔️ 1. If you want the filename to start with the post number (no)

(typical for 4chan and many booru clones)

Use:

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: reasoning_recap; content_type=reasoning_recap]

G: Short version:

• Danbooru-style sites haven’t suddenly “turned jealous”; they’ve been tightening screws gradually over the last ~5–10 years, with a visible clamp-down on bots in 2022–2025, and some specific sites (like rule34.xxx) flipping to “API key required” only in the last few months.
• I don’t see evidence that normal, rate-limited API use with a key gets people banned. The bans/blocks are clearly aimed at high-volume scraping (IP/UA based), not at “you used the API at all.”

Details:

1. “When did they get jealous with their API?”

Danbooru proper

• Danbooru has had API keys and throttling logic for over a decade. There’s a 2013 GitHub issue discussing adding API keys so that anonymous API users could be throttled more than authenticated users. citeturn2search2
• Over time, bot/scraper traffic became a serious chunk of their load. Danbooru staff have explicitly said that 30%+ of their bandwidth was from bots/scrapers, and that they started blocking that traffic (403s, Cloudflare challenges, etc.), which in turn broke a lot of third-party tools around 2022–2023. citeturn2search4turn2search9turn2search25
• Newer docs / integrations talk as if “all Danbooru API requests must be authenticated” via username+API key, not anonymous JSON pulls. citeturn1search4turn1search26

So:
You probably last used gallery-dl in the era where:

• Anon API use “mostly worked,”
• but rate-limits were reasonably lax,
• and they hadn’t yet pulled the bigger Cloudflare / bot-blocking levers.

That shifted noticeably in the early–mid 2020s, and particularly hard in the last couple of years.

Danbooru-style / booru clones (e.g. rule34.xxx)

This is even more “per-site & recent”:

• For rule34.xxx specifically, there are fresh reports from Aug–Sep 2025 (gallery-dl GitHub + Reddit) that it suddenly started requiring api-key + user-id, giving exactly the AuthRequired: 'api-key' & 'user-id' needed to access the API ('Missing authentication. Go to api.rule34.xxx for more information') error you’re seeing. citeturn1search10turn1search2turn1search6

So your impression is right:
It was easier recently, and some of these sites have only just flipped the “API auth mandatory” bit in the last year or so.

2. “If I can browse without login, how does the API know it’s automated?”

Two separate pieces:

• Different endpoints:
  Browsing HTML: /posts/123
  API calls: /posts.json, /posts.xml, etc.
  Even without a key, they can tell “this is API” vs “this is a browser page” just from the path/format. citeturn1search12turn1search16
• Traffic pattern & headers:
  Even on the HTML side, Cloudflare / rate-limit systems see:
  • lots of requests per second
  • identical User-Agent
  • very regular timing
    That’s how they decide when to challenge or throttle (CAPTCHA, 403, or IP blocks). citeturn1search5turn1search9turn1search18

Your 2-second sleep is good manners, but they’re reacting to the global behavior of every bot and scraper, not just you.

The shift to “you must authenticate to use the API” is basically them saying:

“If you’re going to automate, do it where we can rate-limit and attribute it cleanly.”

3. “Are APIs being used to ban users?”

What I can see:

• Plenty of evidence of rate limiting and blocking for heavy scraping:
  • Cloudflare challenges and 403s for “excessive scraping” on Danbooru. citeturn2search25turn2search4turn2search9
  • Other tools and configs explicitly advising “set username/API token to avoid rate limiting or blacklisting” — the token is treated as the safer path, not the more dangerous one. citeturn2search15turn2search1
• API docs and summaries talk about:
  • authentication via user+API key,
  • explicit rate limits per API key / IP,
  • but not “we will ban your account for calling the API at all.” citeturn1search26turn2search7turn1search25

I haven’t found reputable reports of:

• “I used the official Danbooru API with a normal rate and got my account banned because I used the API.”

What does show up:

• People getting temporarily blocked or challenged when they hammer endpoints (either HTML or API) beyond the documented or de-facto limits.
• Tools breaking because their anonymous or high-volume scraping is indistinguishable from abusive bots.

So the reality looks like:

• Banning/blocks are about volume & behavior (hammering, IP rotation, ignoring limits), not about the mere fact that you used an API key.

4. If you want to be “polite” and avoid pissing off operators

Given your goals:

• You already have sleep between downloads in gallery-dl. Good.
• You can further:
  • Respect per-site limits (e.g., keep parallelism low, maybe add a longer sleep for Danbooru-style hosts).
  • Use the documented API + your own key, with moderate usage. That actually makes it easier for them to distinguish “polite script from a human account” vs “random hammering bot.”
  • Avoid long multi-hour runs at max speed; break big jobs into chunks.

If you truly don’t want to touch their API at all, HTML-scraping workarounds are an option, but from the operator’s point of view that’s usually less polite, not more — HTML is heavier and harder to control than an authenticated API with rate limits.

Bottom line:

• The “jealousy” is a drip-feed: API keys and throttling have been around for years, but the hard enforcement and Cloudflare-style blocking ramped up ~2022–2025, and some booru clones only flipped the switch in the last few months.
• There’s no clear signal that normal API usage with a key is ban-bait. The bans/blocks we see are aimed at high-volume scraping, regardless of whether it hits HTML or JSON.
• If you keep your gallery-dl usage modest and respectful (which you already are inclined to do), using an API key is closer to “being a good citizen” than a thing to avoid.

wget --recursive --accept jpg,png,gif,webm --no-parent URL

httrack 'https://example.com/gallery/' -O output -%v

hakrawler -url https://site/page | grep -E '\.(jpg|png|gif|webm)$' | gallery-dl -i -

curl -s URL | pup 'img[src] attr{src}'

curl -s URL | pup 'img[src] attr{src}' | gallery-dl -i -

htmlq -a src img < page.html

hakrawler -url https://example.com | grep -E '\.(jpg|png|gif|webm)$' | gallery-dl -i -

cd ~/bin
curl -LO https://github.com/ericchiang/pup/releases/download/v0.4.0/pup-linux-amd64
mv pup-linux-amd64 pup
chmod +x pup

cd ~/bin
curl -LO https://github.com/hakluke/hakrawler/releases/latest/download/hakrawler_linux_amd64
mv hakrawler_linux_amd64 hakrawler
chmod +x hakrawler

pip install playwright
playwright install

{
  "extractor": {
    "base-directory": "~/Downloads/gallery-dl",

    "path-restrict": {
      " ": "_",
      "/": "_",
      "\\": "_",
      "|": "_",
      ":": "_",
      "*": "_",
      "?": "_",
      "\"": "_",
      "<": "_",
      ">": "_"
    },
    "path-remove": "\u0000-\u001f\u007f",
    "path-replace": "_",

    "sleep": 2.0,
    "sleep-request": 0.0,
    "sleep-extractor": 0.0,

    "archive": "~/Downloads/gallery-dl/archive.sqlite3",

    "directory": ["{category}", "{title|id}"],
    "filename": "{no:0>9}_{filename}.{extension}"
  },

  "format": {
    "file": {
      "extensions": ["webm", "mp4"]
    }
  },

  "postprocessors": [
    { "name": "metadata", "mode": "json", "event": "after" },
    { "name": "metadata", "mode": "tags", "event": "after" }
  ]
}

A couple of important notes:

Your previous exec / exiftool block is the part that was blowing up. The formatter error came from that command template, so I left it out here. The built-in metadata postprocessor is documented and is the safe part to keep. citeturn129075search0turn129075search6

If you want the filename to be more fault-tolerant across mixed sites, use this instead of the filename line above:

G: [Non-text content: thoughts; content_type=thoughts]

G: [Non-text content: reasoning_recap; content_type=reasoning_recap]

G: Yes. In that config, this part is what limits it to video files:

G: Fair call—that was the only piece gating it.

What you’ve got now is basically a clean, stable baseline config:

• safe filenames
• archive handling
• delay control
• metadata preserved
• flexible naming without collapsing to None.ext

That’s about as “set it and forget it” as gallery-dl gets without going into site-specific tuning.

If you come back later, the next likely pressure points will be:

• site-specific auth quirks
• pagination edge cases
• or tightening filename rules once you see real output

But for now, you’re in a good place.

G: Yes — it’s: