ns-omp-provider 0.3.1 → 0.4.0

package/CHANGELOG.md

@@ -1,5 +1,18 @@
 # Changelog
 
+## 0.4.0
+
+Bundles `@ngosangns/ns-pi-provider@0.3.0`.
+
+Moved into the [ns-bridge](https://github.com/ngosangns/ns-bridge) monorepo; bundles the
+workspace `@ngosangns/ns-pi-provider` (see its changelog: Kiro and Devin now run on the
+shared `ns-kiro-core` / `ns-devin-core`).
+
+- The opt-in `kiro` now logs in from the kiro-cli / Kiro IDE session, like
+  `ns-omp-provider-kiro`.
+- Build: the `kiroRootPlugin` esbuild shim is gone — it only existed for the Pi
+  adapter's former vendored Kiro code.
+
 ## 0.3.1
 
 Bundles `@ngosangns/ns-pi-provider@0.2.2`.

package/README.md

@@ -1,16 +1,17 @@
 # ns-omp-provider
 
 [OMP](https://omp.sh) (oh-my-pi) plugin that exposes the **Kiro**, **Devin**, and
-**Grok** providers from [`@ngosangns/ns-pi-provider`](https://github.com/ngosangns/ns-pi-provider).
+**Grok** providers from [`@ngosangns/ns-pi-provider`](../pi-provider), part of
+[ns-bridge](https://github.com/ngosangns/ns-bridge).
 
 `ns-pi-provider` targets Pi 1.0. OMP is a Pi fork whose extension API is close
 but not identical — this package is the adapter. It does **not** modify
-`ns-pi-provider`; the Pi sources are bundled at build time with a small
-compat layer.
+`ns-pi-provider`; the workspace's Pi sources (and the vendor cores under them)
+are bundled at build time with a small compat layer.
 
 | Provider | Auth | Notes |
 |----------|------|-------|
-| `kiro` (**opt-in**) | OAuth (`/login kiro`) + `KIRO_API_KEY` / SSO cache | Off by default — use [`ns-omp-provider-kiro`](https://www.npmjs.com/package/ns-omp-provider-kiro); see below |
+| `kiro` (**opt-in**) | kiro-cli / Kiro IDE session (`/login kiro`) + `KIRO_API_KEY` | Off by default — use [`ns-omp-provider-kiro`](https://www.npmjs.com/package/ns-omp-provider-kiro); see below |
 | `devin` | OAuth (`/login devin`) + `credentials.toml` / env | Swe-2 catalog when authenticated |
 | `grok` (+ `grok-sdk` alias) | Local `grok` CLI / `~/.grok` / `XAI_API_KEY` | Commands: `/grok status \| models \| refresh` |
 
@@ -22,11 +23,8 @@ Shared command: `/ns-pi status | refresh [all\|kiro\|devin\|grok]`.
 # from npm
 omp plugin install ns-omp-provider
 
-# from git
-omp plugin install git:github.com/ngosangns/ns-omp-provider
-
-# local link (dev)
-omp plugin link ~/Github/ngosangns/ns-omp-provider
+# local link (dev, after `pnpm -r build` in ns-bridge)
+omp plugin link ~/Github/ngosangns/ns-bridge/packages/omp-provider
 
 # one-shot without installing
 omp -e ./dist/index.js ...
@@ -53,15 +51,16 @@ export NS_OMP_PROVIDER_DISABLE=grok
 ```
 
 Don't opt in to `kiro` while `ns-omp-provider-kiro` is installed — both would
-register the same `kiro` provider id.
+register the same `kiro` provider id. Both run the same `ns-kiro-core`, so the
+dedicated plugin loses nothing.
 
 ## How the wrapper works
 
 1. **Build-time** — esbuild bundles `@ngosangns/ns-pi-provider` into
    `dist/index.js`, rewriting `@earendil-works/pi-ai*` imports onto
    `src/compat/` (OMP's `@oh-my-pi/pi-ai` plus Pi 1.0 transcript helpers that
-   OMP does not ship: `getCurrentSystemPrompt`, `getCurrentTools`,
-   `withoutInitialSystemMessage`).
+   OMP does not ship — `getCurrentSystemPrompt`, `getCurrentTools`,
+   `withoutInitialSystemMessage` — re-exported from `ns-bridge-core/pi`).
 2. **Runtime** — the OMP `ExtensionAPI` is wrapped so that:
    - OMP contexts (`systemPrompt: string[]`, `developer` messages) become the
      Pi shape (`systemPrompt: string`, no developer role) before
@@ -84,50 +83,26 @@ register the same `kiro` provider id.
   models from `omp models` even though the provider is registered. After
   `/login` (or with CLI creds present) the live catalog, including Devin
   `swe-2-*`, appears via `fetchDynamicModels`.
-- **Kiro catalog** (when opted in) — models come only from Kiro's `ListAvailableModels`
-  (since ns-pi-provider 0.2.0): with no Kiro credential and no saved catalog
-  snapshot, `kiro` registers zero models, and `-1m` long-context variants are
-  not offered.
-- **Upstream pin** — this release bundles `@ngosangns/ns-pi-provider@0.2.2`.
-  Bumping it is a deliberate change (rebuild + retest).
+- **Kiro catalog** (when opted in) — models come only from Kiro's `ListAvailableModels`:
+  with no Kiro session and no saved catalog snapshot, `kiro` registers zero models.
+- **Bundled Pi adapter** — the build bundles the workspace's
+  `@ngosangns/ns-pi-provider` (`workspace:*`), so an ns-omp-provider release
+  ships whatever the Pi adapter is at that commit; note it in the changelog.
 
 ## Development
 
+From the ns-bridge root:
+
 ```bash
-npm install
-npm test          # hermetic unit + bundle load tests
-npm run typecheck
-npm run build
-npm run smoke     # optional: real `omp models -e dist/index.js` under a temp HOME
+pnpm install && pnpm -r build
+pnpm vitest run --project omp                 # hermetic unit + bundle load tests
+pnpm --filter ns-omp-provider typecheck
+pnpm --filter ns-omp-provider smoke           # optional: real `omp models -e dist/index.js` under a temp HOME
 ```
 
-Requires Node ≥ 20. The smoke script needs `omp` on `PATH` and does not touch
-your real `~/.omp`.
+The smoke script needs `omp` on `PATH` and does not touch your real `~/.omp`.
 
 ## Publish
 
-Push a tag matching `package.json` (e.g. `v0.3.0`) to run
-[`.github/workflows/publish.yml`](.github/workflows/publish.yml), which
-publishes with **provenance** from a GitHub-hosted runner:
-
-```bash
-# bump "version" in package.json first, then
-npm run check
-git tag v0.3.0 && git push origin v0.3.0
-```
-
-Auth, in the order npm tries it:
-
-1. **Trusted publishing (OIDC)**, if a trusted publisher is attached to the
-   package. npm only allows that once the package exists:
-   ```bash
-   npm trust github ns-omp-provider --file publish.yml \
-     --repo ngosangns/ns-omp-provider --allow-publish
-   ```
-2. **`NPM_TOKEN` repository secret** (currently set): a granular npm token with
-   package write and "bypass 2FA", passed to npm as `NODE_AUTH_TOKEN`. This
-   covers the first publish. After trusted publishing is configured the secret
-   can be removed (`gh secret delete NPM_TOKEN --repo ngosangns/ns-omp-provider`).
-
-Manual publish from a logged-in machine still works:
-`npm run check && npm publish --access public`.
+Released from the ns-bridge workflow with tag `ns-omp-provider@<version>`; see
+[DEVELOPER.md](../../DEVELOPER.md#releasing).

package/dist/compat/transcript.d.ts

@@ -1,43 +1,7 @@
 /**
- * Pi 1.0 transcript helpers that OMP's pi-ai does not ship.
- *
- * Pi 1.0 folds the system prompt and tool set into `role: "system"` messages
- * (`toolsAdded` / `toolsRemoved` deltas) and providers read them back with
- * these helpers. OMP keeps them on `context.systemPrompt` / `context.tools`
- * and never puts system messages in the transcript, so on OMP these resolve
- * to "" / [] / the messages unchanged — and the providers fall through to
- * the (normalized) `context.systemPrompt` / `context.tools` they check first.
- *
- * Semantics mirror @earendil-works/pi-ai 1.0 `dist/utils/transcript.js`.
+ * Pi 1.x transcript helpers that OMP's pi-ai does not ship, for the bundled
+ * ns-pi-provider sources. One implementation shared with every Pi-family host:
+ * ns-bridge-core/pi. On OMP (no `system` messages in the transcript) they
+ * resolve to "" / [] / the messages unchanged.
  */
-export interface ToolLike {
-    name: string;
-    [key: string]: unknown;
-}
-export interface MessageLike {
-    role: string;
-    content?: unknown;
-    toolsAdded?: ToolLike[];
-    toolsRemoved?: Array<{
-        name: string;
-    }>;
-    sections?: Record<string, string | null>;
-    timestamp?: number;
-    [key: string]: unknown;
-}
-/** Drop the leading system message for APIs that carry the prompt outside the message list. */
-export declare function withoutInitialSystemMessage<T extends {
-    role: string;
-}>(messages: T[]): T[];
-/** Resolve the tools available after applying every transcript delta in order. */
-export declare function getCurrentTools<T = ToolLike>(messages: ReadonlyArray<{
-    role: string;
-}>): T[];
-/**
- * Render the current system prompt after replaying every system message:
- * base `content` blocks are concatenated, named `sections` are patched in
- * order (null deletes) and appended after the base prompt.
- */
-export declare function getCurrentSystemPrompt(messages: ReadonlyArray<{
-    role: string;
-}>): string;
+export { getCurrentSystemPrompt, getCurrentTools, withoutInitialSystemMessage } from "ns-bridge-core/pi";