Epic: add all-powerful init.lisp with hosted policy hooks for billing and actor quotas #58

New issue

Open

opened 2026-08-26 07:37:00 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-26 07:37:00 +00:00

(Migrated from github.com)

Goal

Give Quasar an Emacs-style trusted Common Lisp init layer for operator/deployment customization without rebuilding Quasar.

This is intentionally different from actor code: init.lisp is trusted application configuration with access to the full Quasar extension API.

Init locations

Hosted/system deployment:

/etc/quasar/init.lisp

Desktop/user deployment:

~/.config/quasar/init.lisp

Exact paths may be refined, but system and user init layers must remain distinguishable.

Required extension surface

init.lisp should be able to:

configure StarIntel OIDC
register/replace hooks
define authorization policy
register actors/tools/MCPs
add routes/middleware
configure UI/server behavior
define plans/entitlements
integrate billing
define per-user resource quotas
alter actor scheduling/resource policy

Hosted Quasar use case

The deployment at quasar.starintel.actor must be able to implement account/product policy in Lisp, including:

subscription/plan lookup
feature entitlements
maximum concurrently running actors per user
recursion/spawn limits
resource budgets
operator/admin exceptions

The authoritative policy must run server-side. The browser may display quota state but cannot enforce it alone.

Lifecycle hooks

Define a stable hook API, including candidates such as:

authenticated / session-created
actor-spawn-requested
actor-started/stopped
tool-call-requested
MCP-call-requested
request/route middleware
entitlement/plan resolution

Critical spawn invariant

Every spawn path must hit the same authoritative quota/policy hook:

UI spawn
API spawn
Common Lisp actor child spawn
JavaScript actor child spawn
recursive/subagent spawn

No actor may bypass account limits by spawning descendants.

Security boundary

system init.lisp is trusted operator code
user desktop init.lisp is trusted as that local user and must never silently become server authority
ordinary Lisp/JS actors remain capability-governed and do not inherit init privileges
hosted init source/secrets are never shipped to the browser
only safe resulting state/entitlements are projected to clients

TDD acceptance

load order is deterministic and documented
invalid init fails with explicit startup/error behavior
hooks can approve/deny actor spawn
per-user actor quota is enforced across all spawn paths
JS and Lisp child spawns cannot bypass the same gate
server init can expose safe entitlement state without exposing implementation/secrets
actor code cannot mutate trusted init policy without an explicitly granted operator mechanism

Dependencies

#57 actor host API/parity
#56 StarIntel OIDC/web+Electron architecture
existing principal/capability work (#2, #50)

Non-goals

do not sandbox the system init as though it were an untrusted actor
do not make billing logic a hard-coded React concern
do not require every deployment to use billing; the extension hooks are general-purpose

## Goal Give Quasar an **Emacs-style trusted Common Lisp init layer** for operator/deployment customization without rebuilding Quasar. This is intentionally different from actor code: `init.lisp` is trusted application configuration with access to the full Quasar extension API. ## Init locations Hosted/system deployment: - `/etc/quasar/init.lisp` Desktop/user deployment: - `~/.config/quasar/init.lisp` Exact paths may be refined, but system and user init layers must remain distinguishable. ## Required extension surface `init.lisp` should be able to: - configure StarIntel OIDC - register/replace hooks - define authorization policy - register actors/tools/MCPs - add routes/middleware - configure UI/server behavior - define plans/entitlements - integrate billing - define per-user resource quotas - alter actor scheduling/resource policy ## Hosted Quasar use case The deployment at `quasar.starintel.actor` must be able to implement account/product policy in Lisp, including: - subscription/plan lookup - feature entitlements - maximum concurrently running actors per user - recursion/spawn limits - resource budgets - operator/admin exceptions The authoritative policy must run server-side. The browser may display quota state but cannot enforce it alone. ## Lifecycle hooks Define a stable hook API, including candidates such as: - authenticated / session-created - actor-spawn-requested - actor-started/stopped - tool-call-requested - MCP-call-requested - request/route middleware - entitlement/plan resolution ## Critical spawn invariant Every spawn path must hit the same authoritative quota/policy hook: - UI spawn - API spawn - Common Lisp actor child spawn - JavaScript actor child spawn - recursive/subagent spawn No actor may bypass account limits by spawning descendants. ## Security boundary - system `init.lisp` is trusted operator code - user desktop `init.lisp` is trusted as that local user and must never silently become server authority - ordinary Lisp/JS actors remain capability-governed and do **not** inherit init privileges - hosted init source/secrets are never shipped to the browser - only safe resulting state/entitlements are projected to clients ## TDD acceptance - load order is deterministic and documented - invalid init fails with explicit startup/error behavior - hooks can approve/deny actor spawn - per-user actor quota is enforced across all spawn paths - JS and Lisp child spawns cannot bypass the same gate - server init can expose safe entitlement state without exposing implementation/secrets - actor code cannot mutate trusted init policy without an explicitly granted operator mechanism ## Dependencies - #57 actor host API/parity - #56 StarIntel OIDC/web+Electron architecture - existing principal/capability work (#2, #50) ## Non-goals - do not sandbox the system init as though it were an untrusted actor - do not make billing logic a hard-coded React concern - do not require every deployment to use billing; the extension hooks are general-purpose