@octanejs/mcp-server 0.2.10 → 0.2.11

package/package.json

@@ -1,9 +1,9 @@
 {
   "name": "@octanejs/mcp-server",
-  "version": "0.2.10",
+  "version": "0.2.11",
   "type": "module",
   "engines": {
-    "node": ">=22"
+    "node": ">=22.22.2"
   },
   "description": "MCP server exposing Octane repository automation for coding agents.",
   "license": "MIT",

package/skills/bridge-react-package.md

@@ -87,6 +87,10 @@ So a bridge never means "run the React package unchanged". It means:
    synthetic-event timing) goes in a short divergence note next to the port, with
    what to do instead. On an upgrade, re-copy at the new version: the diff
    against the old copy is your work list.
+   Inspect both the published package and the canonical repository at the pinned
+   tag. Do not assume the registry artifact contains source, tests, fixtures,
+   snapshots, or runner configuration; fetch missing evidence from the tagged
+   repository and record which artifact supplied it.
 
 3. **Map the React APIs.** Same-name and same-semantics in Octane: `useState`,
    `useReducer`, `useEffect`, `useLayoutEffect`, `useInsertionEffect`, `useMemo`,
@@ -153,6 +157,10 @@ So a bridge never means "run the React package unchanged". It means:
    names kept. Write down which upstream test files you ran, ported, or left out
    and why. Do not soften an upstream assertion to get it green; find out whether
    it is a bridge bug or a documented Octane divergence first.
+   Prove the evidence machinery fails closed too: removing, renaming, skipping,
+   or failing to execute a recorded case, or changing pinned evidence, must make
+   validation fail. A green port suite is not trustworthy when its collector can
+   silently go stale.
 
 8. **Validate the rest.** Drive real DOM events against the bridged binding and,
    where possible, run the same fixture against the React original and compare

package/skills/build-octane-software.md

@@ -34,6 +34,9 @@ details but do not replace these gates.
   hydration with production-compiled output and preserve abort/error behavior.
 - Treat bundle size and dependency cost as performance. Check for an official
   binding before adding a compatibility layer or a second framework runtime.
+- Publish every importable `.tsrx`, `.tsx`, `.ts`, and `.js` module as authored
+  and point package exports at that source. Do not ship Octane compiler output;
+  let the consuming application compile the source with its own toolchain.
 - When you do port a React package yourself, work from a pinned copy of that
   release's source kept beside your port, cover its exports rather than the demo
   path, and write down what parity could not reach. The `bridge-react-package`

package/src/bridge.js

@@ -121,7 +121,11 @@ export const KNOWN_BINDINGS = {
 // Octane-specific ecosystem packages that have no React import to rewrite.
 // Keep these out of KNOWN_BINDINGS so the React bridge never invents a source
 // package mapping for native tooling.
-export const KNOWN_NATIVE_BINDINGS = new Set(['@octanejs/devtools', '@octanejs/tauri']);
+export const KNOWN_NATIVE_BINDINGS = new Set([
+	'@octanejs/devtools',
+	'@octanejs/electron',
+	'@octanejs/tauri',
+]);
 
 // Workspace directory names for the maintained bindings. Keep this derived
 // from both catalogs so repository path routing cannot drift from the public