The Cargo homepage feeds Plugin::URL, which hosts can show to users, so
the placeholder should be somewhere reachable rather than a github.com URL
that never existed.
This retires YOUR-USERNAME and YOUR-PLUGIN-NAME as canonical values, which
is the self-arming STALE mechanism working as designed: both were skipped
while they were part of HOMEPAGE and became live checks the moment they
were not. Both pass, since the whole URL was replaced.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WHt4DykxXaQnyaJfyS8KCn
Integrating into Bari 206 turned up a pattern that cannot match correctly
formatted source. Its CLAP_DESCRIPTION is long enough that rustfmt wraps
the assignment:
const CLAP_DESCRIPTION: Option<&'static str> =
Some("Multiband compressor/limiter (...)");
A site pattern spanning `const ... = Some("...")` never matches that, and
the fix is general rather than specific to this field: a site pattern
should be the narrowest fragment that is still distinctive, so formatting
decisions above it cannot break the check. Some("...") is unique enough
and lives on one line whatever rustfmt does with the rest.
Also stops appending a bare newline to STALE when nothing was retired,
which a no-op regeneration does on every run.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WHt4DykxXaQnyaJfyS8KCn
Integrating this toolkit into Bari 206 surfaced two things the template
could not express, both of which would have produced wrong output.
**AUTHOR.** Cargo's authors entry names whoever wrote the plugin; VENDOR
is the organisation that ships it. Bari 206 separates them - "Mikkeli
Matlock" authored it, "Novoyuuparosk" vends it - while this template only
happened to work because its two placeholders were identical. AUTHOR is
now its own value defaulting to VENDOR, pinned in branding.conf only when
it actually differs so the file keeps showing that it derives.
**Site-directed rewriting.** That default is exactly what broke the
rename: with AUTHOR defaulting to VENDOR, both fields hold the same old
string, and a global value substitution cannot tell which occurrence
belongs to which. Renaming the vendor put the org name in the authors
field.
The site table already holds the old resolved literal for every site it
owns, and regeneration produces the new one, so rewriting by that pair is
unambiguous. brand-plugin.sh now does that first and falls back to value
substitution for everything the table does not enumerate - doc comments,
use sites in other modules, prose. The order matters and is load-bearing:
run the global pass first and it consumes the old literals, leaving the
precise pass nothing to match.
Verified on the ambiguous case: renaming with a distinct author now puts
the person in Cargo.toml's authors and the org in Plugin::VENDOR, where
the previous implementation put the org in both.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WHt4DykxXaQnyaJfyS8KCn
Three changes that only make sense together.
**tools/**. check-branding.sh, brand-plugin.sh and branding.conf were
accumulating in the repo root, and a deploy.sh/bat/ps1 set would land
there too. They now live in tools/ and resolve the repo root explicitly
rather than assuming their own directory is it, so they behave the same
however they are invoked.
**One name drives the rest.** branding.conf now derives the package name,
the Rust types and the display name from PLUGIN_NAME, each overridable.
Derivation-by-default removes a class of drift; the override matters
because the derivation is sometimes invalid — "206 Prototype" derives to
"206_prototype", which cargo rejects outright — and because PLUGIN_NAME is
cosmetic while the package name is structural. A display tweak should not
silently rename the crate, its bundle lookup, the CI command and the
lockfile. This template overrides three of them, which a real plugin
normally will not: its names are the template's own rather than derived
from a product name.
An overridden PKG that no longer matches the derivation is reported at
info level, never failed. The override is usually deliberate; a display
rename that forgot the package looks identical from here, and is not.
**The site table is data.** branding-sites.tsv lists every place a name
must appear and in what form; check-branding.sh iterates it instead of
carrying 29 check calls in shell. The scripts are now identical across
every plugin built from this template, with only the table and conf
differing — which matters because the template and codename-206 had
already diverged by two checks, so every sync was a shell merge.
brand-plugin.sh regenerates the rows it owns and preserves the rest, so a
hand-added row for a file this template does not ship survives a rename.
Custom rows are value-substituted like any other tracked file, so they
track the rename rather than going stale — the first cut excluded the
whole table from substitution and got that wrong.
brand-plugin.sh also gained an interactive mode: run it with no arguments
and it prompts for each value with the current one as the default, so
Enter keeps it and a run that answers nothing changes nothing. It only
engages when there is a terminal to ask at, so CI gets the usage message
and exit 2 rather than a hang.
Verified by applying a full rename to a sandboxed copy: 8 files rewritten,
29 owned rows regenerated, 1 custom row preserved and substituted, checker
green at 48/0/7, and the result compiles as bari_206.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WHt4DykxXaQnyaJfyS8KCn
mikkeli