36272c8dac
`GroupQueueServiceImpl` shipped with ZERO tests; `GroupPubsubServiceImpl` had four that exercised neither boundary — its resolver always resolved and its principal was always an instance Owner (who bypasses the capability check). So on the two newest shared services, both the isolation boundary and the anonymous fail-closed gate were unpinned — and they matter most here: a shared-queue consumer is materialized into EVERY descendant app, so an unauthorized enqueue is attacker-controlled input fanned out as script execution across a whole subtree. Both now get the pair their three older siblings have: `unrelated_app_gets_collection_not_shared` (with a positive control, so a reject-everything impl can't pass it) and an anon/non-editor fail-closed test that also confirms reads (depth) stay open. Mutation-verified: swapping `script_gate_require_principal` for `script_gate` — the one-token edit that would let an unauthenticated public route enqueue into any ancestor group's shared queue — makes the anonymous enqueue succeed, and the test catches it exactly there. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PiCloud
A lightweight, self-hosted, event-driven serverless compute platform. Upload a Rhai script, get an HTTP endpoint. Designed to run on a single modest server with no idle CPU cost, and to scale out to a small cluster when you need it.
Status: Phase 1 — MVP scaffolding in progress.
The authoritative design lives in
serverless_cloud_blueprint.md.
Why
Existing serverless platforms are either cloud-locked, heavyweight, or both. PiCloud aims for the opposite end of the spectrum: one binary, one database, one reverse proxy — running on hardware you already own.
Architecture (one paragraph)
PiCloud splits into three logical services — manager (control plane: scripts, schedules, dashboard), orchestrator (per-node event ingress and dispatch), and executor (per-node Rhai sandbox) — each backed by a *-core Rust library. In MVP they run in a single process; in cluster mode they run as three binaries with one manager and one orchestrator + executor per node. Caddy fronts everything; PostgreSQL is the single source of truth.
See CLAUDE.md for working notes and serverless_cloud_blueprint.md for the full design.
Quick Start
Coming as scaffolding lands. For now:
# Rust toolchain (pinned via rust-toolchain.toml)
cargo check --workspace
# Run the all-in-one MVP binary (once main.rs is wired up)
cargo run -p picloud
Repository Layout
crates/
shared/ cross-cutting types
executor-core/ Rhai engine + sandbox
orchestrator-core/ event ingress, dispatch
manager-core/ control plane
picloud/ MVP all-in-one binary
picloud-{manager,orchestrator,executor}/ cluster-mode binaries (skeleton)
dashboard/ SvelteKit
caddy/ Caddyfile
docker/ Dockerfiles
docs/
git-workflow.md Trunk-based workflow
Contributing
See docs/git-workflow.md for the branching and commit conventions. TL;DR: trunk-based, short-lived branches, Conventional Commits, no force-pushing main.
License
TBD.