@codeworksh/plugin 0.3.0-canary.65.1.g856ff027 → 0.3.0-canary.66.1.gf4c14646

package/index.d.mts

@@ -1,4 +1,4 @@
 import { t as section_d_exports } from "./plugin/section.mjs";
 import { g as tool_d_exports } from "./tool-B4nkpC9M.mjs";
-import { t as plugin_d_exports } from "./plugin-Swbzia99.mjs";
+import { t as plugin_d_exports } from "./plugin-CZHbJIzN.mjs";
 export { plugin_d_exports as Plugin, section_d_exports as Section, tool_d_exports as Tool };

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@codeworksh/plugin",
-	"version": "0.3.0-canary.65.1.g856ff027",
+	"version": "0.3.0-canary.66.1.gf4c14646",
 	"description": "SDK for building CodeWork plugins — the plugin, tool, and sandbox contracts shared with @codeworksh/harness.",
 	"keywords": [
 		"agent",
@@ -168,7 +168,7 @@
 		"uuidv7": "^1.2.1"
 	},
 	"peerDependencies": {
-		"@codeworksh/aikit": "0.12.1-canary.65.1.g856ff027",
+		"@codeworksh/aikit": "0.12.1-canary.66.1.gf4c14646",
 		"effect": "4.0.5"
 	}
 }

package/{plugin-Swbzia99.d.mts → plugin-CZHbJIzN.d.mts}

@@ -48,7 +48,7 @@ interface Paths {
   readonly data: string;
   readonly log: string;
 }
-/** One object, shared by every plugin in one exchange. */
+/** One object, shared by every plugin in one turn. */
 interface SharedPluginContext {
   readonly sessionId: SessionID;
   readonly sandbox: Identity;
@@ -145,7 +145,7 @@ interface Plugin {
    * `options` is this plugin's own configuration block, `{}` when its entry carried none.
    * Unvalidated: the harness never looks inside it, so a plugin checks whatever shape it
    * documents. It is a second argument rather than a context field so `ctx` stays one object
-   * shared by every plugin in the exchange.
+   * shared by every plugin in the turn.
    */
   readonly setup: (ctx: SharedPluginContext, options: PluginOptions) => void | Promise<void> | Effect.Effect<void, unknown, Mount>;
 }
@@ -155,4 +155,4 @@ declare namespace plugin_d_exports {
 }
 //#endregion
 export { PluginRegistry as _, define as a, PluginOptions as c, PluginSpec as d, Config as f, SharedPluginContext as g, PromptResolver as h, PluginKind as i, PluginPatch as l, Paths as m, Mount as n, domains as o, Events as p, Plugin as r, rank as s, plugin_d_exports as t, PluginRef as u };
-//# sourceMappingURL=plugin-Swbzia99.d.mts.map
+//# sourceMappingURL=plugin-CZHbJIzN.d.mts.map

package/plugin-XaYYRsX-.mjs.map

@@ -1 +1 @@
-{"version":3,"file":"plugin-XaYYRsX-.mjs","names":[],"sources":["../../src/plugin/plugin.ts","../../src/plugin.ts"],"sourcesContent":["import type { Effect } from \"effect\";\nimport type { Definition } from \"../event.ts\";\nimport type { Service as LocationService } from \"../location.ts\";\nimport type { SandboxIO } from \"../sandbox/io.ts\";\nimport type { SharedPluginContext } from \"./context.ts\";\nimport type { PluginOptions } from \"./ref.ts\";\n\n/**\n * The domains a plugin can extend, and the order the harness runs them in.\n *\n * Order is declared, not positional. A plugin's place used to come from where its entry sat in\n * the `plugins` array, which is unknowable when the entry is written: a user's settings file and\n * a project's are edited by different people at different times, and neither can see the other's\n * order. Since a prompt plugin indexes the tools registered before it, that made a tool added\n * from settings invisible in the system prompt, with no way to fix it from a settings file.\n *\n * A plugin instead says which domain it extends, and the harness runs the domains in this order.\n * Entries within one domain keep the order they were written in, because that is where\n * composition actually happens -- a plugin patching another's tool, or appending to the prompt a\n * previous one rendered, is written next to it and deliberately after it.\n *\n * Kept as data so a later release can add a domain, or make the order configurable, without\n * touching the loader: `{ tool: 1, skill: 2, prompt: 3 }` needs no code change here.\n */\nexport const domains = { tool: 1, prompt: 2 } as const;\n\nexport type PluginKind = keyof typeof domains;\n\n/** Sort key for a plugin: its domain first, then where it was written. */\nexport const rank = (kind: PluginKind) => domains[kind];\n\nexport type Mount = SandboxIO.Provides | LocationService;\nexport interface Plugin {\n\treadonly id: string;\n\t/**\n\t * The domain this plugin extends, which decides when it runs: every `tool` plugin is set up\n\t * before any `prompt` plugin, whichever settings layer each came from, so a prompt plugin\n\t * always sees the complete tool set. Plugins within one domain run in the order they were\n\t * written.\n\t */\n\treadonly kind: PluginKind;\n\t/**\n\t * Event definitions this plugin publishes. Declared rather than registered at\n\t * runtime so they are known before the event system builds, and so a bad type\n\t * fails the boot instead of the first publish. Types must be namespaced\n\t * `plugin.<id>.*`.\n\t */\n\treadonly events?: ReadonlyArray<Definition>;\n\t/**\n\t * Off until a user asks for it. An `optIn` plugin is selected like any other but runs only\n\t * when a settings entry turns it on: `{ \"plugin\": \"<id>\", \"enabled\": true }`.\n\t */\n\treadonly optIn?: boolean;\n\t/**\n\t * `options` is this plugin's own configuration block, `{}` when its entry carried none.\n\t * Unvalidated: the harness never looks inside it, so a plugin checks whatever shape it\n\t * documents. It is a second argument rather than a context field so `ctx` stays one object\n\t * shared by every plugin in the exchange.\n\t */\n\treadonly setup: (\n\t\tctx: SharedPluginContext,\n\t\toptions: PluginOptions,\n\t) => void | Promise<void> | Effect.Effect<void, unknown, Mount>;\n}\n\nexport const define = (plugin: Plugin): Plugin => plugin;\n","/**\n * The plugin authoring surface.\n *\n * Everything a third-party plugin needs to describe itself and to write into the harness during\n * `setup`, and nothing about how the harness finds, installs or runs it. Loading, the store and\n * the `.npmrc` anchoring stay in `@codeworksh/harness`, which imports this same module — so a\n * plugin and its host agree on one set of types rather than two that happen to match.\n */\nexport type { Config, Events, Paths, PromptResolver, SharedPluginContext } from \"./plugin/context.ts\";\nexport { define, domains, type Mount, type Plugin, type PluginKind, rank } from \"./plugin/plugin.ts\";\nexport * as Prompt from \"./plugin/prompt.ts\";\nexport * as Section from \"./plugin/section.ts\";\nexport type { PluginOptions, PluginPatch, PluginRef, PluginSpec } from \"./plugin/ref.ts\";\nexport type { PluginRegistry } from \"./plugin/registry.ts\";\nexport * as Tool from \"./plugin/tool.ts\";\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;AAwBA,MAAa,UAAU;CAAE,MAAM;CAAG,QAAQ;AAAE;;AAK5C,MAAa,QAAQ,SAAqB,QAAQ;AAoClD,MAAa,UAAU,WAA2B"}
+{"version":3,"file":"plugin-XaYYRsX-.mjs","names":[],"sources":["../../src/plugin/plugin.ts","../../src/plugin.ts"],"sourcesContent":["import type { Effect } from \"effect\";\nimport type { Definition } from \"../event.ts\";\nimport type { Service as LocationService } from \"../location.ts\";\nimport type { SandboxIO } from \"../sandbox/io.ts\";\nimport type { SharedPluginContext } from \"./context.ts\";\nimport type { PluginOptions } from \"./ref.ts\";\n\n/**\n * The domains a plugin can extend, and the order the harness runs them in.\n *\n * Order is declared, not positional. A plugin's place used to come from where its entry sat in\n * the `plugins` array, which is unknowable when the entry is written: a user's settings file and\n * a project's are edited by different people at different times, and neither can see the other's\n * order. Since a prompt plugin indexes the tools registered before it, that made a tool added\n * from settings invisible in the system prompt, with no way to fix it from a settings file.\n *\n * A plugin instead says which domain it extends, and the harness runs the domains in this order.\n * Entries within one domain keep the order they were written in, because that is where\n * composition actually happens -- a plugin patching another's tool, or appending to the prompt a\n * previous one rendered, is written next to it and deliberately after it.\n *\n * Kept as data so a later release can add a domain, or make the order configurable, without\n * touching the loader: `{ tool: 1, skill: 2, prompt: 3 }` needs no code change here.\n */\nexport const domains = { tool: 1, prompt: 2 } as const;\n\nexport type PluginKind = keyof typeof domains;\n\n/** Sort key for a plugin: its domain first, then where it was written. */\nexport const rank = (kind: PluginKind) => domains[kind];\n\nexport type Mount = SandboxIO.Provides | LocationService;\nexport interface Plugin {\n\treadonly id: string;\n\t/**\n\t * The domain this plugin extends, which decides when it runs: every `tool` plugin is set up\n\t * before any `prompt` plugin, whichever settings layer each came from, so a prompt plugin\n\t * always sees the complete tool set. Plugins within one domain run in the order they were\n\t * written.\n\t */\n\treadonly kind: PluginKind;\n\t/**\n\t * Event definitions this plugin publishes. Declared rather than registered at\n\t * runtime so they are known before the event system builds, and so a bad type\n\t * fails the boot instead of the first publish. Types must be namespaced\n\t * `plugin.<id>.*`.\n\t */\n\treadonly events?: ReadonlyArray<Definition>;\n\t/**\n\t * Off until a user asks for it. An `optIn` plugin is selected like any other but runs only\n\t * when a settings entry turns it on: `{ \"plugin\": \"<id>\", \"enabled\": true }`.\n\t */\n\treadonly optIn?: boolean;\n\t/**\n\t * `options` is this plugin's own configuration block, `{}` when its entry carried none.\n\t * Unvalidated: the harness never looks inside it, so a plugin checks whatever shape it\n\t * documents. It is a second argument rather than a context field so `ctx` stays one object\n\t * shared by every plugin in the turn.\n\t */\n\treadonly setup: (\n\t\tctx: SharedPluginContext,\n\t\toptions: PluginOptions,\n\t) => void | Promise<void> | Effect.Effect<void, unknown, Mount>;\n}\n\nexport const define = (plugin: Plugin): Plugin => plugin;\n","/**\n * The plugin authoring surface.\n *\n * Everything a third-party plugin needs to describe itself and to write into the harness during\n * `setup`, and nothing about how the harness finds, installs or runs it. Loading, the store and\n * the `.npmrc` anchoring stay in `@codeworksh/harness`, which imports this same module — so a\n * plugin and its host agree on one set of types rather than two that happen to match.\n */\nexport type { Config, Events, Paths, PromptResolver, SharedPluginContext } from \"./plugin/context.ts\";\nexport { define, domains, type Mount, type Plugin, type PluginKind, rank } from \"./plugin/plugin.ts\";\nexport * as Prompt from \"./plugin/prompt.ts\";\nexport * as Section from \"./plugin/section.ts\";\nexport type { PluginOptions, PluginPatch, PluginRef, PluginSpec } from \"./plugin/ref.ts\";\nexport type { PluginRegistry } from \"./plugin/registry.ts\";\nexport * as Tool from \"./plugin/tool.ts\";\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;AAwBA,MAAa,UAAU;CAAE,MAAM;CAAG,QAAQ;AAAE;;AAK5C,MAAa,QAAQ,SAAqB,QAAQ;AAoClD,MAAa,UAAU,WAA2B"}

package/plugin.d.mts

@@ -1,5 +1,5 @@
 import { t as section_d_exports } from "./plugin/section.mjs";
 import { n as prompt_d_exports } from "./prompt-DWaA5ZXj.mjs";
 import { p as tool_d_exports } from "./tool-Bz8XyBlE.mjs";
-import { _ as PluginRegistry, a as define, c as PluginOptions, d as PluginSpec, f as Config, g as SharedPluginContext, h as PromptResolver, i as PluginKind, l as PluginPatch, m as Paths, n as Mount, o as domains, p as Events, r as Plugin, s as rank, u as PluginRef } from "./plugin-Swbzia99.mjs";
+import { _ as PluginRegistry, a as define, c as PluginOptions, d as PluginSpec, f as Config, g as SharedPluginContext, h as PromptResolver, i as PluginKind, l as PluginPatch, m as Paths, n as Mount, o as domains, p as Events, r as Plugin, s as rank, u as PluginRef } from "./plugin-CZHbJIzN.mjs";
 export { type Config, type Events, type Mount, type Paths, type Plugin, type PluginKind, type PluginOptions, type PluginPatch, type PluginRef, type PluginRegistry, type PluginSpec, prompt_d_exports as Prompt, type PromptResolver, section_d_exports as Section, type SharedPluginContext, tool_d_exports as Tool, define, domains, rank };