feat: language and jurisdictions metadata in .mikeworkflow.json packs

[amal66]

Summary

Workflows can now be exported to and imported from portable .mikeworkflow.json files, and those files carry optional language and jurisdictions metadata alongside title, type, prompt, columns, and practice area. A firm can share e.g. a French-law NDA review workflow and have it arrive tagged correctly; older files without the new fields import cleanly with stable defaults (English / ["General"]) — the format stays version 1, no breaking change.

Changes

• backend/src/lib/workflowFormat.ts — new module: the zod workflowPackSchema is the single source of truth for the .mikeworkflow.json format (format version 1, strict top level, forward-compatible loose columns), including the optional nullable language (string) and jurisdictions (string array) fields; plus describeWorkflowPackIssues (human-readable validation errors) and buildWorkflowPackJsonSchema (draft-07 JSON Schema envelope with examples).
• backend/src/routes/workflows.ts — new exportWorkflow/importWorkflow (exported for tests) and two routes: GET /workflows/:workflowId/export (owner-only download, safe filename) and POST /workflows/import (validates against the schema, inserts a fresh workflow; language/jurisdictions normalized to the existing DEFAULT_WORKFLOW_LANGUAGE / DEFAULT_WORKFLOW_JURISDICTIONS defaults when omitted, via the file's existing normalizeOptionalString/normalizeJurisdictions).
• schemas/workflow.schema.json — the published schema for external tooling, generated from the zod source (never hand-edited).
• backend/scripts/generate-workflow-schema.ts + generate:workflow-schema npm script — the generator that writes it.
• backend/tests/workflowFormat.test.ts — drift check (published JSON must deep-equal the zod-derived schema; examples must validate) plus validation-behavior tests including the metadata fields; backend/tests/workflows.import-metadata.test.ts — import stores explicit metadata and applies the defaults to legacy packs. Tests live under backend/tests/ so they are outside the tsc build's src include; they run under the vitest harness.

Why

Workflows are the unit of legal know-how in Mike, but they were locked inside one deployment. A single-file interchange format makes them shareable and versionable, and language/jurisdiction tags are the metadata a legal workflow most needs to travel with it. Deriving the published JSON Schema from the same zod schema the import endpoint enforces (with a drift test) guarantees the documented contract and the actual API can never disagree.

Testing

• cd backend && npm install && npm run build — green as committed.
• cd backend && npm run generate:workflow-schema — regenerates schemas/workflow.schema.json byte-identical to the committed file.
• With the vitest harness branch (upstream-pr/test-harness) merged locally (one trivial package.json scripts-block conflict, kept both lines): cd backend && npm test → 3 files, 25 tests passed (13 of them from this PR).
• Frontend untouched; not verified end-to-end against a live Supabase stack in this environment.

Provenance

All changes are mechanical ports of code in amal66/mike@origin/main (commit b3166dd) plus the metadata delta from #18 (branch feat/workflow-metadata, the fork's language/jurisdictions commit): apps/api/src/modules/workflows/workflowFormat.ts → backend/src/lib/workflowFormat.ts; workflows.service.ts exportWorkflow/importWorkflow and workflows.routes.ts export/import routes → backend/src/routes/workflows.ts (this repo already has the Db type, asyncRoute, withDatabaseWorkflow, normalizers, and default constants those functions use); apps/api/scripts/generate-workflow-schema.ts → backend/scripts/generate-workflow-schema.ts; schemas/workflow.schema.json regenerated from the zod source; both test files ported with path-only adjustments. Exceptions: (1) zod import changed from "zod" to "zod/v4" — this repo pins zod ^3.25.76, which ships the v4 API (strictObject/looseObject/z.iso/z.toJSONSchema) under that subpath; the regenerated schema consequently differs from the fork's only in JSON key order; (2) comment/$id-adjacent path strings updated for the backend/ layout, and the schema description's reference to the fork-only docs/workflows.md dropped; (3) the fork's logger call in its routes has no equivalent here — the existing console.error-based error handler in routes/workflows.ts is unchanged and covers these routes.

Credits & prior art

• @rafal-fryc (upstream #59) — builds on the proposal in feat(workflows): add JSON file download/upload for workflow transfer Open-Legal-Products/mike#59, which pioneered .mikeworkflow.json workflow export/import (client-side download/upload). The fork's original portability commit records feat(workflows): add JSON file download/upload for workflow transfer Open-Legal-Products/mike#59 as its precedent, and the file extension and interchange goal come straight from that PR; this PR moves the format server-side behind a zod schema.
• @amiel-35 (upstream #34) — builds on the proposal in feat: local LLM support via Ollama (OpenAI-compatible, behind ENABLE_OLLAMA) #34, a docs-only declarative workflow-pack schema (schemas/workflow.schema.json, docs/workflows.md). The fork's pack-format commit records feat: local LLM support via Ollama (OpenAI-compatible, behind ENABLE_OLLAMA) #34 as its precedent; this PR ships the same artifact path (schemas/workflow.schema.json), generated from the zod source of truth so the published contract can't drift.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CEguyEgXa9JjCciXCcVemC