Export and import a workspace's overrides and rules

[olehwebdev]

What and why

Implements U13 (roadmap M2): share a workspace's overrides with a teammate, or copy them to another workspace.

• Export overrides and rules… saves the active workspace's overrides and rules as one JSON file. The dialog suggests a name after the page's host (shop.test-overrides.json).
• Import overrides and rules… adds a file's overrides and rules to the active workspace:
  • It adds only what the workspace doesn't have yet, so your own versions are kept.
  • It leaves out entries it can't read.
  • The toast says what was added and left out. The page reloads as it does after a save, if that setting is on.
• Both are in a new menu on the Explorer's Overrides section and in the palette. The palette's export item shows only when there is something to export.

How it works:

• File format (src/main/overridesFile/): { format: 'console-editor-overrides', version: 1, overrides, rules }.
  • Each override carries its kind, source URL, match, on/off, originalHash, a response override's request and response settings, its content, and its base when that differs. Diffs and Patch live need the base.
  • Rules are CreateRuleInput plus enabled.
  • Nothing carries ids or times; the importing store sets them.
• Reading a file (per CLAUDE.md › Forms and validation): the envelope and each override are read with Zod schemas in src/shared/overrides, bound with z.toZod to the types in src/shared/types/overridesFile.ts.
  • overridesFileSchema, through parseInput, takes the format, a version this build reads (a newer one is refused, with a word to update the app), and at most 500 overrides. The file must be at most 200 MB.
  • exportedOverrideSchema checks each override: a known kind, an http(s) source URL, a usable matcher, a SHA-256 or null. A response override's request and response settings are then checked as the store checks them (responseFieldsOf).
  • Rules are checked with ruleInputSchema.
• What "already there" means: for an override, the same kind, matcher and, for a response override, method and GraphQL operation (sameOverrideTarget); for a rule, sameRuleInput. A file listing one twice adds it once.
• After an import: entries are created in order, and those that were off are turned off. overrides-changed and rules-changed are sent even when a later entry fails, such as a rule refused because the workspace already holds 200.
• Rule order: rules apply oldest first, and two with the same createdAt were ordered by their random ids. An import creates its rules within one millisecond, so they could come out in either order (CI caught this). addRule now puts a rule made in the same millisecond as another of its workspace one past the newest. Otherwise the clock's time stands, as before.
• Moves and splits:
  • MAX_URL_CHARS moved from src/main/ipc/constants.ts to src/shared/constants.ts, since the shared schema needs it too.
  • The palette's "Open the overrides folder" item moved, with the two new ones, to overrideFileItems.ts, to keep AppCommandPalette under 150 lines.
  • The new renderer slice is features/override/share; an ungrouped slice would have gone over steiger's limit of 20.
  • pathFileName (a file path's name, for the toast) lives in shared/lib/url, since shared/lib is at its module limit.

main, with #29 (the external editor), is merged in (not rebased). Only docs, registerIpc.ts and an e2e import line conflicted: both sides added a line, and both are kept.

How it was tested

• Unit (test/unit/overridesFile.test.ts):
  • what an export holds: only the active workspace's, a base only when it differs, no ids;
  • the file name;
  • a round trip into another workspace, with the clock frozen as in a fast import: content, base, response settings, on/off, and rules in their order;
  • an import keeps what the workspace has, and adds a duplicated entry once;
  • response overrides are told apart by method and operation;
  • ten kinds of unreadable entry are counted;
  • the file is refused when it isn't JSON, isn't an export, comes from a newer version, or lists too many overrides.
• Rule store (test/unit/ruleStore.test.ts): rules made in one millisecond keep their order, even when their ids sort the other way.
• Renderer (test/renderer/share-overrides.test.ts): the toast texts, the reload after an import, and what happens when the dialog is cancelled or the import fails.
• E2E (test/e2e/app.e2e.test.ts), with the native dialogs stubbed as the HAR test does:
  • export the first workspace's four overrides;
  • import them into the second workspace, whose page then runs the edited script;
  • importing again adds nothing.

Checklist

• Comes from a git flow branch (feature/…, bugfix/…) into main, and does one thing
• npm run typecheck, npm run lint:fsd, npm run lint:structure, npm run lint, npm run lint:unused, npm run lint:duplicates, npm run lint:secrets, npm test and npm run test:e2e pass on the merged tree (1207 unit, 111 e2e)
• docs/SPEC.md describes any behaviour this changes (§2, §5 Sharing, §8, §11)
• User-visible changes are noted under [Unreleased] in CHANGELOG.md