core/go
8
0
Fork 0
generated from lthn/LEM
Code Issues 5 Pull requests 1 Projects Releases Packages Wiki Activity Actions

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

Merged
Snider merged 8 commits from phase4-foundation into dev 2026-02-19 14:44:08 +00:00
Conversation 0 Commits 8 Files changed 32 +5175 -34
Charon commented 2026-02-18 09:17:30 +00:00
Member
Copy link

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 
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>
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>
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>
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>
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>
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>
Virgil added 1 commit 2026-02-19 14:40:03 +00:00 
- Path traversal: CheckPath now requires separator after prefix match
- Store namespace: block reserved '_' prefixed groups
- StoreGet: distinguish ErrNotFound from real DB errors via sentinel
- Store: add rows.Err() checks in GetAll and Render
- gRPC leak: cleanupGRPC on all early-return error paths in OnStartup
- DenoClient: fix fmt.Sprint(nil) → type assertions
- Socket permissions: 0700 dirs, 0600 sockets (owner-only)
- Marketplace: persist SignKey, re-verify manifest on Update
- io/local: resolve symlinks in New() (macOS /var → /private/var)
- Tests: fix sun_path length overflow on macOS

Co-Authored-By: Virgil <virgil@lethean.io>
Virgil added 1 commit 2026-02-19 14:41:57 +00:00 
Co-Authored-By: Virgil <virgil@lethean.io>
Snider approved these changes 2026-02-19 14:43:58 +00:00
Snider merged commit 0192772ab5 into dev 2026-02-19 14:44:08 +00:00
Snider deleted branch phase4-foundation 2026-02-19 14:44:08 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Snider
Labels
Clear labels   
needs-review

   
needs-review

   
needs-review

   
needs-review

   
needs-review

   
needs-review

   
needs-review
  
athena

Assign to Athena AI agent (M3 Ultra)

  
athena-gemini

Dispatch to Gemini CLI on M3 Ultra

  
audit

Code audit task

  
clotho

Assign to Clotho AI agent for processing

  
clotho-gemini

Dispatch to Gemini CLI on darbs (AU)

  
codex

Dispatch to Codex CLI on gateway for analysis

  
darbs-claude

Dispatch to Claude on darbs (AU)

  
security

Security review task

  
wiki

Documentation/wiki update

No labels
needs-review
needs-review
needs-review
needs-review
needs-review
needs-review
needs-review
athena
athena-gemini
audit
clotho
clotho-gemini
codex
darbs-claude
security
wiki
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: core/go#9
No description provided.
Delete branch "phase4-foundation"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?