Merge pull request #27 from rivet-dev/ralph/kernel-consolidation

chore: reorg project

Author: NathanFlurry

.agent/contracts/compatibility-governance.md

@@ -8,25 +8,25 @@ Changes that add, remove, or materially alter TypeScript compile/typecheck behav
 
 #### Scenario: Core runtime TypeScript handling changes
 - **WHEN** the core runtime adds or removes implicit TypeScript preprocessing behavior
-- **THEN** `docs/quickstart.mdx`, `docs/api-reference.mdx`, `docs/runtimes/node.mdx`, `docs/node-compatability.mdx`, `docs-internal/arch/overview.md`, and `docs-internal/friction.md` MUST be updated in the same change
+- **THEN** `docs/quickstart.mdx`, `docs/api-reference.mdx`, `docs/runtimes/node.mdx`, `docs/nodejs-compatibility.mdx`, `docs-internal/arch/overview.md`, and `docs-internal/friction.md` MUST be updated in the same change
 
 #### Scenario: Companion TypeScript tooling API changes
 - **WHEN** the public API of the companion TypeScript tooling package changes
 - **THEN** `docs/quickstart.mdx` and `docs/api-reference.mdx` MUST be updated in the same change so project/source helper semantics remain accurate
 
 ### Requirement: Maintain Node Stdlib Compatibility Matrix
-Changes affecting bridged or polyfilled Node APIs MUST keep `docs/node-compatability.mdx` synchronized with the actual runtime surface, including supported, limited, and unsupported modules/APIs. Every module entry in the matrix MUST include an explicit support-tier classification (Bridge, Polyfill, Stub, Deferred, or Unsupported) as defined by the `node-stdlib` spec. The page MUST include a top-of-page target Node version statement.
+Changes affecting bridged or polyfilled Node APIs MUST keep `docs/nodejs-compatibility.mdx` synchronized with the actual runtime surface, including supported, limited, and unsupported modules/APIs. Every module entry in the matrix MUST include an explicit support-tier classification (Bridge, Polyfill, Stub, Deferred, or Unsupported) as defined by the `node-stdlib` spec. The page MUST include a top-of-page target Node version statement.
 
 #### Scenario: Bridge API surface changes
 - **WHEN** a change adds, removes, or materially alters bridged Node API behavior
-- **THEN** the compatibility matrix page at `docs/node-compatability.mdx` MUST be updated in the same change to reflect the new runtime contract
+- **THEN** the compatibility matrix page at `docs/nodejs-compatibility.mdx` MUST be updated in the same change to reflect the new runtime contract
 
 #### Scenario: Legacy internal matrix path appears anywhere in repository docs/spec sources
 - **WHEN** a repository document or spec source references the legacy internal stdlib compatibility document
-- **THEN** the reference MUST be replaced with `docs/node-compatability.mdx` before the change is considered complete
+- **THEN** the reference MUST be replaced with `docs/nodejs-compatibility.mdx` before the change is considered complete
 
 #### Scenario: Target Node version callout is missing
-- **WHEN** `docs/node-compatability.mdx` is updated
+- **WHEN** `docs/nodejs-compatibility.mdx` is updated
 - **THEN** the page MUST retain an explicit target Node version statement at the top
 
 ### Requirement: Node Compatibility Target Version Tracks Test Type Baseline
@@ -38,7 +38,7 @@ The runtime compatibility target MUST align with the `@types/node` package major
 
 #### Scenario: `@types/node` target major is upgraded
 - **WHEN** the workspace intentionally upgrades `@types/node` to a new major version used by secure-exec validation
-- **THEN** the same change MUST update `docs/node-compatability.mdx` and related compatibility-governance references to the new target Node major line
+- **THEN** the same change MUST update `docs/nodejs-compatibility.mdx` and related compatibility-governance references to the new target Node major line
 
 #### Scenario: Compatibility target is documented
 - **WHEN** compatibility requirements or docs declare a target Node version
@@ -67,10 +67,10 @@ Unexpected issues, workarounds, and integration friction encountered during secu
 - **THEN** its log entry MUST be updated to indicate resolution and summarize the fix
 
 ### Requirement: Run Bridge Type Conformance Tests After Bridge Changes
-Any change to files under `packages/secure-exec-core/src/bridge` MUST run bridge type conformance checks via `pnpm run check-types:test` in `packages/secure-exec` before completion.
+Any change to files under `packages/nodejs/src/bridge` MUST run bridge type conformance checks via `pnpm run check-types:test` in `packages/secure-exec` before completion.
 
 #### Scenario: Bridge source file is modified
-- **WHEN** a commit modifies one or more files in `packages/secure-exec-core/src/bridge`
+- **WHEN** a commit modifies one or more files in `packages/nodejs/src/bridge`
 - **THEN** `pnpm run check-types:test` MUST be executed and failures MUST be addressed before the change is considered complete
 
 ### Requirement: Compatibility Project Matrix Uses Black-Box Node Fixtures
@@ -221,15 +221,15 @@ Changes to runtime or bridge filesystem metadata/rename behavior SHALL update co
 - **THEN** the compatibility project-matrix MUST include fixture coverage that exercises the changed behavior under host Node and secure-exec comparison
 
 ### Requirement: Governance References Use Canonical Secure-Exec Package Family Naming
-Governance artifacts that reference runtime package imports SHALL use the `@secure-exec/*` scoped package names (`@secure-exec/core`, `@secure-exec/node`, `@secure-exec/browser`, `@secure-exec/python`) or the `secure-exec` barrel. Source paths SHALL use the corresponding workspace directories (`packages/secure-exec-core`, `packages/secure-exec-node`, `packages/secure-exec-browser`, `packages/secure-exec-python`, `packages/secure-exec`).
+Governance artifacts that reference runtime package imports SHALL use the `@secure-exec/*` scoped package names (`@secure-exec/core`, `@secure-exec/nodejs`, `@secure-exec/browser`, `@secure-exec/python`) or the `secure-exec` barrel. Source paths SHALL use the corresponding workspace directories (`packages/core`, `packages/nodejs`, `packages/browser`, `packages/python`, `packages/secure-exec`).
 
 #### Scenario: Governance guidance references runtime package imports
 - **WHEN** a governance document or spec requirement describes runtime package imports
 - **THEN** it MUST use the appropriate `@secure-exec/*` scoped package name or the `secure-exec` barrel
 
 #### Scenario: Governance guidance references runtime source paths
 - **WHEN** a governance document or spec requirement describes runtime source directories
-- **THEN** it MUST use the appropriate `packages/secure-exec-*` workspace path for the component being referenced
+- **THEN** it MUST use the appropriate `packages/*` workspace path for the component being referenced
 
 ### Requirement: Module-Access Boundary Changes MUST Update Security and Friction Documentation
 Any change that introduces or modifies driver-managed host module projection or overlay boundaries MUST update compatibility/friction and security-model documentation in the same change.
@@ -251,7 +251,7 @@ Any change that introduces or modifies runtime log-capture defaults or hook-base
 
 #### Scenario: Runtime introduces or changes log-stream hook behavior
 - **WHEN** runtime log-stream hook contract changes (event shape, ordering semantics, or failure behavior)
-- **THEN** `docs/security-model.mdx` MUST describe trust-boundary and resource-consumption implications and `docs/node-compatability.mdx` MUST reflect user-visible behavior changes where applicable
+- **THEN** `docs/security-model.mdx` MUST describe trust-boundary and resource-consumption implications and `docs/nodejs-compatibility.mdx` MUST reflect user-visible behavior changes where applicable
 
 #### Scenario: Logging changes include exploit regression coverage
 - **WHEN** logging/output behavior is changed in runtime or bridge paths
@@ -261,7 +261,7 @@ Any change that introduces or modifies runtime log-capture defaults or hook-base
 Any change that modifies runtime-driver behavior or runtime orchestration contracts MUST run shared integration suites against both node and browser runtime-driver targets.
 
 #### Scenario: Runtime/driver implementation changes trigger cross-target validation
-- **WHEN** a change modifies runtime contracts or driver behavior under `packages/secure-exec-core/src/`, `packages/secure-exec-node/src/`, or `packages/secure-exec-browser/src/`
+- **WHEN** a change modifies runtime contracts or driver behavior under `packages/core/src/`, `packages/nodejs/src/`, or `packages/browser/src/`
 - **THEN** the change MUST execute shared integration suites for both node and browser targets before completion
 
 #### Scenario: Shared suites are reused between targets

.agent/contracts/documentation-site.md

@@ -8,11 +8,11 @@ The documentation site SHALL expose a core navigation set that includes Quicksta
 
 #### Scenario: Docs configuration defines required core pages
 - **WHEN** the docs configuration is loaded
-- **THEN** navigation MUST include `quickstart`, `security-model`, and `node-compatability` as available documentation pages
+- **THEN** navigation MUST include `quickstart`, `security-model`, and `nodejs-compatibility` as available documentation pages
 
 #### Scenario: Node compatibility page path is resolvable
 - **WHEN** a user selects the Node Compatibility page from navigation
-- **THEN** the docs site MUST resolve and render `node-compatability.mdx` successfully
+- **THEN** the docs site MUST resolve and render `nodejs-compatibility.mdx` successfully
 
 ### Requirement: Quickstart Uses Steps With Runnable Example
 The Quickstart page SHALL present onboarding steps using Mintlify `<Steps>` and SHALL include at least one basic runnable example that verifies setup success using the current runtime logging contract.
@@ -30,17 +30,17 @@ The Quickstart page SHALL present onboarding steps using Mintlify `<Steps>` and
 - **THEN** it MUST use hook-based log streaming examples and MUST NOT instruct users to read `result.stdout` or `result.stderr`
 
 ### Requirement: Node Compatibility Page Declares Target Version and Matrix
-The docs site MUST provide `docs/node-compatability.mdx` with an explicit target Node version statement near the top of the page and a clean compatibility matrix table that summarizes module support tier and runtime notes.
+The docs site MUST provide `docs/nodejs-compatibility.mdx` with an explicit target Node version statement near the top of the page and a clean compatibility matrix table that summarizes module support tier and runtime notes.
 
 #### Scenario: Target Node version is visible at top of page
-- **WHEN** `node-compatability.mdx` is rendered
+- **WHEN** `nodejs-compatibility.mdx` is rendered
 - **THEN** users MUST see the targeted Node version before the compatibility matrix content
 
 #### Scenario: Compatibility matrix uses concise tabular format
-- **WHEN** `node-compatability.mdx` is rendered
+- **WHEN** `nodejs-compatibility.mdx` is rendered
 - **THEN** it MUST include a simple table with module/support-tier/status details migrated from the internal compatibility source
 
 #### Scenario: Permission model scope stays at runtime and bridge contract
-- **WHEN** `node-compatability.mdx` documents permission behavior
+- **WHEN** `nodejs-compatibility.mdx` documents permission behavior
 - **THEN** it MUST describe core runtime/bridge permission enforcement and MUST NOT present driver-construction convenience defaults as the canonical security contract
 

.agent/contracts/isolate-runtime-source-architecture.md

@@ -4,15 +4,15 @@
 TBD - created by archiving change harden-isolate-runtime-typing-and-layout. Update Purpose after archive.
 ## Requirements
 ### Requirement: Isolate Runtime Source Layout Separates Inject Entrypoints and Shared Modules
-The isolate-runtime source tree SHALL organize host-injected entry scripts under `packages/secure-exec-core/isolate-runtime/src/inject/` and shared reusable modules under `packages/secure-exec-core/isolate-runtime/src/common/`.
+The isolate-runtime source tree SHALL organize host-injected entry scripts under `packages/core/isolate-runtime/src/inject/` and shared reusable modules under `packages/core/isolate-runtime/src/common/`.
 
 #### Scenario: Existing inject sources are migrated to canonical layout
 - **WHEN** isolate-runtime injection sources are maintained or refactored
-- **THEN** entry scripts evaluated by host runtime MUST live under `packages/secure-exec-core/isolate-runtime/src/inject/` and shared helpers/types MUST live under `packages/secure-exec-core/isolate-runtime/src/common/`
+- **THEN** entry scripts evaluated by host runtime MUST live under `packages/core/isolate-runtime/src/inject/` and shared helpers/types MUST live under `packages/core/isolate-runtime/src/common/`
 
 #### Scenario: New isolate injection source is added
 - **WHEN** contributors introduce a new host-to-isolate injected script
-- **THEN** the source file MUST be added under `packages/secure-exec-core/isolate-runtime/src/inject/` and MUST NOT be placed in legacy flat isolate-runtime paths
+- **THEN** the source file MUST be added under `packages/core/isolate-runtime/src/inject/` and MUST NOT be placed in legacy flat isolate-runtime paths
 
 ### Requirement: Inject Entrypoints SHALL Compile as Standalone Runtime Artifacts
 Inject entrypoint files SHALL be compiled into standalone executable source payloads suitable for host runtime injection, including any shared code imported from `src/common`.

.agent/contracts/node-bridge.md

@@ -117,7 +117,7 @@ Bridge-exposed filesystem metadata calls (`exists`, `stat`, and typed directory
 - **THEN** bridge handling MUST return entry type information without a repeated `readDir` probe for each entry
 
 ### Requirement: Bridge Boundary Contracts SHALL Be Defined In A Canonical Shared Type Module
-Bridge global keys and host/isolate boundary type contracts SHALL be defined in one canonical shared type module under `packages/secure-exec-core/src/shared/` and reused across host runtime setup and bridge modules.
+Bridge global keys and host/isolate boundary type contracts SHALL be defined in canonical shared type modules — bridge-contract types in `packages/nodejs/src/bridge-contract.ts` and global-exposure helpers in `packages/core/src/shared/global-exposure.ts` — and reused across host runtime setup and bridge modules.
 
 #### Scenario: Host runtime injects bridge globals
 - **WHEN** host runtime code wires bridge globals into the isolate