Epic: build a real Common Lisp web application for auto-dig.starintel.actor #26

New issue

Open

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

lost-rob0t commented

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

(Migrated from github.com)

Goal

Make https://auto-dig.starintel.actor a real StarIntel web application implemented with Common Lisp web tooling.

Do not expose an internal Auto-Dig runtime/UI shim directly as the public website.

Architecture

The public site runs on the shared StarIntel web host and talks to the canonical Auto-Dig/Quasar control plane through explicit APIs.

Suggested implementation direction:

Common Lisp application layer
Clack/Lack-compatible HTTP stack
Hunchentoot, Woo, or another justified Common Lisp server backend
server-rendered HTML where useful with JS only where it improves the interaction

Select the exact Lisp stack during the design slice; do not introduce a new framework without need.

Authentication

Sign in with StarIntel via central OIDC
use the stable StarIntel subject as user identity
no local password database
application authorization/scopes remain distinct from mere account ownership

Required first-class UI capabilities

overall Auto-Dig status
bounded/recent run list
inspect a run by durable run ID
start a run
pause/resume/stop where authorized
progress/state updates without making browser state authoritative
useful links into results/research artifacts

Reuse the canonical Quasar/Auto-Dig run lifecycle instead of browser automation or direct database/message-broker mutation.

Security

HTTPS only
backend control authority remains server-side
no bearer tokens in URLs/logs/rendered pages
CSRF/session protections appropriate to chosen web stack
scope/ownership checks for run access and control
bounded request/result sizes

Deployment

runs as an isolated service on the common 2-core StarIntel web host
separate service user/state/secrets from Quasar and other websites
health endpoint and structured logs
declarative StarInfra deployment

TDD / acceptance

anonymous user gets an explicit sign-in flow
authenticated read-only user can view only authorized status/runs
authorized control user can start/pause/resume/stop through canonical lifecycle APIs
cross-user run access fails closed
restart does not make browser/server UI state authoritative over durable run state
exact production build can be deployed at auto-dig.starintel.actor

Dependencies

Quasar canonical Auto-Dig lifecycle/control-plane work
StarIntel OIDC/ZITADEL infrastructure
shared StarIntel web-host infrastructure

## Goal Make `https://auto-dig.starintel.actor` a real StarIntel web application implemented with **Common Lisp web tooling**. Do not expose an internal Auto-Dig runtime/UI shim directly as the public website. ## Architecture The public site runs on the shared StarIntel web host and talks to the canonical Auto-Dig/Quasar control plane through explicit APIs. Suggested implementation direction: - Common Lisp application layer - Clack/Lack-compatible HTTP stack - Hunchentoot, Woo, or another justified Common Lisp server backend - server-rendered HTML where useful with JS only where it improves the interaction Select the exact Lisp stack during the design slice; do not introduce a new framework without need. ## Authentication - **Sign in with StarIntel** via central OIDC - use the stable StarIntel subject as user identity - no local password database - application authorization/scopes remain distinct from mere account ownership ## Required first-class UI capabilities - overall Auto-Dig status - bounded/recent run list - inspect a run by durable run ID - start a run - pause/resume/stop where authorized - progress/state updates without making browser state authoritative - useful links into results/research artifacts Reuse the canonical Quasar/Auto-Dig run lifecycle instead of browser automation or direct database/message-broker mutation. ## Security - HTTPS only - backend control authority remains server-side - no bearer tokens in URLs/logs/rendered pages - CSRF/session protections appropriate to chosen web stack - scope/ownership checks for run access and control - bounded request/result sizes ## Deployment - runs as an isolated service on the common 2-core StarIntel web host - separate service user/state/secrets from Quasar and other websites - health endpoint and structured logs - declarative StarInfra deployment ## TDD / acceptance - anonymous user gets an explicit sign-in flow - authenticated read-only user can view only authorized status/runs - authorized control user can start/pause/resume/stop through canonical lifecycle APIs - cross-user run access fails closed - restart does not make browser/server UI state authoritative over durable run state - exact production build can be deployed at `auto-dig.starintel.actor` ## Dependencies - Quasar canonical Auto-Dig lifecycle/control-plane work - StarIntel OIDC/ZITADEL infrastructure - shared StarIntel web-host infrastructure