refactor: flatten package directory names

Author: NathanFlurry

.agent/contracts/compatibility-governance.md

@@ -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-nodejs/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-nodejs/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/nodejs`, `@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-nodejs`, `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.
@@ -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-nodejs/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/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 canonical shared type modules — bridge-contract types in `packages/secure-exec-nodejs/src/bridge-contract.ts` and global-exposure helpers in `packages/secure-exec-core/src/shared/global-exposure.ts` — 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

.agent/contracts/node-runtime.md

@@ -18,6 +18,10 @@ The project SHALL provide a stable sandbox execution interface through `NodeRunt
 - **WHEN** a caller invokes `run()` with CommonJS code that assigns to `module.exports`
 - **THEN** the result's `exports` field MUST contain the value of `module.exports`
 
+#### Scenario: Run CJS module with file path resolves relative requires from that file
+- **WHEN** a caller invokes `run()` with a `filePath` and the module uses `require("./relative-path")`
+- **THEN** relative CommonJS resolution MUST use the provided file path's directory as the parent module directory
+
 #### Scenario: Run ESM module and retrieve namespace exports
 - **WHEN** a caller invokes `run()` with ESM code that uses `export` declarations
 - **THEN** the result's `exports` field MUST contain the module namespace object with all named exports and the `default` export (if declared)
@@ -234,7 +238,7 @@ The Node runtime MUST validate isolate-originated serialized payload size before
 - **THEN** the runtime MUST fail the operation with a deterministic overflow error and MUST NOT call `JSON.parse` on that payload
 
 #### Scenario: All isolate-originated parse entry points are guarded
-- **WHEN** host runtime code in the Node execution driver (`packages/secure-exec-nodejs/src/execution-driver.ts`) parses isolate-originated JSON payloads for bridged operations
+- **WHEN** host runtime code in the Node execution driver (`packages/nodejs/src/execution-driver.ts`) parses isolate-originated JSON payloads for bridged operations
 - **THEN** each parse entry point MUST apply the same pre-parse size validation before invoking `JSON.parse`
 
 #### Scenario: In-limit serialized payload preserves existing behavior
@@ -325,7 +329,7 @@ The runtime SHALL publish its execution interface through the `@secure-exec/*` s
 
 #### Scenario: Runtime source is split across focused packages
 - **WHEN** contributors update runtime implementation files
-- **THEN** shared types and runtime classes MUST live under `packages/secure-exec-core`, Node driver code under `packages/secure-exec-nodejs`, browser driver code under `packages/secure-exec-browser`, Python driver code under `packages/secure-exec-python`, and the barrel re-export layer under `packages/secure-exec`
+- **THEN** shared types and runtime classes MUST live under `packages/core`, Node driver code under `packages/nodejs`, browser driver code under `packages/browser`, Python driver code under `packages/python`, and the barrel re-export layer under `packages/secure-exec`
 
 #### Scenario: Barrel package contains no source logic
 - **WHEN** contributors inspect `packages/secure-exec/src/`
@@ -339,15 +343,15 @@ Module projection and overlay-based loading SHALL reject native addon artifacts
 - **THEN** runtime MUST fail deterministically and MUST NOT execute native addon code
 
 ### Requirement: Isolate-Executed Bootstrap Sources MUST Be Static TypeScript Modules
-Any source code evaluated inside the isolate for runtime/bootstrap setup MUST originate from static files under `packages/secure-exec-core/isolate-runtime/src/` and MUST be tracked as normal TypeScript source with inject entrypoints rooted in `packages/secure-exec-core/isolate-runtime/src/inject/`.
+Any source code evaluated inside the isolate for runtime/bootstrap setup MUST originate from static files under `packages/core/isolate-runtime/src/` and MUST be tracked as normal TypeScript source with inject entrypoints rooted in `packages/core/isolate-runtime/src/inject/`.
 
 #### Scenario: Runtime injects require and bridge bootstrap code
 - **WHEN** secure-exec prepares isolate bootstrap code for `require` setup, bridge setup, or related runtime helpers
 - **THEN** the injected source MUST come from static isolate-runtime module files rather than ad-hoc inline source assembly in host runtime files
 
 #### Scenario: New isolate injection path is introduced
 - **WHEN** a change adds a new host-to-isolate code injection path
-- **THEN** the injected code MUST be added as a static `.ts` file under `packages/secure-exec-core/isolate-runtime/src/inject/` in the same change
+- **THEN** the injected code MUST be added as a static `.ts` file under `packages/core/isolate-runtime/src/inject/` in the same change
 
 #### Scenario: Existing template-generated bootstrap helper is migrated
 - **WHEN** secure-exec migrates helpers such as `getRequireSetupCode`, `getBridgeWithConfig`, or `createInitialBridgeGlobalsCode`
@@ -357,7 +361,7 @@ Any source code evaluated inside the isolate for runtime/bootstrap setup MUST or
 The `@secure-exec/core` package build MUST execute isolate-runtime compilation before producing final runtime artifacts, and build orchestration MUST treat isolate-runtime compilation and isolate-runtime typecheck as explicit validation dependencies.
 
 #### Scenario: Package build runs with clean outputs
-- **WHEN** `packages/secure-exec-core` is built from a clean workspace
+- **WHEN** `packages/core` is built from a clean workspace
 - **THEN** the build MUST run a dedicated isolate-runtime compile step before final package build output is produced
 
 #### Scenario: Turbo build graph resolves core build dependencies

.agent/contracts/runtime-driver-test-suite-structure.md

@@ -10,7 +10,7 @@ Secure-exec runtime-driver integration coverage MUST use the canonical filesyste
 - `packages/secure-exec/tests/test-suite/{name}.ts`
 - `packages/secure-exec/tests/exec-driver/{name}.test.ts`
 - `packages/secure-exec/tests/runtime-driver/{name}.test.ts`
-- `packages/secure-exec-core/test/kernel/{name}.test.ts` (kernel unit tests)
+- `packages/core/test/kernel/{name}.test.ts` (kernel unit tests)
 - `packages/secure-exec/tests/kernel/{name}.test.ts` (kernel cross-runtime integration tests)
 
 #### Scenario: Shared matrix entrypoint exists at canonical path
@@ -48,15 +48,15 @@ Shared suite registration order in the matrix entrypoint MUST be explicit and st
 - **THEN** they MUST be imported and invoked in deterministic source order rather than filesystem discovery
 
 ### Requirement: Kernel Unit Tests SHALL Use MockRuntimeDriver In Kernel Package
-Kernel unit tests that validate kernel subsystem behavior (VFS, FD table, process table, device layer, pipe manager, command registry, permissions) SHALL reside under `packages/secure-exec-core/test/kernel/` and use MockRuntimeDriver for driver interactions.
+Kernel unit tests that validate kernel subsystem behavior (VFS, FD table, process table, device layer, pipe manager, command registry, permissions) SHALL reside under `packages/core/test/kernel/` and use MockRuntimeDriver for driver interactions.
 
 #### Scenario: Kernel unit tests live in kernel package
 - **WHEN** contributors add or update tests for kernel subsystem behavior
-- **THEN** those tests MUST reside under `packages/secure-exec-core/test/kernel/` as `*.test.ts` files
+- **THEN** those tests MUST reside under `packages/core/test/kernel/` as `*.test.ts` files
 
 #### Scenario: Kernel unit tests use MockRuntimeDriver
 - **WHEN** kernel unit tests need to validate spawn/exec orchestration or command registration
-- **THEN** they MUST use a MockRuntimeDriver (from `packages/secure-exec-core/test/kernel/helpers.ts`) that implements the RuntimeDriver interface with controllable behavior, rather than requiring real runtime drivers
+- **THEN** they MUST use a MockRuntimeDriver (from `packages/core/test/kernel/helpers.ts`) that implements the RuntimeDriver interface with controllable behavior, rather than requiring real runtime drivers
 
 #### Scenario: Kernel unit tests validate subsystem invariants independently
 - **WHEN** kernel unit tests validate FD table, process table, pipe manager, or device layer behavior

CLAUDE.md

@@ -57,17 +57,17 @@
 - the WasmVM runtime requires standalone WASM binaries in `native/wasmvm/target/wasm32-wasip1/release/commands/`
 - build them locally: `cd native/wasmvm && make wasm` (requires Rust nightly + wasm32-wasip1 target + rust-src component + wasm-opt/binaryen)
 - the Rust toolchain is pinned in `native/wasmvm/rust-toolchain.toml` — rustup will auto-install it
-- CI builds the binaries before tests; a CI-only guard test in `packages/secure-exec-wasmvm/test/driver.test.ts` fails if they're missing
+- CI builds the binaries before tests; a CI-only guard test in `packages/wasmvm/test/driver.test.ts` fails if they're missing
 - tests gated behind `skipIf(!hasWasmBinaries)` or `skipUnlessWasmBuilt()` will skip locally if binaries aren't built
 - see `native/wasmvm/CLAUDE.md` for full build details and architecture
 
 ## WasmVM Syscall Coverage
 
 - every function in the `host_process` and `host_user` import modules (declared in `native/wasmvm/crates/wasi-ext/src/lib.rs`) must have at least one C parity test exercising it through libc
-- when adding a new host import, add a matching test case to `native/wasmvm/c/programs/syscall_coverage.c` and its parity test in `packages/secure-exec-wasmvm/test/c-parity.test.ts`
+- when adding a new host import, add a matching test case to `native/wasmvm/c/programs/syscall_coverage.c` and its parity test in `packages/wasmvm/test/c-parity.test.ts`
 - the canonical source of truth for import signatures is `native/wasmvm/crates/wasi-ext/src/lib.rs` — C patches and JS host implementations must match exactly
 - C patches in `native/wasmvm/patches/wasi-libc/` must be kept in sync with wasi-ext — ABI drift between C, Rust, and JS is a P0 bug
-- permission tier enforcement must cover ALL write/spawn/kill/pipe/dup operations — audit `packages/secure-exec-wasmvm/src/kernel-worker.ts` when adding new syscalls
+- permission tier enforcement must cover ALL write/spawn/kill/pipe/dup operations — audit `packages/wasmvm/src/kernel-worker.ts` when adding new syscalls
 - `PATCHED_PROGRAMS` in `native/wasmvm/c/Makefile` must include all programs that use `host_process` or `host_user` imports (programs linking the patched sysroot)
 
 ## Terminology

docs-internal/arch/kernel-integration.md

@@ -172,7 +172,7 @@ secure-exec/                           ← monorepo root
 │   │   │   └── index.ts            ← Re-exports kernel + all runtimes + all OS adapters
 │   │   └── package.json
 │   │
-│   ├── secure-exec-typescript/       ← EXISTING: TypeScript compiler tools
+│   ├── typescript/       ← EXISTING: TypeScript compiler tools
 │   ├── playground/                   ← EXISTING: web demo
 │   └── website/                      ← EXISTING: docs site
 │
@@ -1281,7 +1281,7 @@ secure-exec/                                    ← monorepo root
 │   │       ├── project-matrix/
 │   │       └── types/
 │   │
-│   ├── secure-exec-typescript/                 ← EXISTING: TypeScript compiler tools
+│   ├── typescript/                 ← EXISTING: TypeScript compiler tools
 │   ├── playground/                             ← EXISTING: web demo
 │   └── website/                                ← EXISTING: docs site
 │