Two halves of the same coupling, both left behind by this morning's extraction. The pairing UI was Settings/IntegrationsSettings/BrowserRelay.tsx — a PLATFORM screen driving this plugin's pairing, calling /browser/relay-token, and working only because the plugin happens to serve that path. It is a panel here now, beside the tab list rather than buried in settings: it shows whether the extension is connected and how many tabs it holds, which is the first thing anyone looks at when a capture does not work, and that is not configuration you set once. The download link pointed at public/browser-relay-extension.zip, a static file. That file was 58 lines behind the source it claimed to be — built in August from something that predated a February commit, never rebuilt, and serving an extension missing the multi-session recovery path that the same February commit added. Anyone downloading it got the version that cannot recover from exactly the failure they were about to hit. So the archive is built from the extension directory per request. There is no second copy to fall behind, which is the only durable fix for that class. zip.ts is hand-rolled and stored rather than deflated. The route's own history says it used to shell out to `zip`; this manifest's "nothing to declare" is worth more than 30 KB on a download that happens once, and Chrome accepts stored entries. Timestamps are fixed at the format's zero so the same directory always produces identical bytes — which is what makes the ETag meaningful and "did this change" answerable by comparing two files. Verified by unzipping the output and diffing background.js against the source. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
37 lines
1.3 KiB
TypeScript
37 lines
1.3 KiB
TypeScript
// `panels.ts`, not `.tsx` — discovery checks for that exact name.
|
|
import type { AppRegistryMeta } from 'officerdev';
|
|
import { Globe, LayoutList, Plug } from 'lucide-react';
|
|
import { TabList } from './TabList';
|
|
import { TabPreview } from './TabPreview';
|
|
import { PairingPanel } from './PairingPanel';
|
|
|
|
// Two panels, both self-contained — they read their own data and take no props, which is why the screen
|
|
// that used to render them (`BrowserScreen.tsx`, with `appType: null` placeholders) had nothing to pass
|
|
// and could simply be deleted. The Workspace hosts them directly now.
|
|
export const appRegistryMetas: AppRegistryMeta[] = [
|
|
{
|
|
key: 'officerdev/browser-tabs',
|
|
name: 'Tabs',
|
|
icon: LayoutList,
|
|
component: TabList,
|
|
availableOnPanel: false,
|
|
},
|
|
{
|
|
// Pairing is a panel rather than a settings page, because it is not configuration you set once — it
|
|
// shows whether the extension is connected right now and how many tabs it holds, which is the first
|
|
// thing anyone looks at when a capture does not work.
|
|
key: 'officerdev/browser-pairing',
|
|
name: 'Pairing',
|
|
icon: Plug,
|
|
component: PairingPanel,
|
|
availableOnPanel: true,
|
|
},
|
|
{
|
|
key: 'officerdev/browser-preview',
|
|
name: 'Preview',
|
|
icon: Globe,
|
|
component: TabPreview,
|
|
availableOnPanel: false,
|
|
},
|
|
];
|