AI 原生开放教材

外观

Better Harness（QoderAI）工程手册·英文原文 ↗原件 ↓仓库 ↗

External Artifact provider modules ​

Traceability ​

  • Spec ID: external-artifact-provider-modules
  • Status: Implemented

Intent ​

Let an operator run a separately published Artifact Provider in Harness Studio without copying its renderer or adapter into Studio. The host owns module loading and Provider validation; the external package owns format semantics and its receipt-bound implementation.

Acceptance Scenarios ​

  • AC-1: Repeated --artifact-provider-module <specifier> options load the module's createArtifactProvider() result and inject it through Studio's existing external Provider registry.
  • AC-2: Relative module paths resolve from --cwd, package specifiers resolve through Node, and URL/builtin/empty/duplicate/over-budget inputs fail before Studio opens a port.
  • AC-3: A real published Homology Notebook Provider can be activated and render an .ipynb through the generic hosted surface; Studio does not import the Provider's private renderer or adapter files.
  • AC-4: Help, TypeScript build, focused unit/server tests, and a clean packed cross-repository consumer prove the integration boundary.

Non-goals ​

  • Downloading or installing Provider packages from the Studio UI.
  • Granting an untrusted module a sandbox; module loading is an explicit operator-authorized local-code action.
  • Moving Notebook or kernel execution semantics into Better Harness.
  • Automatically activating a contribution without the existing fingerprint- bound activation record.

Plan and Tasks ​

  • Add a bounded Node module loader beside Artifact Provider discovery.
  • Add a repeatable CLI option and pass loaded Providers through the existing artifactProviders embedding seam.
  • Declare the Homology Provider as an optional peer integration after it has a public npm identity; keep Studio independently runnable without it.
  • Test parsing, path/package resolution, failure closure, registry status, and the real cross-repository package lane.

Test and Review Evidence ​

  • AC-1/AC-2: focused Vitest for loader and CLI behavior.
  • AC-3: Homology clean-consumer tarballs plus Harness Studio server/browser E2E.
  • AC-4: Node 24 package build/test/pack and Review Readiness Check.
  • Risk: loaded modules execute with the Studio process authority. The CLI help and spec identify this as an operator-provisioned local-code boundary; no browser-controlled module specifier is accepted.
  • Implemented evidence: Node 24 Studio build and 46 files/270 Vitest tests; generic external-host Playwright 1/1; Homology's packed-provider browser E2E loaded the public factory, verified/activated its receipt, rendered Markdown plus stored output, and reported 0 console/page errors.