Standard course package

Infrastructure handled. Business ideas stay flexible.

The platform gives every student the same secure, deployable technical foundation while leaving the product model, workflow, branding, and founder story open to change.

View included functionality See the Lovable-to-Cursor sample

48general functions catalogued

43ready without provider setup

1provider connections available

4safe extension templates

Student implementation path

Four stages, with one documented boundary

Lovable owns the design draft. The project model owns business structure. The platform client owns browser-to-server calls. Protected server routes own data, AI, and side effects.

Define

Choose a preset, then describe users, entities, fields, roles, states, prompts, and triggers in the project model.

src/course/student-project.json

Design

Build the approved user journey in Lovable. Keep stable feature IDs on actions that will need real behaviour.

npm run lovable:brief

Implement

Synchronise the design and use Cursor to replace prototype handlers with the standard platform client.

npm run lovable:sync

Validate and deploy

Run the shared checks, push to GitHub, and let the isolated Cloud Run workflow publish and health-check the project.

npm run setup:check

Cursor implementation contract

Use the client instead of inventing API wiring

Import platform from src/lib/platform/client.ts. The method signatures expose the common operations while keeping credentials and privileged checks on the server.

Create or list recordsplatform.records.create() / .list()

Move through a workflowplatform.workflows.transition()

Evaluate configured rulesplatform.automation.evaluate()

Run an approved AI promptplatform.ai.run()

Publish teacher statusplatform.project.syncStatus()

Framework function registry

48 reusable functions, with activation state

43 ready 1 setup 4 templates

5 included functions

Identity and access

Standard ways to identify users, maintain sessions, and enforce who can see or change data.

What the student does

Choose the smallest useful role set and decide which pages or actions each role needs. Keep the shared callback and session plumbing unchanged.

Start herestudent-project.json → roles + auth

Passwordless email

Supabase one-time sign-in links with a safe server callback.

SignInForm

Ready

GitHub root OAuth

Setup registers one course identity, configures Supabase, and uses the shared callback flow.

/auth/callback

Ready

SSR session refresh

Cookie-backed sessions are refreshed in middleware for pages and API routes.

src/lib/supabase/middleware.ts

Ready

Roles and permissions

Project roles control workflow transitions and server operations.

student-project.json → roles

Ready

Row-Level Security

Database policies isolate owner records while allowing approved teacher oversight.

supabase/migrations

Ready

Live project definition

The model is the source of truth

Students define business nouns and rules in one validated file. Shared forms, APIs, workflows, and agent guidance read the same configuration.

5entities

19fields

3relationships

4roles

1workflows

2triggers

provider_profile

Provider Profile

4 fields

A vetted student helper profile using demo-safe labels.

Display nametext · requiredVerification statusselect · requiredSkillsselect · requiredAvailability notetext

facility

Facility

3 fields

A demo-safe facility record for filtering bookings without storing resident details.

Facility aliastext · requiredAreaselect · requiredApproved session locationselect · required

listing

Service Listing

4 fields

A support session that a verified student can offer.

Service titletext · requiredCategoryselect · requiredDuration minutesnumber · requiredSafety rulelong_text · required

booking

Booking

5 fields

A coordinator request for a supervised session.

Listing titletext · requiredFacility aliastext · requiredRequested datedate · requiredTime slotselect · requiredPublic notelong_text

review

Review

3 fields

A coordinator feedback record after completion.

Booking referencetext · requiredRatingnumber · requiredCommentlong_text

Relationships

Validated model links

booking.listing_title → listing · many-to-onebooking.facility_alias → facility · many-to-onereview.booking_reference → booking · many-to-one

Access configuration

2 sign-in methods

GitHub is the single root identity. Password and magic-link access remain separate recovery paths and never receive the GitHub password.

Magic linkRecovery ready
GitHub OAuthEnabled

adminprovidercoordinatormentor

Configured triggers

2 project rules

Rules use the same condition evaluator demonstrated by LoomGuard and produce standard action plans.

EnabledNotify both sides when a booking is confirmedworkflow.transitioned → 2 actions

EnabledEscalate a recorded no-showworkflow.transitioned → 2 actions

Integration requirements

1 declared connections

Each external service stays disabled until its student-owned provider, credentials, and server adapter are ready.

EnabledGitHub OAuthoauthConfigured automatically in Supabase from the course-owned GitHub OAuth application.

Standard controllers

API routes already available

These stable controllers sit between generated views and project data. Students can add business-specific routes without rebuilding authentication, validation, or health handling.

Method	Path	Purpose	Access
GET	`/api/health`	Deployment and emergency-switch health	Public
GET	`/api/framework`	Sanitized model and function catalogue	Public
GET	`/api/records`	List owned records by entity	Signed in
POST	`/api/records`	Validate and create a model record	Signed in
POST	`/api/records/:id/transition`	Apply an allowed workflow transition	Signed in
POST	`/api/automation/evaluate`	Evaluate configured triggers without external side effects	Signed in
POST	`/api/ai`	Run an enabled, budgeted AI prompt	Signed in
POST	`/api/project-status`	Publish status for teacher oversight	Signed in
GET	`/auth/callback`	Complete magic-link or OAuth sign-in	Provider callback

Machine-readable catalogueThe same sanitized model and function registry is available at /api/framework for dashboards, setup checks, and coding agents.

Clear ownership boundary

What students change, and what the platform protects

The course is designed so students can focus on the business requirement without becoming responsible for every infrastructure concern.

Student-owned work

The product and its explanation

Define the target user and business problem
Change entities, fields, labels, and branding
Approve Lovable designs and explain each intended interaction
Select and explain approved workflow steps
Add limited business rules and display components
Request approval before enabling AI or real PII
Prepare the demo, technical explanation, and founder story

Standard package

The reusable engineering foundation

Authentication, roles, and server sessions
Database migrations and Row-Level Security
Protected APIs and workflow event logging
AI rate limits, budgets, and usage reporting
Environment handling, health checks, and CI
Lovable snapshots and Cursor migration guardrails
Managed resource provisioning and isolated deployment

Current project controls

Compliance and AI stay visible

These controls are read from the same project definition and remain visible when students replace the product interface.

Compliance Boundary

Course demo uses aliases only. Real deployment would need guardian permission, facility approval, background-check policy, and explicit data retention rules.

PII: avoidedMinor users: yesMentor review: required

AI Budget

Enabled project prompt budget: 0.00 USD.

Safety summary: off