core/go

Fork 0

generated from lthn/LEM

feat(coredeno): Phase 4 foundation — Deno sidecar with marketplace install #9

Open

Charon wants to merge 6 commits from phase4-foundation into dev

Charon commented

2026-02-18 09:17:30 +00:00

Member

Summary

Tier 1: Boot sequence — gRPC listener, manifest loading, Deno sidecar launch
Tier 2: Bidirectional bridge — Go↔Deno JSON-RPC + gRPC module lifecycle
Tier 3: Worker isolation — sandboxed module loading with postMessage I/O bridge
Tier 4: Marketplace install pipeline — git clone, ed25519 manifest verification, store registry, auto-load at startup

Architecture

Go boots a Deno sidecar process. Communication is bidirectional:

Go → Deno: JSON-RPC over Unix socket (LoadModule, UnloadModule, ModuleStatus)
Deno → Go: gRPC over Unix socket (StoreGet/Set, FileRead/Write, ProcessStart/Stop)

Each module runs in an isolated Deno Worker with per-module permission sandboxing. The I/O bridge relays Worker postMessage calls through the parent to the Go gRPC server, injecting module identity to prevent spoofing.

The marketplace installer clones module repos, verifies ed25519 manifest signatures, and registers metadata in the SQLite store. On startup, installed modules are auto-loaded as Workers.

Key packages

Package	Purpose
`pkg/coredeno/`	Service, sidecar lifecycle, gRPC server, Deno client
`pkg/coredeno/runtime/`	TypeScript runtime (main.ts, server.ts, modules.ts, worker-entry.ts)
`pkg/coredeno/proto/`	gRPC protobuf definitions
`pkg/marketplace/`	Module index parser + installer
`pkg/store/`	SQLite group-namespaced KV (added GetAll)
`pkg/manifest/`	YAML manifest with ed25519 signing (exported MarshalYAML)

Test plan

go test ./pkg/store/... — 8 tests (including new GetAll)
go test ./pkg/manifest/... — 10 tests
go test ./pkg/marketplace/... — 14 tests (9 new installer tests)
go test ./pkg/coredeno/... — 40 unit tests
go test -tags integration ./pkg/coredeno/... — 4 integration tests (Tiers 1-4)

🤖 Generated with Claude Code

## Summary - **Tier 1:** Boot sequence — gRPC listener, manifest loading, Deno sidecar launch - **Tier 2:** Bidirectional bridge — Go↔Deno JSON-RPC + gRPC module lifecycle - **Tier 3:** Worker isolation — sandboxed module loading with postMessage I/O bridge - **Tier 4:** Marketplace install pipeline — git clone, ed25519 manifest verification, store registry, auto-load at startup ## Architecture Go boots a Deno sidecar process. Communication is bidirectional: - **Go → Deno:** JSON-RPC over Unix socket (LoadModule, UnloadModule, ModuleStatus) - **Deno → Go:** gRPC over Unix socket (StoreGet/Set, FileRead/Write, ProcessStart/Stop) Each module runs in an isolated Deno Worker with per-module permission sandboxing. The I/O bridge relays Worker postMessage calls through the parent to the Go gRPC server, injecting module identity to prevent spoofing. The marketplace installer clones module repos, verifies ed25519 manifest signatures, and registers metadata in the SQLite store. On startup, installed modules are auto-loaded as Workers. ## Key packages | Package | Purpose | |---------|--------| | `pkg/coredeno/` | Service, sidecar lifecycle, gRPC server, Deno client | | `pkg/coredeno/runtime/` | TypeScript runtime (main.ts, server.ts, modules.ts, worker-entry.ts) | | `pkg/coredeno/proto/` | gRPC protobuf definitions | | `pkg/marketplace/` | Module index parser + installer | | `pkg/store/` | SQLite group-namespaced KV (added GetAll) | | `pkg/manifest/` | YAML manifest with ed25519 signing (exported MarshalYAML) | ## Test plan - [ ] `go test ./pkg/store/...` — 8 tests (including new GetAll) - [ ] `go test ./pkg/manifest/...` — 10 tests - [ ] `go test ./pkg/marketplace/...` — 14 tests (9 new installer tests) - [ ] `go test ./pkg/coredeno/...` — 40 unit tests - [ ] `go test -tags integration ./pkg/coredeno/...` — 4 integration tests (Tiers 1-4) 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Charon added 6 commits 2026-02-18 09:17:30 +00:00

feat(coredeno): gRPC server with permission-gated I/O fortress e8695b72a6

Generated Go code from proto. Server implements CoreService with
FileRead/FileWrite/FileList/FileDelete/StoreGet/StoreSet — every
request checked against the calling module's manifest permissions.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

feat(coredeno): wire Service into framework DI with ServiceRuntime[T] 7d047fbdcc

Service embeds ServiceRuntime[Options] for Core/Opts access.
NewServiceFactory returns factory for core.WithService registration.
Correct Startable/Stoppable signatures with context.Context.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

feat(coredeno): wire Tier 1 boot sequence — gRPC listener, manifest loading, sidecar launch 2f246ad053

Service.OnStartup now creates sandboxed I/O medium, opens SQLite store,
starts gRPC listener on Unix socket, loads .core/view.yml manifest, and
launches Deno sidecar with CORE_SOCKET env var. Full shutdown in reverse.

New files: listener.go (Unix socket gRPC server), runtime/main.ts (Deno
entry point), integration_test.go (full boot with real Deno).

34 tests pass (33 unit + 1 integration).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

feat(coredeno): Tier 2 bidirectional bridge — Go↔Deno module lifecycle af98accc03

Wire the CoreDeno sidecar into a fully bidirectional bridge:

- Deno→Go (gRPC): Deno connects as CoreService client via polyfilled
  @grpc/grpc-js over Unix socket. Polyfill patches Deno 2.x http2 gaps
  (getDefaultSettings, pre-connected socket handling, remoteSettings).
- Go→Deno (JSON-RPC): Go connects to Deno's newline-delimited JSON-RPC
  server for module lifecycle (LoadModule, UnloadModule, ModuleStatus).
  gRPC server direction avoided due to Deno http2.createServer limitations.
- ProcessStart/ProcessStop: gRPC handlers delegate to process.Service
  with manifest permission gating (run permissions).
- Deno runtime: main.ts boots DenoService server, connects CoreService
  client with retry + health-check round-trip, handles SIGTERM shutdown.

40 unit tests + 2 integration tests (Tier 1 boot + Tier 2 bidirectional).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

feat(coredeno): Tier 3 Worker isolation — sandboxed module loading with I/O bridge ad6a466459

Each module now runs in a real Deno Worker with per-module permission
sandboxing. The I/O bridge relays Worker postMessage calls through the
parent to CoreService gRPC, so modules can access store, files, and
processes without direct network/filesystem access.

- Worker bootstrap (worker-entry.ts): sets up RPC bridge, dynamically
  imports module, calls init(core) with typed I/O object
- ModuleRegistry rewritten: creates Workers with Deno permission
  constructor, handles LOADING → RUNNING → STOPPED lifecycle
- Structured ModulePermissions (read/write/net/run) replaces flat
  string array in Go→Deno JSON-RPC
- I/O bridge: Worker postMessage → parent dispatchRPC → CoreClient
  gRPC → response relayed back to Worker
- Test module proves end-to-end: Worker calls core.storeSet() →
  Go verifies value in store

40 unit tests + 3 integration tests (Tier 1 boot + Tier 2 bidir + Tier 3 Worker).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

feat(coredeno): Tier 4 marketplace install pipeline — clone, verify, register, auto-load 9899398153

Wire the marketplace to actually install modules from Git repos, verify
manifest signatures, track installations in the store, and auto-load them
as Workers at startup. A module goes from marketplace entry to running
Worker with Install() + LoadModule().

- Add Store.GetAll() for group-scoped key listing
- Create marketplace.Installer with Install/Remove/Update/Installed
- Export manifest.MarshalYAML for test fixtures
- Wire installer into Service with auto-load on startup (step 8)
- Expose Service.Installer() accessor
- Full integration test: install → load → verify store write → unload → remove

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

This pull request has changes conflicting with the target branch.

go.mod
go.sum

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin phase4-foundation:phase4-foundation

git checkout phase4-foundation

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git checkout dev

git merge --no-ff phase4-foundation

git checkout phase4-foundation

git rebase dev

git checkout dev

git merge --ff-only phase4-foundation

git checkout phase4-foundation

git rebase dev

git checkout dev

git merge --no-ff phase4-foundation

git checkout dev

git merge --squash phase4-foundation