Make Lantern Cloudflare D1 native

Author: ottenhoff

AGENTS.md

@@ -66,11 +66,12 @@ Default stack:
 
 - Deno
 - Hono
-- Postgres
+- Cloudflare D1 for persistence
+- Cloudflare R2 for reviewed artifacts and evidence
+- Cloudflare Worker Loader / Dynamic Workers for reviewed runtime delivery
 - hand-written SQL
 - server-rendered HTML
 - plain CSS tokens
-- HTMX only where it clearly helps
 
 Avoid by default:
 
@@ -132,7 +133,7 @@ The platform is the trusted boundary.
 Generated apps should not get:
 
 - raw LMS tokens
-- direct database access
+- direct D1 database access
 - arbitrary outbound HTTP
 - direct grade writes
 

APP_PACKAGE_SPEC.md

@@ -35,7 +35,7 @@ This spec does not support:
 
 - arbitrary backend code
 - direct LMS API access
-- direct database access
+- direct D1 database access
 - arbitrary outbound HTTP
 - direct grade writes
 
@@ -372,29 +372,26 @@ If we add those, we have broken the trust boundary.
 
 ## Runtime Backend Note
 
-This spec defines the app-facing capability contract, not one required hosting
-vendor or transport.
+This spec defines the app-facing capability contract. Lantern's checked-in
+runtime implementation is Cloudflare-native: Workers, D1, R2, and Worker
+Loader / Dynamic Workers.
 
-Lantern may realize this contract through different runtime backends as long as
-the app sees the same narrow SDK surface and the same trust boundary.
-
-For example, a managed Lantern deployment may choose a capability-based sandbox
-such as Cloudflare Dynamic Workers to:
+Lantern realizes this contract through a capability-based Dynamic Worker
+sandbox that:
 
 - block arbitrary outbound Internet access
 - inject only explicit typed bindings that match Lantern capabilities
 - keep LMS credentials and other privileged secrets outside the app sandbox
 
-That does not change the public package contract.
+That does not change the public package contract: app packages remain
+browser-first artifacts and do not receive Cloudflare bindings directly.
 
 Rules:
 
 - app packages must not depend on Cloudflare-specific APIs, bindings, or worker
   internals
-- self-hosted Lantern deployments must be able to honor the same contract
-  through a different backend
-- Dynamic Workers or any similar sandbox may tighten the implementation, but
-  they do not add new app capabilities by themselves
+- Dynamic Workers may tighten the implementation, but they do not add new app
+  capabilities by themselves
 
 ## Scoring Contract
 

AUTHORING.md

@@ -55,15 +55,11 @@ run:
 
 ```sh
 deno task local:init
-createdb lantern
 deno task local:bootstrap
 deno task local:start
 ```
 
-Then open `http://localhost:8417/admin/packages`.
-
-If `createdb` is not installed, create the `lantern` database through your
-normal Postgres tooling before `deno task local:bootstrap`.
+Then open the localhost URL printed by Wrangler.
 
 ## Package Shape
 
@@ -206,7 +202,7 @@ Do not add:
 
 - backend code
 - direct LMS calls
-- direct database calls
+- direct D1 database calls
 - arbitrary outbound HTTP
 - direct grade writes
 - fallback-heavy runtime branches
@@ -233,7 +229,7 @@ and admin import.
 When you want to move a reviewed package into Lantern's governed inventory:
 
 1. Start Lantern locally.
-2. Open `http://localhost:8417/admin/packages/import`.
+2. Open `/admin/packages/import` on the localhost URL printed by Wrangler.
 3. Choose the exact package directory you scaffolded and validated locally.
 
 Lantern validates the manifest and referenced files, stores an immutable

AUTHORING_FOR_LLMS.md

@@ -111,7 +111,7 @@ The app must not expect:
 
 - raw LMS tokens
 - arbitrary network access
-- database access
+- D1 database access
 - server-side execution inside the package
 
 ## Preview Files

BROWSER_AUTOGRADER_COOKBOOK.md

@@ -150,9 +150,9 @@ checks instead of one starter file.
 
 When the package is ready for governed review:
 
-1. Start Lantern locally with `deno task local:init`, `createdb lantern`,
+1. Start Lantern locally with `deno task local:init`,
    `deno task local:bootstrap`, and `deno task local:start`.
-2. Open `http://localhost:8417/admin/packages/import`.
+2. Open `/admin/packages/import` on the localhost URL printed by Wrangler.
 3. Import the exact package directory you validated locally.
 
 Lantern stores an immutable reviewed snapshot, signs the reviewed runtime

DESIGN.md

@@ -0,0 +1,137 @@
+# Lantern Design Principles
+
+Lantern is a governed app platform for institution-built and AI-built learning
+apps. Its interface should make review, approval, launch, grading, and audit
+work feel clear and dependable.
+
+This is the public UI design contract for the repo. It should stay focused on
+implementation-facing principles and reusable interface rules. Private product
+strategy, research, internal operations, and Cloudflare setup details do not
+belong here.
+
+## Product Feel
+
+Lantern should feel:
+
+- institutional
+- clear
+- calm
+- trustworthy
+- more modern than Canvas, but compatible with that world
+
+Lantern should not feel like:
+
+- a flashy startup dashboard
+- a generic app marketplace
+- an LMS replacement
+- a pile of one-off admin screens
+
+The UI exists to make governed learning-app operations legible. It should help
+reviewers and operators understand what is approved, what is live, what changed,
+what failed, and what evidence exists.
+
+## Interface Model
+
+Prefer:
+
+- server-rendered HTML
+- plain CSS tokens
+- strong information hierarchy
+- accessible defaults
+- reusable page and component patterns
+- explicit status, evidence, and next action language
+- dense but readable operational pages
+
+Avoid:
+
+- React-heavy front ends by reflex
+- Tailwind or utility-heavy styling
+- highly custom one-off UI patterns
+- decorative effects that compete with operational facts
+- marketing-page composition inside the admin product
+- hidden fallback flows or ambiguous recovery states
+
+When a page is about governance, the primary facts should be visible before
+secondary decoration or explanation.
+
+## Visual Language
+
+Use a quiet institutional palette:
+
+- navy and blue-gray for structure and primary actions
+- warm amber only as a restrained brand accent
+- green, amber, and red for semantic success, warning, and danger states
+- light surfaces with clear borders and enough spacing to scan
+
+The current admin tokens live in
+[`src/admin/layout_style_tokens.ts`](src/admin/layout_style_tokens.ts). New
+admin UI should use those tokens before introducing new colors, radii, shadows,
+or spacing systems.
+
+Default shape:
+
+- cards and controls use small radii
+- borders are preferred over heavy shadows
+- status badges should be semantic, compact, and readable
+- tables and fact grids should optimize for scanning and comparison
+
+## Content Rules
+
+Use plain operational language.
+
+Good Lantern copy:
+
+- names the object being acted on
+- states the exact status or blocker
+- names the trusted boundary when relevant
+- explains failures clearly without exposing secrets
+- gives one obvious next step when a next step exists
+
+Avoid copy that:
+
+- implies generated apps have raw LMS, D1 database, or grading access
+- hides governance behind vague success states
+- invents compatibility promises the system does not actually provide
+- exposes private tenant, infrastructure, pricing, or strategy details
+
+## Workflow Rules
+
+Every admin workflow should make these questions easy to answer:
+
+1. What app, version, deployment, LMS slot, attempt, or placement am I looking at?
+2. Is it reviewed, approved, live, blocked, or failed?
+3. What exact boundary produced this state?
+4. What durable evidence exists?
+5. What is the one safe next action?
+
+Prefer one correct path over several similar actions. If a task is unavailable,
+fail clearly and keep the user inside a Lantern-owned page.
+
+## Accessibility
+
+Accessibility is part of the governance model, not polish.
+
+Design and implementation should preserve:
+
+- semantic headings and landmarks
+- keyboard-reachable controls
+- visible focus states
+- readable contrast
+- labels for form controls
+- stable layout at narrow and wide viewport sizes
+- clear error text near the relevant action
+
+When a reviewed package has accessibility evidence or exceptions, surface that
+state before it goes live.
+
+## Review Checklist
+
+Before shipping UI changes, check:
+
+- The page still feels institutional, clear, and calm.
+- Primary governance facts are visible without hunting.
+- New styles reuse existing tokens and patterns.
+- Buttons and links have clear action language.
+- Failure states are explicit and do not silently degrade.
+- No private strategy, secrets, account details, or infra values appear.
+- The change keeps the trusted LMS/runtime/grading boundary legible.

Dockerfile

@@ -21,4 +21,4 @@ USER deno
 
 EXPOSE 8417
 
-CMD ["deno", "run", "--cached-only", "--no-prompt", "--allow-read=examples,var", "--allow-write=var", "--allow-env=PORT,DATABASE_URL,DATABASE_CA_CERT,LTI_TOOL_PRIVATE_JWK,APP_ORIGIN,APP_RUNTIME_ORIGIN,LANTERN_OPERATOR_NAME,USER,LOGNAME", "--allow-net", "main.ts"]
+CMD ["deno", "run", "--cached-only", "--no-prompt", "--allow-read=examples,var", "--allow-write=var", "--allow-env=PORT,LTI_TOOL_PRIVATE_JWK,APP_ORIGIN,APP_RUNTIME_ORIGIN,LANTERN_OPERATOR_NAME,USER,LOGNAME", "--allow-net", "main.ts"]