feat(plugins): TREK_PLUGINS_IGNORE_TREK_RANGE turns the version gate into a warning (#2226)

* feat(plugins): TREK_PLUGINS_IGNORE_TREK_RANGE turns the version gate into a warning

A plugin whose author has not updated its `trek` range for the running TREK can
now be installed, updated and activated when the operator sets
TREK_PLUGINS_IGNORE_TREK_RANGE to a truthy value. Every gate (registry picker,
post-extraction re-check, sideload, dev-link, activation) warns instead of
refusing; a missing range is tolerated the same way; "install latest" takes the
newest published version. The plugin-API version gate is not lifted and the
Discover compatibility verdict stays truthful.

The admin is warned at every step: each bypass is logged, install/upload/link/
update responses carry a `trekRangeBypassed` marker, and both admin panels show
a "Version checks off" pill, an "Install anyway" confirm dialog before a
registry install, the same notice after a path that could not ask first, and a
persistent chip on the row while the plugin runs outside its range.

Nine new i18n keys in every locale; wiki pages updated (Environment-Variables,
Admin-Plugins, Plugin-Development, Security-Hardening).

* refactor(plugins): one useRangeBypass hook behind both admin shells

SonarQube flagged PR 2226 at 10.8% duplicated new code: the range-bypass
logic had been added to the desktop and phone plugin panels as identical
copies. The marker/warning types, the row chip, the "Install anyway" offer,
the dialog copy and the confirm-or-notice state now live in
useRangeBypass (next to useInstanceSettings, the existing shared-logic
precedent); each panel keeps only its own dialog/sheet markup.

* docs(claude): record the SonarQube gate rules and the no-English-placeholder i18n rule

The CI SonarCloud gate (Sonar way, on new code: >=80% coverage, <=3%
duplication, A ratings, hotspots reviewed) was only discoverable by waiting
20-25 minutes for the workflow. The root CLAUDE.md now states the conditions,
the desktop/mobile shell-mirror duplication trap and its shared-hook fix, and
how to check a PR with the sonarqube MCP first; client and server CLAUDE.md
point at it. shared/CLAUDE.md says every locale needs a real translation —
parity cannot tell an English placeholder from a translation.

* docs(claude): keep CLAUDE.md to commands, invariants, gates and philosophy

Verified every concrete claim in the five CLAUDE.md files against the code
and fixed the stale ones: the websocket server is the Nest realtime gateway,
MCP tools live in <domain>.mcp.ts files, the client "native shell" section
described code that was never written, offline maps also prefetch vector
basemaps, plus several renamed files and wrong table names.

Then trimmed everything that drifts on its own: dates, migration history,
counts, and inventories of stores, slices, domains, sync files and CLI
commands. What stays is the commands, the invariants with the file that
enforces each one, what CI actually runs, the reference implementations to
copy, and the rules for new code. Each file now opens with that rule.
This commit is contained in:
jubnl
2026-09-04 00:43:06 +02:00
committed by GitHub
parent 74c47a6158
commit bc10fba389
53 changed files with 1378 additions and 337 deletions
@@ -105,3 +105,46 @@ export function hostSatisfies(range: string | null | undefined, host: string | n
if (!isValidTrekRange(range)) return false;
return semver.satisfies(release, range);
}
/**
* Whether TREK_PLUGINS_IGNORE_TREK_RANGE is set: the operator's explicit "install it
* anyway" for a plugin whose author has not updated its `trek` range. While it is on,
* every TREK-version gate (registry picker, post-extraction re-check, sideload, dev-link,
* activation) WARNS instead of refusing. Nothing else changes — {@link hostSatisfies}
* keeps telling the truth, so the admin UI can still say the plugin is running outside
* the range its author vouched for. Read live, like the other plugin switches.
*/
export function trekRangeBypassed(): boolean {
return readEnv().plugins.ignoreTrekRange;
}
/** What a bypassed gate reports back to the admin: the range that was ignored and the host it was ignored on. */
export interface TrekRangeBypass {
/** The plugin's declared range, or null when it declared none at all. */
trekRange: string | null;
hostVersion: string;
}
/**
* Non-null exactly when `range` would have been refused and only the bypass lets it
* through: the marker that makes an install/activate response say "this worked, but
* only because you told TREK to ignore the version check". Null for a normal install
* (the range fits) and null when the bypass is off (the gate refuses instead).
*/
export function bypassedRange(range: string | null | undefined): TrekRangeBypass | null {
if (hostSatisfies(range)) return null;
if (!trekRangeBypassed()) return null;
return { trekRange: range ?? null, hostVersion: hostVersion() };
}
/**
* The one log line every bypassed gate writes. It names the plugin, the range that was
* ignored and the host it was ignored on, so an operator reading the log after a plugin
* misbehaves can connect the two without the UI.
*/
export function warnRangeBypass(id: string, b: TrekRangeBypass): void {
const declared = b.trekRange ? `declares TREK ${b.trekRange}` : 'declares no TREK version range';
console.warn(
`[plugins] ${id} ${declared} — this is TREK ${b.hostVersion}; continuing because TREK_PLUGINS_IGNORE_TREK_RANGE is set. The author has not verified it on this version: it may not work, and it could corrupt TREK data.`,
);
}