30 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	2e01242381	feat(extension): derive the version as unpadded CalVer (milestone 318 step 8) ... `1.0.<minutes since 2020>` -> `YYYY.M.D.HHMM` UTC, from the commit time of the newest change to a packaged extension file. Same clock and same commit as before; readable instead of opaque, and the same value the rest of the family derives. The hold on this step was two questions about AMO, and Mozilla's own docs answer both: ^(0|[1-9][0-9]{0,8})([.](0|[1-9][0-9]{0,8})){0,3}$ 1. four all-numeric segments -> ACCEPTED ({0,3} more after the first). 2. leading zeros -> REJECTED. A segment is the single digit `0` or starts 1-9, so `08` and `0201` are refused. MDN says it in prose too: "Non-zero numbers must not include a leading zero." So the documented fallback applies, extension only: the same numbers rendered without the family's zero-padding. `2026.08.29.0201` and `2026.8.29.201` are one value in two renderings — rule 148 defines comparison as numeric per segment, under which they are equal — so nothing already published is reordered, and left-padding each segment recovers the family string exactly. HHMM stays one segment because AMO allows at most four. The transition is safe in the other direction too: 2026 > 1, so every CalVer outranks every published 1.0.x. build.yml's downgrade guard confirms it. Also in scope: * MAJOR.MINOR is gone. `cmd_major_minor`, `cmd_patch` and VERSION_EPOCH go with it, the committed version in manifest.json / package.json is now wholly inert, and ci.yml's MAJOR.MINOR-agreement check is retired rather than left running beside a fact that stopped existing (rule 22). * ci.yml's `extension-version` lane now asserts Mozilla's regex verbatim instead of a loose `^[0-9]+(\.[0-9]+)*$` — which would have passed the padded shape. It also asserts YYYY.M.D.HHMM, because AMO would accept a regression to `1.0.<minutes>` while that orders below everything signed since. Checking here is the point: AMO 409s on re-signing, so a version it rejects is burned and cannot be reused. * `artifacts.sh version extension` delegates to packaging.sh, so the two cannot answer differently. The direction matches the existing one — artifacts.sh already asks packaging.sh for the extension's path set. #3156 is what makes this commit safe to make: packaging.sh is in web's path set, so the web revision moves with the extension version and build-web rebuilds instead of republishing an image bundling the previous XPI. Scribe #3138. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 13:43:30 -04:00
bvandeusen	b6b9fd8287	ci: a release publishes a changelog, not an image (318 step 7) ... Step 2 took the build consequence away from a `v*` tag — `main` has already built and published the commit by the time anyone tags it, and rebuilding would re-push `:c-<sha>`, which rule 145 forbids even when the source matches. That left the tag with nothing to do at all. This is the job it has instead. Step 6 put the derived version in the Settings footer, so an operator can say WHICH build they are running; this says what is in it that was not in the one they ran last month. Both halves of one question (note #3127 §5). The previous release is found by walking ANCESTRY, not by sorting a list. That is load-bearing here specifically: rule 148 moved the tag shape from `v26.05.22.0` to `v2026.08.28.2208`, and lexicographically `v2026...` sorts BEFORE `v26...` — the third character is `0` against `6`. A sorted implementation would reach back past every new-shape tag to the newest old-shape one and publish months of commits as "changes since", looking entirely correct while doing it. `git describe --exclude` is immune to the shape change, and reachability is the more honest question anyway. The publisher GETs and PATCHes rather than POSTing and recovering the id from a 409 — note #3127 §6.7, which is ThoughtSync #2182's bug. A `v*` tag is created once so the conflict path is rare, but "rare" is how that one survived to be found somewhere else. Cross-checks are reported on the release, not enforced. The tag is already pushed by the time this runs, so failing would leave the operator with a tag, no release, and a red lane to explain it — while the release is still the useful object. It says so at the top when the tag names a version the web image does not report, or when the commit is not on `main` and the `:c-` rollback refs it lists were never published. Nothing runs on a schedule and nothing auto-tags on merge. Release tags are bookmarks (note #3127 §0); FC went twelve weeks without one and nothing was wrong. Also here: - `scripts/` joins the ruff lane. release_notes.py runs only on a tag push, so a syntax error there would otherwise surface at the one moment nobody wants to be debugging a workflow. - version.spec.js reads the workflow directory instead of listing three files by hand. Its own comment says the assertion should survive consumers coming and going; the hardcoded list was the part that could not, and release.yml would have joined the directory without joining the check. Tests build a synthetic history spanning the tag-shape change rather than leaning on this repo's tags, so the span assertion holds whether or not a checkout brought the tags along — a span test that quietly skips is worse than one that fails.	2026-08-28 20:57:25 -04:00
bvandeusen	fb2c4d5b80	fix(extension): packaging.sh decides the version, so it must move the version ... `packaging.sh pathspec` excluded `extension/scripts/**` — the same list web-ext ignores. But the two lists answer different questions, and this is the one place they disagree. packaging.sh is not packaged into the XPI. It does decide the version string, and build.yml stamps that string into the manifest.json that IS packaged. Changing how the version is computed therefore changes the shipped bytes, and the derivation has to see it. Harmless while every push rebuilt the web image. Step 4 made the rebuild conditional on the derived revision moving, which turns it into a silent failure: a packaging.sh change yields a NEW version, so sign-extension misses its ext-<version> cache and signs — while build-web sees an unmoved revision, reuses the published image and ships the OLD XPI. One orphaned AMO signature, and an instance serving code the registry calls current. Found while checking the ground under step 5, which changes the version format and is exactly the commit that would have hit it. Split the list rather than widening the shared one: NOT_VERSION_RELEVANT drives the pathspec, NOT_PACKAGED_TRACKED still drives web-ext's ignore list, and scripts/ stays out of the XPI. The two directions are not symmetric, which is why the version list is the narrower one — too wide costs a re-sign and a rebuild for a change that ships nothing new, too narrow serves stale bytes and says nothing. No version churn: the last packaging.sh commit predates the current extension revision, so the derived version is unchanged at 1.0.3500147 and web's revision stays a7e626a67a. Both suites now pin the disagreement from their own side, because the tempting fix for either half is to make the lists one again — version.spec.js asserts the pathspec does NOT exclude scripts while the ignore list still does, and test_artifact_paths.py asserts packaging.sh is inside the extension and web path sets.	2026-08-28 08:49:06 -04:00
bvandeusen	a7e626a67a	feat(extension): report the channel beside the version (step 7) ... Closes the half of the ask the signing work didn't: a way to tell a dev build from a main one. FC_CHANNEL is baked into the web image at build time and /api/extension/manifest reports it as its own key, next to version — the popup banner, the toolbar tooltip and the Settings card all name it. Beside the version, never inside it. A `1.0.3499884-dev` suffix is the obvious shortcut and it is the exact failure this design comes from: versionIsNewer parses each dotted segment with parseInt, so a suffixed segment reads as 0, every dev build compares equal to every other, and "no update available" stops being distinguishable from "I cannot read this version". The comparator already degrades rather than discarding (rule 150), which is a reason not to NEED the suffix, not a licence to add one. Two tests hold the line — one backend, asserting version and channel are separate keys; one frontend, asserting the rendered version text stays the bare derived number. Optional on the read side, and absent rather than defaulted. An image built before this field says nothing by not having the key; an image built without a channel now says nothing the same way, so there is one absence to handle instead of a second spelling of "unknown". Every reader drops the label entirely when it is missing and reads exactly as it did before. Reported verbatim rather than validated against {dev, main}: if an image declares something else, showing what it claims helps whoever is debugging more than dropping it would. FC_CHANNEL is declared LAST in the Dockerfile. An ARG invalidates every layer below it, and this is the one value that differs between the dev and main builds of identical source — earlier, and the two channels could never share a cached pip install. A tag push counts as main: a vYY.MM.DD tag is cut from main, so that image is a main-channel artifact wearing an immutable name. No channel switcher, deliberately. background.js:34 already records that Firefox's static update_url cannot apply, because every FC instance is a different host — so the extension asks its configured backend, and the channel IS the instance it points at. Switching is repointing apiUrl and reinstalling from that host. A separate setting would contradict each server build shipping its own extension. This commit touches packaged extension files, so it moves the derived version and will sign a new one via AMO — the first push to exercise the extension-changed path from dev end to end.	2026-08-27 11:47:30 -04:00
bvandeusen	fe48e77821	ci(extension): retire the manual-bump guard, true up the docs (step 5) ... The guard asked whether a packaged extension file changed without the version moving. Since step 4 nobody moves the version by hand, so it was checking a fact that had stopped existing — and it was not merely dead weight: it would have failed the lane on every real extension change, demanding a bump that decides nothing. Removed rather than left running beside the new mechanism (rule 22). What replaces it is thinner and true. The extension-version lane now asserts the derivation resolves on this commit, that the derived value is the plain dotted-numeric shape AMO accepts, and that MAJOR.MINOR agrees between manifest.json and package.json. MAJOR.MINOR is the one part still hand-set, and packaging.sh reads it from manifest.json ALONE, so a divergence ships a version package.json disagrees with. The lane keeps fetch-depth: 0 — checking that the derivation survives a real checkout is half its remaining value. Deliberately not checked there: that the derived value beats what is already signed. That guard belongs in build.yml, where it compares against the real ext-* releases. Comparing against origin/main in a lane would be wrong, because dev legitimately derives a LOWER value whenever main is ahead on the extension, and a lane that fails for being behind is a lane people learn to ignore. packaging.sh is down to two consumers from three. version.spec.js's "ci.yml derives its pathspec" test would have gone red on that, so it is rewritten to assert the property rather than the consumer: no workflow inlines an :(exclude)extension/ literal, across all three. That keeps the #2397 anti-regression value while surviving consumers coming and going. A second test pins build.yml to packaging.sh version and fails if it goes back to grepping the committed value — which is not a style regression but the #3092 bug itself. build.yml joins extension.yml's trigger paths, since the suite now asserts against it. The lockstep test narrows from the whole version string to MAJOR.MINOR. The committed patch numbers are inert now; asserting on them would fail for a difference that changes nothing. Docs. extension/README.md's Release section described extension.yml signing on main and committing the XPI into frontend/public/ — untrue since 2026-05-25, and it told the reader to hand-bump both files, which is now exactly the wrong instruction. Rewritten, with a Versioning section that says plainly that editing the patch number does nothing and why the key is commit time rather than a count. ci-requirements.md drops the third packaging.sh consumer and names every job that needs full history. Root README no longer claims the extension is signed on main only.	2026-08-27 11:29:44 -04:00
bvandeusen	cd5444e3ae	ci(extension): derive the version from commit TIME, not commit count (#3092) ... Rule 149: an artifact's ordering key must be time-derived, never a commit count. packaging.sh's cmd_patch was a count. Why that matters here rather than in the abstract. A count is per-branch: dev and main count different histories of the SAME code. Today only main signs, so nothing has ordered the two against each other and the fault is invisible. The moment dev also publishes an extension, the two versions order by which branch accumulated more commits rather than by which is newer — and a squash-merge makes it permanent, because main gains one commit where dev gained five. dev then climbs away from main and a dev install can never cross back. That is Roundtable's 2026-08-24 incident (Scribe #2993) in a different repo: their versionCode was the branch's commit count, and it produced a channel you could enter and not leave. Measured on this repo today the old formula gives main=23, dev=24 — one apart, which is exactly how the inversion stays invisible until it strands somebody. New formula: minutes since 2020-01-01 of the LATEST commit touching a packaged extension file. Same anchor and unit Roundtable settled on. Commit time, not build time, and the difference is load-bearing: - stable while the extension is unchanged, so the ext-<version> signature cache still hits and AMO is called once per extension CHANGE rather than once per push. Build-time minutes would re-sign on every push and never let two channels share a signature. - after a merge, main sees the same commit and derives the same number, so :latest reuses the signature :dev already produced for byte-identical code. Same code, same version, one signing. - monotonic: max() over a set that only gains members. Verified across all 24 extension-touching commits, zero non-monotonic steps. - reproducible from any checkout. Derives 1.0.3499884 on dev, 1.0.3465860 on main — both far above the last hand-set 1.0.11, so milestone 271's backfill guard is satisfied by construction rather than by an offset. Still shadow-only: nothing reads the derived value yet. Both shadow steps log it, and ci.yml's runs on dev too, so both channels' numbers are visible — that is the pair that has to stay ordered. Prior shadow observations describe the OLD formula and prove nothing about this one, so the window restarts; ci.yml says so at the step. New requirement recorded in ci-requirements.md: a depth-1 clone derives a wrong, too-low value rather than failing, so fetch-depth: 0 is load-bearing wherever packaging.sh version is called. Refs #3092, milestone 271	2026-08-27 09:26:58 -04:00
bvandeusenandClaude Opus 5	ddf896078c	refactor(platforms): retire deviantart end-to-end (#3069) ... Executes the 2026-07-05 product decision (FC downloaders = art-dedicated services only), which removed Twitter/X and Bluesky but left deviantart fully wired for seven weeks — the half-retired state rule 22 exists to prevent. Removed: the PlatformInfo module and its registry entry, the gallery-dl extractor block, extension_service's artist-page pattern, the extension's PLATFORMS + PLATFORM_ARTIST_PATTERNS entries, its manifest host permission and content-script match, the frontend icon/colour/label, and the operator- facing "supported platforms" list that still advertised it. Two judgment calls, both recorded in migration 0088: * existing `source` rows are DISABLED, not deleted. The row is the only record of the artist's DeviantArt URL. Disabling is also required for correctness rather than tidiness: with the platform unregistered the download path falls through to gallery-dl, which carries its OWN deviantart extractor, so an enabled row would have kept downloading from a dropped platform. * the `credential` row IS deleted — a live session cookie for a site FC will never call again. Adds the invariant whose absence is why manifest.json drifted in the first place: nothing tied its domain lists back to the platform table. The extension suite now asserts both directions, plus that no host permission belongs to an unclaimed domain (`*://*/*` exempted — FC is self-hosted at an operator-chosen URL the extension cannot enumerate). Extension version 1.0.10 -> 1.0.11: ci.yml's guard hard-fails a packaged extension change without a bump. No release is cut — build.yml's sign-extension job only runs on main. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 07:24:08 -04:00
Claude	11dd324f89	fix(extension): exclude the test/ and scripts/ directory entries from the XPI ... The XPI-content check added in 1c6452e did its job on its first run: the archive carried empty `test/` and `scripts/` entries. `test/**` matches the files inside a directory but not the directory entry itself, and web-ext writes an entry for the directory separately -- so the contents were correctly excluded while the empty directories shipped anyway. Nothing harmful reached users (no dev code, just two empty entries), but our single declaration claimed these do not ship and something was shipping. Both forms are now listed per directory. The bare name alone would not do: minimatch's `test` does not match `test/url.spec.js`, so dropping the glob would ship the contents instead. Verified locally: the derived version is unchanged at 1.0.19, confirming the added entries are redundant for the git pathspec and only affect web-ext. Refs #2400 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 16:20:54 -04:00
Claude	597b91d29b	refactor(extension): one definition of what ships in the XPI ... Milestone #271 step 1. Groundwork for deriving the extension version from git; no behavior change yet -- nothing consumes `version` so far. "Which files end up in the XPI" was stated in two places and about to become three. Three hand-kept copies of one fact is what allowed #2397, where the publish path could republish a stale XPI because its cache key had no link to the content it stood for. New extension/scripts/packaging.sh holds the single declaration and exposes: ignore web-ext --ignore-files values pathspec :(exclude)extension/... for git version <MAJOR.MINOR from manifest>.<commit count over packaged files> major-minor / patch Consumers now delegate instead of restating it: - extension/package.json -- all four web-ext scripts - .forgejo/workflows/ci.yml -- the extension-version guard's exclusions - (step 4) the rev-list that derives the version scripts/** joins the non-packaged set; the script must not ship to users. Two shell hazards, both load-bearing: The script runs `set -euf`. Its lists are iterated with deliberate word splitting, and without -f the shell ALSO globs them -- invoking `pathspec` from a directory where test/ exists (exactly how ci.yml calls it) would expand `test/**` into the individual spec files and silently stop covering anything added later. A caller's own `set -f` cannot prevent this: the script is a separate sh process and does not inherit it. Callers additionally need their own `set -f` for the substituted RESULT, which is a different expansion. version.spec.js asserts every --ignore-files caller sets it, that the pathspec comes through with `test/**` literal and no .spec.js paths, and that neither consumer has reinstated a hardcoded list -- the easy future regression is "simplifying" by inlining one again. Verified: all five subcommands plus the usage/exit-2 path. Derived version on main (8300029) is 1.0.19, matching dev. Last published is 1.0.10, so the eventual cutover moves strictly upward and needs no offset -- Firefox refuses downgrades. (An earlier note recorded 18; that was measured against a stale origin/main from before the PR #234 merge.) Refs #2398 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 15:33:11 -04:00
Claude	f9111c06a7	test(extension): unit suite for lib/ + version-consistency specs ... extension/ had no test harness at all -- web-ext lint was the only signal, so the URL-normalization fix in 8214afe shipped with nothing exercising it. Adds vitest (mirroring frontend/vitest.config.js) and three specs: - url.spec.js normalizeApiUrl / webRootFromApiUrl, including the #2393 regression: instance-root input must reach /api/credentials, idempotence, trailing-slash and whitespace handling, and that empty input never yields a bare "/api" (which isConfigured() would read as configured). - platforms.spec.js getPlatformFromUrl / isArtistPage, pinning the #1485 regression -- all three Patreon creator URL shapes (bare, /c/, /cw/) plus inner pages, with nav pages excluded -- and table-integrity checks. - version.spec.js manifest.json and package.json versions in lockstep, AMO-safe version format, and url.js ordered before api.js in background.scripts (classic scripts share one scope, so a reorder is a runtime ReferenceError with no build signal). Specs load lib/*.js by evaluating the real file as a classic script (test/helpers/loadLib.js) instead of adding module.exports shims to production code that would never run in the browser. The suite therefore exercises exactly the bytes packaged into the XPI. Two packaging consequences, both handled: - web-ext would otherwise bundle test/ and vitest.config.js INTO the XPI; both are now in --ignore-files across all four web-ext scripts. - ci.yml's extension-version guard must ignore the same paths, or editing a spec would demand a pointless version bump. The dangerous drift direction is the opposite one -- a guard exclusion for a file that DOES ship would let a real change pass unnoticed -- so version.spec.js asserts every :(exclude) in ci.yml appears in --ignore-files. extension.yml also triggers on ci.yml now, since version.spec.js reads it. Refs #2393, #2397 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 23:47:18 -04:00
Claude	8214afee1e	fix(extension): normalize FC URL so credential push doesn't 405 ... The stored apiUrl was required to already carry the `/api` suffix, since api.js builds requests as `${baseUrl}/credentials`. The options label read "FC base URL", so entering the instance root -- the natural reading -- sent every request one path segment short: POST /credentials hit the Vue SPA catch-all and came back 405, and GET /extension/manifest 404'd. Worse, Test Connection reported success on it: the catch-all answers GET /credentials with 200 HTML, so `r.ok` was true and the only affordance meant to catch this misconfiguration actively masked it. Normalize instead of validate (rules 92, 26): - New lib/url.js: normalizeApiUrl / webRootFromApiUrl, one source shared by the background client and the options page. Accepts either the instance root or the API root. - api.js normalizes on read, so configs already stored in the broken form heal themselves without the operator reopening Settings. - options.js stores the canonical form, echoes back what it saved, and the test now asserts a JSON content-type -- killing the false green. - 404/405 in request() now names the URL and points at the setting. - Options label/placeholder state that both forms work. Version 1.0.9 -> 1.0.10 in BOTH manifest.json and package.json; build.yml resolves the release version from package.json, and a stale value there would hit the cached ext-1.0.9 asset and republish the old XPI unsigned against the new code. Refs #2393 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 19:37:38 -04:00
bvandeusenandClaude Opus 4.8	e92570a31e	refactor(extension): DRY the web-root transform + cookie-export flow (#161) ... Behavior-preserving (extension JS has lint-only CI + your manual test): - api.webRoot() single-sources the baseUrl→web-root transform (strip trailing slash + /api) that was copy-pasted in background.js's self-update check and OPEN_ARTIST_PAGE, whose comments even cross-referenced each other. - exportPlatformCookies(key) shares the extract→verify→upload spine between EXPORT_COOKIES (single) and EXPORT_ALL_COOKIES; it returns a structured outcome so each caller keeps its own response/skip messages verbatim. - popup.js mutedNote(text) replaces the "centered muted note" div hand-rolled in the platform-loading, sources-loading, and empty-sources renderers. No version bump — no behavior change, so it rides the next real ext release rather than forcing an AMO re-sign + reinstall. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NsmJSQxnNxGgtM5Yz4GAqi	2026-07-13 21:57:14 -04:00
bvandeusenandClaude Opus 4.8	d80a5255ed	feat(extension): in-app update prompt — popup banner + toolbar badge (#1489) ... The extension is installed per-instance from the operator's FC host, so Firefox's static update_url can't apply (each instance has a different host) and updates were fully manual. Add a self-hosted-friendly update surface that reuses the existing public GET /api/extension/manifest ({version, latest_url, sha256}): - lib/api.js: getExtensionManifest(). - background.js: checkForUpdateInfo() compares the instance's latest published version against runtime.getManifest().version (dotted-numeric compare so 1.0.10 > 1.0.9); CHECK_UPDATE message handler; refreshUpdateBadge() sets a toolbar badge via browser.action; a daily browser.alarms check plus on startup/installed. New 'alarms' permission (non-prompting). - popup: an 'Update available — vX' banner with an Update button that opens the signed XPI (web root, /api stripped like OPEN_ARTIST_PAGE) → Firefox's native install prompt. Never blocks the popup on a failed check. No backend changes (endpoint already exists). Bump 1.0.8→1.0.9 so this ships; from here on updates surface themselves instead of needing a manual reinstall. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 18:28:06 -04:00
bvandeusenandClaude Opus 4.8	69b5637bd6	fix(extension): show Add-to-FC button on subscribed Patreon creators (#1485) ... Symptom (operator-flagged): the extension injected the Add-as-source button on a Patreon creator you had NOT subscribed to, but it disappeared once you were subscribed — the opposite of when it's useful. Root cause (extension logic, not Patreon security): Patreon serves a creator under three URL shapes — bare patreon.com/Atole, patreon.com/c/Atole, and patreon.com/cw/Atole (the 'creator workspace' URL you land on once subscribed; documented in patreon_resolver._VANITY_RE). The button's artist-page gate (PLATFORM_ARTIST_PATTERNS.patreon in platforms.js) and its byte-mirror probe pattern (_PLATFORM_PATTERNS in extension_service._derive) only matched the bare single-segment form and explicitly excluded c/. So the subscribed-view URL failed the gate → no button. The ingestion resolver already handled all three; only these two gates were too narrow. Fix: both regexes now accept optional cw/ and c/ prefixes and drop the strict single-segment end-anchor, so a creator's inner page (/cw/Atole/posts, /Atole/membership) also matches — robust to whatever exact shape the subscribed view uses. Nav-page exclusions (home/search/messages/notifications/library/ settings/posts + post permalinks) preserved. New unit test covers all three prefixes, sub-paths, and nav-page rejection (both regexes validated identically). Bump extension 1.0.7→1.0.8 so a fresh signed XPI ships the fix (also exercises batch-5 web-ext-10's AMO sign path end-to-end on the main build). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 17:50:07 -04:00
bvandeusenandClaude Opus 4.8	51749e05db	chore(deps): update web-ext 8→10 (batch 5) (#1450) ... Renovate dep-dashboard batch 5. web-ext is the extension's build/lint/sign CLI (devDependency only; no extension source changes). Verified against the 8→10 changelog + FC's actual usage: - All CLI flags we use survive unchanged: --source-dir, --no-config-discovery, --ignore-files, --overwrite-dest (build), --channel/--api-key/--api-secret (sign). No removed/renamed flags for lint/build/sign. - v9's one breaking change (.js config files rejected) does NOT apply: we pass --no-config-discovery on every command and ship no config file. - Node: web-ext 10 baselines Node 22. The lint job runs on node:24-bookworm-slim; the load-bearing AMO sign job runs on ci-python:3.14 which installs Node 24 (CI-runner NODE_MAJOR=24) — both satisfy it. Sign is cache-skipped this push (extension version unchanged at 1.0.7) but is verified compatible for the next version bump. - The bundled addons-linter jumps to 10.1.0 — the extension.yml lint job (web-ext lint over the MV3 manifest) is the CI verifier for any new manifest findings. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 16:30:11 -04:00
bvandeusen	d3245f0c22	feat(ext): verify cookies in-browser before uploading (1.0.7) ... Pre-upload verify request: after capturing the live browser cookies, hit a known authenticated endpoint with credentials:'include' from the extension's background context. If the platform reports we're not logged in, abort the upload so we don't overwrite FC-side credentials with stale data. - platforms.js: add `verify` config per cookie-auth platform - hentaifoundry: HEAD /?enterAgree=1 (mirrors gallery-dl's HF _init_site_filters; same 401 path the operator hit 2026-06-03) - patreon: GET /api/current_user (clean 401 when logged out) - subscribestar, deviantart: no stable auth endpoint, skip verify - cookies.js: verifyCookiesForPlatform() returns {ok, status, reason}. ok=true/false/null tri-state — null = verify not configured, caller treats as "proceed". - background.js EXPORT_COOKIES + EXPORT_ALL_COOKIES: verify gates the upload; failures bubble up with the platform's name + reason. - popup.js: success message now appends "(verified ✓)" when applicable. - manifest + package.json: 1.0.6 → 1.0.7.	2026-06-03 14:04:45 -04:00
bvandeusen	d65f0b2091	feat(extension): probe shows current state before click; v1.0.6 ... Operator-asked 2026-05-31 (during sidecar synthetic anchor cleanup): "the add source/subscription button idea to the firefox extension so it can tell me if a source/artist is added or not and offer an option to add it if it isn't." Plan tracked in Scribe task #507. ## Backend - `ExtensionService.probe(url)` — read-only resolution. Reuses `_derive` for platform+slug, then 2 SELECTs. Returns one of: - `source_match` (exact (artist, platform, url) Source exists) - `artist_match` (artist exists, this URL isn't a Source yet; collapses the sidecar-synthetic-only case from v26.06.01.0) - `new` (neither exists) - `unknown_platform` (URL didn't match any artist-page regex) - `GET /api/extension/probe?url=...` route with `X-Extension-Key` auth posture matching `/quick-add-source`. Read-only, side-effect free. - 6 backend tests in tests/test_api_extension.py covering each state + auth + invalid URL. ## Extension - `api.js`: `probeSource(url)` mirroring `quickAddSource` shape. - `background.js`: `PROBE_SOURCE` + `OPEN_ARTIST_PAGE` handlers. The latter strips the `/api` suffix from configured `apiUrl` (placeholder format per options.html) and opens `${base}/artist/{slug}` in a new tab via `browser.tabs.create`. - `content-script.js`: probe-first render — on page-load and SPA navigation, asks the backend for the URL's state and renders the chip in the matching color/copy on FIRST paint instead of flashing generic "Add" and updating after. Click handler branches: `source_match` → OPEN_ARTIST_PAGE; `artist_match`/`new` → existing ADD_AS_SOURCE flow (then re-probes so the chip flips green immediately, no wait for next nav). - `content-script.css`: three state-color modifiers (--new, --artist-match, --source-match) on the FC parchment-on-slate palette. Sage for already-added, amber for artist-exists, accent orange for new. ## Versioning - `extension/manifest.json` + `extension/package.json` → 1.0.6. build.yml's sign-extension job will fire on push to main since no `ext-1.0.6` Forgejo/Gitea release exists yet — exercises the regenerated AMO keys end-to-end. ## Behavior on the sidecar-synthetic case Filesystem-imported "Dymkens"-style artist with only a sidecar synthetic Source: probe returns `artist_match` (not `new`), so the chip reads "+ Add Patreon source to Dymkens" rather than offering to recreate the artist. Clicking adds the real Source; existing `_source_for_sidecar` preference logic (v26.06.01.0) routes future gallery-dl Posts to the real one.	2026-06-01 00:41:17 -04:00
bvandeusen	2394e47370	fix(hentaifoundry): inject host-only PHPSESSID/CSRF duplicates + extension preserves browser hostOnly ... Operator-flagged 2026-05-27: HF source check 401'd on `HEAD /?enterAgree=1` even with valid login cookies. Root cause is the combination of (1) gallery-dl's HF extractor checking `self.cookies.get("PHPSESSID", domain="www.hentai-foundry.com")` with `requests`' EXACT domain matching, and (2) the extension's cookies.js forcibly rewriting every captured cookie to a leading-dot subdomain-wide form. HF's PHPSESSID is browser-stored as host-only on `www.hentai-foundry.com`; the rewrite re-anchored it to `.hentai-foundry.com`, which `cookies.get(...)` no longer matches even though the cookie is still sent on actual HTTP requests (RFC 6265 subdomain rules). The extractor falls into its unauthenticated `?enterAgree=1` fallback, which 401s (Cloudflare or HF's anti-bot HEAD gating). Two-part fix, no operator action required for existing stored cookies: 1. **Backend** (`credential_service._augment_cookies`) — refactored from the subscribestar-only single function into a per-platform dispatcher. New `_augment_hentaifoundry` parses the materialized netscape file and, for each `.hentai-foundry.com` entry whose name is PHPSESSID or YII_CSRF_TOKEN, appends a host-only duplicate (`www.hentai-foundry.com\tFALSE\t...`). Originals preserved. Three new tests pin: injection fires + originals preserved; idempotent when host-only already exists; doesn't touch unrelated cookies (e.g. `_ga`). 2. **Extension** (`cookies.js`) — `toNetscapeFormat` now respects `c.hostOnly` from the browser instead of blindly forcing a leading-dot subdomain-wide form. Host-only cookies are written with the bare host + FALSE flag; non-host-only cookies retain the leading-dot + TRUE form. Forward-compat — fresh captures from v1.0.5+ no longer need the backend's host-only duplication. Extension bumped 1.0.4 → 1.0.5; manifest + package.json in lockstep. After deploy: the next HF source check on the operator's already-stored cookies will succeed because the materialized cookies.txt now contains host-only PHPSESSID. No browser re-export needed.	2026-05-27 19:12:51 -04:00
bvandeusenandClaude Opus 4.7	74dac6b960	fix(extension+migration): MV3 CSP opt-out from upgrade-insecure-requests (v1.0.4) + alembic 0023 drops the ck_tag_fandom_requires_character check before the type swap ... extension/manifest.json: add content_security_policy.extension_pages = "script-src 'self'; object-src 'self';" — explicitly omits the upgrade-insecure-requests directive that MV3 inherits by default. Without this, every fetch(http://curator.../...) silently upgrades to https:// at the browser layer (Sec-Fetch-Site=same-origin, NS_ERROR_GENERATE_FAILURE), regardless of about:config. Bump XPI version 1.0.3 → 1.0.4 so a fresh signed build replaces the cached one. Operator-troubleshot 2026-05-26 via Inspect-the-extension dev tools showing the silent scheme upgrade. alembic 0023: drop ck_tag_fandom_requires_character before the tag_kind type swap and recreate after. Postgres can't resolve `kind = 'character'` across the rename (column on tag_kind_old, literal binds to new tag_kind → "operator does not exist"). Same dance on downgrade. Banked under reference_tag_kind_enum_swap_check_drop. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-26 21:57:38 -04:00
bvandeusen	5587a76606	fix(ext-ci): replace jq with python3 (jq not in ci-python image) + bump ext 1.0.2→1.0.3 (escape AMO 'version already exists' from prior partial-failure run) + add rollback to prevent empty cache-release tombstones — Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-25 23:14:11 -04:00
bvandeusen	17e19081a2	fix(ext-ci): drop web-ext-config.cjs (v8 mis-parses .cjs configs as if module.exports were a config option) — inline ignore-files on CLI + --no-config-discovery — Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-25 22:46:58 -04:00
bvandeusen	c06cbc0abe	feat(ci): inline extension sign into build.yml + Forgejo Release Assets as XPI cache (v26.05.25.5) — bump ext to 1.0.2 — Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-25 21:30:11 -04:00
bvandeusen	dc3bce7fc1	chore(ext): bump to 1.0.1 to trigger initial sign-and-publish — Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-25 17:37:10 -04:00
bvandeusenandClaude Opus 4.7	379445c244	fc3g(ext): content script — floating 'Add to FabledCurator' button on artist pages ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-23 23:37:02 -04:00
bvandeusenandClaude Opus 4.7	b067a3eec1	fc3g(ext): options page — FC URL + API key form with test-connection button ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-23 23:36:31 -04:00
bvandeusenandClaude Opus 4.7	b7832c941d	fc3g(ext): popup UI — platforms + sources tabs, export-all CTA, status indicator ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-23 23:35:55 -04:00
bvandeusenandClaude Opus 4.7	df82abe75e	fc3g(ext): background script — message router, Discord token capture, Pixiv OAuth ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-23 23:34:11 -04:00
bvandeusenandClaude Opus 4.7	c1d3046778	fc3g(ext): cookies extraction + FC backend API client ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-23 23:33:26 -04:00
bvandeusenandClaude Opus 4.7	9b01b19666	fc3g(ext): platform registry + artist-page URL patterns ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-23 23:32:47 -04:00
bvandeusenandClaude Opus 4.7	a06c4f009f	fc3g(ext): bootstrap extension/ skeleton (manifest, package, icon, README) ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-23 23:32:23 -04:00