@chainingintention/pi-web-cn 1.202610.0 → 1.202610.2

package/examples/workspace-provider-plugin/src/browser/index.ts

@@ -0,0 +1,69 @@
+import type { JsonObject, PiWebPlugin, WorkspacePanelContext } from "@chainingintention/pi-web-cn/plugin-api";
+
+const summaries = new Map<string, string>();
+
+const plugin = {
+  apiVersion: 4,
+  name: "工作区提供器示例",
+  activate: ({ pluginId, runtimePluginId, html }) => ({
+    contributions: {
+      actions: [
+        {
+          id: "workspace.open",
+          title: "打开工作区提供器示例",
+          enabled: ({ state }) => state.selectedWorkspace?.provider?.pluginId === pluginId,
+          run: ({ selectWorkspaceTool }) => {
+            selectWorkspaceTool(`${runtimePluginId}:workspace.example-provider`);
+          },
+        },
+      ],
+      workspacePanels: [
+        {
+          id: "workspace.example-provider",
+          title: "提供器示例",
+          visible: ({ workspace }) => workspace.provider?.pluginId === pluginId,
+          render: (context) => {
+            const marker = stringMetadata(context.workspace.provider?.metadata, "marker") ?? "未知";
+            const summary = summaries.get(workspaceKey(context)) ?? "请从此包的服务端插件获取摘要。";
+            return html`
+              <section class="toolbar"><strong>工作区提供器示例</strong></section>
+              <section class="viewer">
+                <p>此工作区由 <code>${pluginId}</code> 提供。</p>
+                <p class="muted">接管标记：<code>${marker}</code></p>
+                <button
+                  ?disabled=${context.peer?.request === undefined}
+                  @click=${() => { void refreshSummary(context); }}
+                >获取包摘要</button>
+                <p aria-live="polite">${summary}</p>
+              </section>
+            `;
+          },
+        },
+      ],
+    },
+  }),
+} satisfies PiWebPlugin;
+
+export default plugin;
+
+async function refreshSummary(context: WorkspacePanelContext): Promise<void> {
+  const key = workspaceKey(context);
+  try {
+    if (context.peer?.request === undefined) throw new Error("插件后端不可用");
+    const result = await context.peer.request("summary", null);
+    if (typeof result !== "string") throw new Error("插件后端返回的摘要无效");
+    summaries.set(key, result);
+  } catch (error) {
+    summaries.set(key, error instanceof Error ? error.message : String(error));
+  }
+  context.host.requestRender();
+}
+
+function workspaceKey(context: WorkspacePanelContext): string {
+  return `${context.machine.id}:${context.workspace.id}`;
+}
+
+function stringMetadata(metadata: JsonObject | undefined, key: string): string | undefined {
+  const value = metadata?.[key];
+  return typeof value === "string" ? value : undefined;
+}

package/examples/workspace-provider-plugin/src/server.ts

@@ -0,0 +1,68 @@
+import { access } from "node:fs/promises";
+import { join } from "node:path";
+import type {
+  PiWebServerPlugin,
+  ProjectInput,
+  ProviderClaim,
+  ProviderWorkspace,
+  ServerPluginPeerRequestContext,
+  WorkspaceProvider,
+} from "@chainingintention/pi-web-cn/server-plugin-api";
+
+const markerPath = ".pi-web/example-workspace-provider";
+
+const plugin: PiWebServerPlugin = {
+  apiVersion: 3,
+  name: "工作区提供器示例",
+  activate({ pluginId, logger }) {
+    logger.info("激活工作区提供器示例", { pluginId });
+    return {
+      workspaceProvider: createWorkspaceProvider(),
+      peer: { request: (context) => requestSummary(pluginId, context) },
+    };
+  },
+};
+
+export default plugin;
+
+function createWorkspaceProvider(): WorkspaceProvider {
+  return {
+    async probe(project: ProjectInput, signal: AbortSignal): Promise<ProviderClaim> {
+      signal.throwIfAborted();
+      try {
+        await access(join(project.path, markerPath));
+        signal.throwIfAborted();
+        return "claim";
+      } catch (error) {
+        if (isMissingFile(error)) return "pass";
+        throw error;
+      }
+    },
+    async list(project: ProjectInput, signal: AbortSignal): Promise<ProviderWorkspace[]> {
+      signal.throwIfAborted();
+      return [{
+        key: "main",
+        path: project.path,
+        label: project.name,
+        isMain: true,
+        // This object is visible to every browser script and API consumer.
+        publicMetadata: { kind: "example", marker: markerPath },
+      }];
+    },
+  };
+}
+
+function requestSummary(pluginId: string, context: ServerPluginPeerRequestContext): string {
+  context.signal.throwIfAborted();
+  if (context.operation !== "summary") {
+    throw new Error(`不支持的示例工作区操作：${context.operation}`);
+  }
+  return `${pluginId} 提供工作区 ${context.workspace.label}，路径：${context.workspace.path}`;
+}
+
+function isMissingFile(error: unknown): boolean {
+  return typeof error === "object"
+    && error !== null
+    && "code" in error
+    && Reflect.get(error, "code") === "ENOENT";
+}

package/examples/workspace-provider-plugin/tsconfig.json

@@ -0,0 +1,21 @@
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "NodeNext",
+    "moduleResolution": "NodeNext",
+    "lib": ["ES2022", "DOM"],
+    "types": ["node"],
+    "rootDir": "src",
+    "outDir": "dist",
+    "strict": true,
+    "exactOptionalPropertyTypes": true,
+    "noUncheckedIndexedAccess": true,
+    "noImplicitReturns": true,
+    "noFallthroughCasesInSwitch": true,
+    "forceConsistentCasingInFileNames": true,
+    "verbatimModuleSyntax": true,
+    "skipLibCheck": false,
+    "noEmitOnError": true
+  },
+  "include": ["src/**/*.ts"]
+}

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@chainingintention/pi-web-cn",
-  "version": "1.202610.0",
-  "description": "Remote web UI and browser control plane for persistent Pi Coding Agent sessions.",
+  "version": "1.202610.2",
+  "description": "Web UI for persistent Pi Coding Agent sessions in real workspaces.",
   "license": "MIT",
   "author": "Federico Jaramillo Martinez",
   "type": "module",
@@ -10,7 +10,8 @@
       "types": "./dist/plugin-api.d.ts"
     },
     "./server-plugin-api": {
-      "types": "./dist/server-plugin-api.d.ts"
+      "types": "./dist/server-plugin-api.d.ts",
+      "import": "./dist/server-plugin-api.js"
     }
   },
   "typesVersions": {
@@ -37,6 +38,10 @@
     "skills/relay/SKILL.md",
     "skills/relay-runner/SKILL.md",
     "extensions",
+    "examples/workspace-provider-plugin",
+    "examples/session-bridge-plugin",
+    "!examples/**/node_modules",
+    "!examples/**/dist",
     "docs/plugins.md",
     "docs/config.md",
     "docs/assets",
@@ -45,8 +50,8 @@
   ],
   "scripts": {
     "dev": "bash -c 'trap \"kill 0\" EXIT; npm run dev:sessiond & npm run dev:web & npm run dev:client & wait'",
-    "dev:sessiond": "tsx watch src/server/sessiond.ts",
-    "dev:web": "bash -c 'set -e; npm run build:plugins; trap \"kill 0\" EXIT; npm run dev:plugins & tsx watch src/server/index.ts & wait'",
+    "dev:sessiond": "node scripts/dev-sessiond.mjs --watch",
+    "dev:web": "tsc -p tsconfig.plugins.json && node scripts/dev-web.mjs",
     "dev:server": "npm run dev:web",
     "dev:client": "vite --host 0.0.0.0",
     "dev:plugins": "node scripts/build-plugins.mjs --watch",
@@ -58,12 +63,13 @@
     "typecheck": "tsc --noEmit",
     "typecheck:cached": "tsc --noEmit --incremental --tsBuildInfoFile node_modules/.cache/pi-web/typecheck.tsbuildinfo",
     "knip": "knip",
-    "lint": "eslint \"src/**/*.ts\" \"extensions/**/*.ts\" \"pi-web-plugins/**/*.ts\" \"pi-packages/**/*.ts\" vite.config.ts vitest.config.ts",
+    "lint": "eslint \"src/**/*.ts\" \"extensions/**/*.ts\" \"pi-web-plugins/**/*.ts\" \"pi-packages/**/*.ts\" vite.config.ts vitest.config.ts vitest.artifacts.config.ts",
     "test": "vitest run --config vitest.config.ts",
+    "check:artifacts": "vitest run --config vitest.artifacts.config.ts",
     "verify": "npm run typecheck && npm run lint && npm run knip && npm test",
     "verify:staged": "node scripts/verify-staged.mjs",
     "start": "tsx src/server/index.ts",
-    "start:sessiond": "tsx src/server/sessiond.ts",
+    "start:sessiond": "node scripts/dev-sessiond.mjs",
     "clean": "node -e \"require('node:fs').rmSync('dist', { recursive: true, force: true })\"",
     "prepack": "npm run build",
     "pack:dry": "npm pack --dry-run",
@@ -100,23 +106,26 @@
     "marked": "^18.0.6",
     "node-pty": "^1.1.0",
     "typebox": "1.3.7",
+    "undici": "^8.5.0",
     "ws": "^8.21.0",
     "yauzl": "^3.4.0"
   },
   "devDependencies": {
     "@changesets/cli": "^2.31.0",
-    "@earendil-works/pi-agent-core": "0.86.1",
-    "@earendil-works/pi-ai": "0.86.1",
-    "@earendil-works/pi-coding-agent": "0.86.1",
+    "@earendil-works/pi-agent-core": "0.87.0",
+    "@earendil-works/pi-ai": "0.87.0",
+    "@earendil-works/pi-coding-agent": "0.87.0",
     "@eslint/js": "^10.0.1",
     "@types/node": "^24.13.3",
     "@types/ws": "^8.18.1",
     "@types/yauzl": "^2.10.3",
     "@types/yazl": "^2.4.6",
+    "dompurify": "^3.4.15",
     "eslint": "^10.6.0",
     "globals": "^17.7.0",
     "happy-dom": "^20.11.1",
     "knip": "^6.25.0",
+    "mermaid": "^11.17.2",
     "tsx": "^4.23.0",
     "typescript": "^6.0.3",
     "typescript-eslint": "^8.63.0",
@@ -140,9 +149,9 @@
   "homepage": "https://github.com/nayuto-wakusei/pi-web-ChineseTranslation#readme",
   "packageManager": "npm@11.11.0",
   "peerDependencies": {
-    "@earendil-works/pi-agent-core": "0.86.1",
-    "@earendil-works/pi-ai": "0.86.1",
-    "@earendil-works/pi-coding-agent": "0.86.1"
+    "@earendil-works/pi-agent-core": "0.86.1 || 0.87.0",
+    "@earendil-works/pi-ai": "0.86.1 || 0.87.0",
+    "@earendil-works/pi-coding-agent": "0.86.1 || 0.87.0"
   },
   "keywords": [
     "pi-package",

package/skills/README.md

@@ -4,9 +4,34 @@ Distributable agent skills developed alongside pi-web.
 
 ## relay
 
-Execute a long or complex plan as a chain of independent sessions, each running
-one well-sized leg and handing off to the next via `spawn_session`.
+A tool-agnostic foundation for the [Relay Principle](https://relayprinciple.ai/):
+carry long work through a chain of fresh agent contexts, one bounded leg and one
+durable handoff at a time, without a standing coordinator or role hierarchy.
+It defines the method's concepts and invariants but leaves tools and ways of
+working to an operational profile.
 
 ```bash
 npx skills add jmfederico/pi-web --skill relay -a pi -g
 ```
+
+## relay-runner
+
+The opinionated operational profile used by PI WEB's `/relay` preparation
+prompt. The prompt first establishes a shared understanding and obtains explicit
+human approval without pre-planning the chain; this profile then binds the base
+method to Pi session tools and a Git/software-delivery workflow,
+including adaptive leg sizing, verification and commit policy, whole-work
+review and remediation, delivery, and intervention. Dispatch and handoff
+prompts select both skills before each fresh runner begins.
+
+```bash
+npx skills add jmfederico/pi-web --skill relay-runner -a pi -g
+```
+
+`relay-runner` is not standalone; install the base `relay` skill as well when
+using these commands directly. The `relays` Pi package ships and installs both
+skills atomically. Its files under
+`pi-packages/relays/skills/` are symlinks to the canonical `SKILL.md` files in
+this directory; the package build (`npm run build:plugins`, or the dev watch)
+materializes them as real packaged files. Edit the canonical copies here, not
+the package links.

package/skills/relay-runner/SKILL.md

@@ -15,6 +15,7 @@ For a Relay using this profile:
 
 - Have the preparation prompt select `relay-runner` before drafting the packet. Record it immediately in draft `operations.md` and retain it as required for every active leg, including implementation, review, remediation, and delivery.
 - Name both `relay` and `relay-runner` in every handoff prompt. Fresh sessions cannot inherit a prior runner's loaded skills.
+- Keep every Relay handoff on the current runner's model by omitting the `model` argument, unless instructed to use a specific model or to choose an appropriate one. Record any Relay-wide model instruction in `operations.md` so it remains available to later runners.
 - Treat the charter as destination and scope edges, `operations.md` as this profile's repository and execution bindings, `status.md` as current position and next work, and repository instructions as the quality and implementation authority.
 - Follow canonical repository policy when it conflicts with a profile default. Record a material operational adaptation in `operations.md`, not the charter. Stop for human intervention when reconciling the conflict would change the finish line or an edge, weaken a protected invariant, or require a product or business decision.
 
@@ -53,19 +54,26 @@ Relay intentionally does not predict the chain. Before dispatch, establish the d
 
 Expected files, subsystems, dependencies, architecture, and sequencing are route assumptions. Keep only what the current or next leg needs in status or a targeted temporary artifact; do not turn route assumptions into stable agreement.
 
-A leg is one context-contained, reviewable slice that leaves coherent durable progress toward the finish line. Prefer a functional, locally verifiable checkpoint. Keep directly coupled implementation, tests or manual checks, contracts, generated outputs, documentation, and integration glue together. Split independent responsibilities rather than splitting mechanically by file or repository layer.
+A leg is one context-contained, reviewable slice that advances the finish line. Development legs implement and verify by default: optimize for the smallest useful behaviour, not the smallest independently testable artifact. A functional checkpoint makes an observable charter outcome available and verifies it through the relevant application boundary. A tested but unused module is a prerequisite, not a functional outcome. Setup, required verification, review and delivery remain legitimate lifecycle legs.
+
+Slice by supported cases across the necessary layers. When a journey is too large, choose a narrower case or a safe partial capability with explicit limitations, keeping the full charter outstanding. Keep directly coupled implementation, checks, contracts, generated outputs, documentation and integration together.
 
 Before substantial work, state the leg's:
 
-- bounded outcome;
-- primary responsibility and expected change surface;
-- coupled verification;
-- deferred dependencies; and
-- checkpoint type: functional or profile-authorized transitional.
+- observable outcome and application boundary;
+- bounded change surface and coupled verification;
+- remaining connection to usable behaviour, if any; and
+- checkpoint type: functional, necessary prerequisite or profile-authorized transitional.
+
+An unconnected prerequisite must name the behaviour it enables and why a connected slice cannot reasonably fit. Its successor prioritizes that connection. Before adding another prerequisite-only leg, reassess the slice and simplify the route; continue only when a concrete dependency still prevents connection.
+
+Routine reading, design, sizing and test investigation belong inside implementation. A research-only leg requires a specific unanswered question blocking responsible implementation: record the blocked behaviour, why available evidence is insufficient and the result needed to proceed. Answer that question and hand off to implementation; intervene if it remains unresolved. Size or complexity alone calls for a smaller implementation slice.
+
+Choose the simplest design satisfying the charter, canonical project rules and concrete risks introduced by the change. Justify additional safeguards against those obligations; keep speculative recovery systems and future-use abstractions outside the slice. Preserve safety when narrowing behaviour.
 
-Persist only conclusions useful to the next runner. If uncertainty prevents responsible sizing, run a bounded discovery leg with a concrete question and durable result instead of mixing broad archaeology with implementation.
+Persist only conclusions useful to the next runner. Keep leg history in the packet log and project documentation focused on current behaviour and contracts.
 
-If a leg grows beyond its context-contained slice, stop broadening before context exhaustion. Finish or revert to a functional checkpoint, or use an already authorized transition. Record the next bounded slice. Do not promise a fixed total leg count.
+If a leg grows beyond its context-contained slice, stop broadening before context exhaustion. Finish or revert to a coherent functional or justified prerequisite checkpoint, or use an already authorized transition. Record the next bounded slice. Do not promise a fixed total leg count.
 
 When status does not name the next task, choose the smallest coherent slice that advances the critical path or unblocks an agreed outcome. Do not invent cleanup or speculative follow-up merely to fill a leg.
 
@@ -130,7 +138,7 @@ Do **not** put a quality bar, technical design, expected files or subsystems, ve
 Write the profile's mechanics to `operations.md` instead:
 
 - packet identity and `relay-runner` as the profile required in every leg and handoff;
-- adaptive leg sizing and critical-path task selection, with route assumptions provisional and no fixed leg count;
+- implementation-first leg sizing and outcome-led task selection under this profile, with route assumptions provisional and no fixed leg count;
 - pointers to canonical repository instructions and applicable project skills;
 - checkpoint and transition policy;
 - packet root, working location, branch, immutable base commit, initial HEAD, pre-existing state, packet isolation, and exact review range;
@@ -158,11 +166,11 @@ Use this loop:
 
 1. Read `charter.md`, `operations.md`, `status.md`, and only targeted context they reference. Then load canonical project skills applicable to this leg.
 2. Confirm that the prompt's leg identifier, status baton, working location, branch, and blockers are consistent. Resolve small baton defects with targeted inspection; intervene instead of broad archaeology or guessing about intent.
-3. Choose the explicit next task from status when it fits the charter and leg size. Otherwise apply the operations record's critical-path task-selection policy. If the task remains ambiguous or falls outside the finish line, intervene.
+3. Use status's next outcome as the starting point. Revise inherited sequencing or design when a simpler connected slice better advances it. Safe implementation splits within the charter are runner decisions, not approval requests. If the intended outcome remains ambiguous or falls outside the finish line, intervene.
 4. Re-anchor to the finish line and perform the containment check. Do exactly one bounded slice. Do not audit unrelated code, execute the next nominal leg too, or expand scope under the guise of quality.
 5. Run every focused check meaningful for the slice and report exact results. Before whole review, run the full verification named by `operations.md`. Never describe failed, skipped, or incomplete verification as passing.
 6. Make delivery changes durable under the operations record's commit policy without absorbing unrelated state. Keep packet-only writes out of delivery commits.
-7. Update status with the new position, completed and next leg identifiers, next task or selection pointer, targeted context, verification state, blockers, and active transition/review pointers. Append the concise leg entry to the log before stopping or handing off.
+7. Update status with the observable progress, completed and next leg identifiers, next outcome, existing seam to connect, concrete constraints, remaining unconnected work, targeted context, verification state, blockers and active transition/review pointers. Keep route choices provisional. Append the concise leg entry to the log before stopping or handing off.
 8. Stop without spawning when Relay completion is recorded, the leg is blocked, or an intervention trigger fires. When the chartered outcome is implemented but required review, approval, or delivery remains, name that lifecycle work as the next leg instead of stopping. Surface the intervention signal clearly. Otherwise hand off exactly once at the end with `spawn_session`.
 
 Use this handoff shape, substituting the actual paths and next identifier:
@@ -177,7 +185,7 @@ Load the `relay` and `relay-runner` skills, then read:
 - .pi-web/relays/<name>/status.md
 
 Do not read log.md end-to-end. Use only targeted entries referenced by charter.md, operations.md, or status.md.
-Run exactly one leg, make its work and packet updates durable, then either hand off once or stop with the recorded intervention signal.
+Run exactly one outcome-led leg under the profile's implementation-first rules. Use status's next outcome and connection priority; adapt the route within the charter. Make work and packet updates durable, then either hand off once or stop with the recorded intervention signal.
 ```
 
 ## Whole-work review and remediation
@@ -200,7 +208,7 @@ For each attempt:
 - When attempt 2 has a blocking finding, do not automatically consume attempt 3. Invoke the remediation contingency only when concrete evidence shows that an attempted remediation reasonably expected to resolve a blocker did not, remediation introduced an in-scope regression, or materially new evidence reveals a blocker that could not reasonably have been assessed earlier—and one bounded remediation is likely to resolve it. Record that justification, mark the contingency invoked, and dispatch one coherent remediation leg followed by attempt 3. Expanded scrutiny, a changed standard, deferred already-available evidence, or speculative possibility does not qualify. If a genuine blocker remains but the contingency is not justified or bounded, intervene.
 - When exceptional attempt 3 still has any blocking finding, stop the automatic loop. Record the unresolved findings and exact decision needed, raise the human intervention signal, and do **not** dispatch remediation or a fourth review. A human may accept an authorized risk, change the agreement, stop the Relay, or explicitly grant a bounded additional remediation/review attempt.
 
-The reviewer chooses proportionate independent review and records that decision. Independent subreviews are optional; use them only when a specific changed surface benefits from focused expertise, not to create review theater or increase the chance of finding something. The reviewer may use `spawn_subsession` for report-only focused reviews, then `yield_to_subsessions` and consolidate. Subreview prompts must identify repository, base and exact diff, the charter's goal and edges, canonical quality instructions, and the prohibition on all writes including packet changes. The consolidating reviewer is the sole packet writer. Do not assume a particular model is available. The Relay handoff still uses one `spawn_session` only at the end of the leg.
+The reviewer chooses proportionate independent review and records that decision. Independent subreviews are optional; use them only when a specific changed surface benefits from focused expertise, not to create review theater or increase the chance of finding something. The reviewer may use `spawn_subsession` for report-only focused reviews, then `yield_to_subsessions` and consolidate. Subreview prompts must identify repository, base and exact diff, the charter's goal and edges, canonical quality instructions, and the prohibition on all writes including packet changes. The consolidating reviewer is the sole packet writer. The Relay handoff still uses one `spawn_session` only at the end of the leg.
 
 A blocking finding needs concrete evidence of an in-scope defect: for example a reproduced failure, a failing relevant check, a specific execution path that violates the approved outcome, or a clear breach of a material contract, invariant, security, authorization, or data-integrity boundary. Mere possibility, stylistic preference, optional hardening, hypothetical future requirements, or “there could be an edge case” is not blocking. If proportionate targeted inspection cannot establish applicability and impact, classify the concern as non-blocking or omit it rather than forcing remediation.
 

package/dist/client/assets/CodeViewer-CZHnKRwQ.js

@@ -1,4 +0,0 @@
-import{$ as e,J as t,P as n,S as r,Y as i,l as a,q as o,y as s}from"./vendor-editor-core-vUi74DnD.js";import{c,i as l,l as u,n as d,r as f,s as p,t as m,u as h}from"./vendor-editor-languages-DoaXUodB.js";import{_ as g,f as _,g as v,m as y,n as b,p as x,u as S}from"./index-Bv1v-Jz7.js";import{t as C}from"./vendor-editor-legacy-CYBnW6ZU.js";var w=class extends y{constructor(...e){super(...e),this.content=``}firstUpdated(){this.recreateEditor()}updated(e){(e.has(`content`)||e.has(`language`))&&this.recreateEditor()}disconnectedCallback(){this.view?.destroy(),this.view=void 0,super.disconnectedCallback()}render(){return v`<div class="host"></div>`}recreateEditor(){this.editorHost&&(this.view?.destroy(),this.view=new o({parent:this.editorHost,state:e.create({doc:this.content,extensions:[i(),t.of(a),n(r,{fallback:!0}),e.readOnly.of(!0),o.editable.of(!1),o.lineWrapping,T,...D(this.language),...O(this.language)]})}))}static{this.styles=g`
-    :host { display: block; min-height: 0; height: 100%; }
-    .host { height: 100%; min-height: 0; overflow: auto; }
-  `}};b([_()],w.prototype,`content`,void 0),b([_()],w.prototype,`language`,void 0),b([S(`.host`)],w.prototype,`editorHost`,void 0),w=b([x(`code-viewer`)],w);var T=o.theme({"&":{height:`100%`,color:`var(--pi-text)`,backgroundColor:`var(--pi-bg)`,fontSize:`12px`},".cm-scroller":{fontFamily:`ui-monospace, SFMono-Regular, Menlo, Consolas, monospace`,lineHeight:`1.45`},".cm-gutters":{backgroundColor:`var(--pi-bg)`,color:`var(--pi-dim)`,borderRight:`1px solid var(--pi-border-muted)`},".cm-activeLineGutter":{backgroundColor:`transparent`},".cm-activeLine":{backgroundColor:`transparent`},".cm-content":{caretColor:`transparent`},"&.cm-focused":{outline:`none`}}),E=o.theme({".cm-content":{textAlign:`start`},".cm-line":{unicodeBidi:`plaintext`}});function D(e){return e===`markdown`?[o.contentAttributes.of({dir:`auto`}),E]:[]}function O(e){if(e===void 0)return[];switch(e){case`typescript`:return[u({typescript:!0})];case`javascript`:return[u()];case`json`:return[l()];case`markdown`:return[p()];case`css`:return[h()];case`html`:return[c()];case`python`:return[f()];case`rust`:return[d()];case`go`:return[m()];case`diff`:return[s.define(C)];default:return[]}}export{w as CodeViewer};