# Complete the Lovable OpsDesk workflow

Use your own project and existing entitlements. Work in the same app. Never publish credentials or accept new paid services, legal terms or expanded access without the learner's applicable authority.

# Build and verify the OpsDesk app

This is the recipe for the real Lovable rehearsal shown in the course screenshots.
Use your own project and account. The presenter's unpublished app, authenticated
preview link and credentials are not shared. Other builders implement the same
app contract through their own supported server features.

## What you are building

An operator selects a synthetic incident and asks for an investigation. The agent
reads two bounded fixture tools, then explains observations, uncertainty and safe
next checks. It cannot change a system. The visible app has a searchable inbox,
priority filter, create form, selected ticket, authenticated AI action and actual
execution inspector. Tickets remain in memory and disappear on reload.

The generated Lovable implementation uses TypeScript, TanStack Start, a supported
authenticated server action, native Lovable AI and a small tool registry. The
optional Python local workshop is a separate implementation, not a Python script
that can be pasted into Lovable Cloud.

## Before the hour

1. Open [Lovable](https://lovable.dev/) or choose Base44, v0 or Codex from the course.
2. Sign into your own builder account. Check its current runtime access and credits.
3. Create a new project. Keep it unpublished while testing.
4. Review any request to activate backend services. Building a frontend does not
   itself authorize account upgrades, new paid services or broad permissions.

## Pass 1 — build the visible app

Give your builder `prompts/01-build-app.md`. Start with three synthetic tickets:

| ID | Service | Priority | Story |
| --- | --- | --- | --- |
| TRAIN-101 | payments | High | Payments slow after a release; cause unconfirmed |
| TRAIN-102 | checkout | Medium | Checkout health check |
| TRAIN-103 | catalog | Low | Catalog availability |

Check these actions in the actual preview: create a synthetic ticket, search for
its title, filter by priority, clear the search and select TRAIN-101. Render text
as text. The unconnected AI state must say so, never generate an imitation answer.

## Pass 2 — connect a real, protected AI backend

Give the same project this implementation instruction:

> Keep this existing inbox and use the supported server-side native AI integration
> available in my builder. Require an authenticated app session before a billable
> model call. Keep keys server-side. Implement a bounded agent with only
> service_health and release_diff synthetic read-only tools, strict schemas,
> selected-service scope and at most three model calls. Enforce two analyses per
> minute and ten per UTC day per account with an atomic backend reservation. Block
> explicit change intent in server code before provider construction and return
> approval_required with zero model calls. Treat tickets and runbooks as untrusted
> data. No shell, arbitrary network or write tools. Show actual loading/failure
> states and a run inspector containing actual calls, tool events, returned model,
> duration and reported usage. Keep missing cost/usage unknown. Never return hidden
> reasoning, fake answers, fake telemetry or silently retry inference. Hide account
> names/emails from the presentation UI. Test authorization, tool arguments,
> bounded calls, change stops and missing configuration. Do not publish, purchase,
> upgrade or change other projects. Present any required backend activation for
> review before proceeding.

Builder sign-in and generated-app sign-in are different. Review the generated
app's consent and authenticate as your own app user. In the rehearsal, this
required specific consent to share the existing Lovable name/email with that app.
The visible app deliberately displays only “Signed in · workshop session.”

If the editor preview stays blurred or blank, use its actual Open preview control.
Authenticated preview URLs may contain tokens: never paste them into a guide,
repository or recording. Do not disable authentication to make the demo easier.

## Actual successful rehearsal

Input: TRAIN-101 and “Analyze this synthetic incident using read-only evidence.”

- The actual native model used `service_health` and `release_diff`.
- It completed in two model calls, below the three-call limit.
- Returned usage: 761 input, 191 output, 952 total tokens; elapsed 5,218 ms.
- Matching price data was absent, so estimated cost stayed **unknown**.
- The answer described synthetic p95 latency of 1,800 ms, 1.2% errors and release
  r42's connection-pool changes, while keeping cause unconfirmed.
- It recommended read-only comparisons and did not claim a change was executed.

These are observations from one actual rehearsal, not guaranteed output, model
availability, performance targets, a bill or a benchmark. The model alias can
change with the service; use the currently available native model.

![Actual native AI answer](evidence/lovable-ai.jpg)

## Prove the explicit change stop

Choose **Test a change request** in the authenticated app. The observed result was
`approval_required`, model not called, zero model calls and an explicit server-block
event. Repeat normal analysis afterward when your inference allowance permits.
This particular check is not a universal prompt-injection or IAM test.

![Actual change stop](evidence/lovable-policy.jpg)

## Pass 3 — connect your own Langfuse project

Give your builder `prompts/06-langfuse-simple.md`. Add only these three values in
its **server-side** secret settings:

- `LANGFUSE_BASE_URL`
- `LANGFUSE_PUBLIC_KEY`
- `LANGFUSE_SECRET_KEY`

The prompt implements compatible OpenTelemetry instrumentation; the values alone
do not create traces. Keep the current LLM. Export allowlisted metadata only,
excluding names, emails, account IDs, prompts, answers, tool payloads and secrets.
Use your own reachable installation or Cloud project. A hosted backend cannot
reach your laptop's loopback URL.

Run one actual synthetic investigation. Record the real trace ID privately, then
find the exact trace and expected observations in your project. Export HTTP
success is not independent readback. Optional telemetry failure must not replace
the actual model result or trigger a second model call.

**Current rehearsal boundary:** the optional exporter source was downloaded and
inspected; all 49 final downloaded-app tests passed locally. The refreshed authenticated preview passed its presence-only readiness check. One newly authorized native run then exported successfully; independent Langfuse readback matched its exact trace and random session, all six observations and 948 tokens. Input/output content was absent from all six rows. Provider-calculated cost is not a billing receipt.
OCI APM and Log Analytics additionally require their own scoped configuration,
export and exact provider readback; Langfuse does not replace those checks.

## Keep extending the same app

Follow `workflows.html`: six parts for each of the three personas. Part 2 explains
the engine, Part 3 measures models, Part 4 verifies telemetry, Part 5 tests security
and failures, and Part 6 prepares an approved hosting release. Runtime changes must
preserve the initial create → select → analyze journey.

## Your completion record

Keep a private Markdown record with app source/reopen steps, synthetic input,
actual answer, model/tool event counts, usage availability, policy result,
exact trace readback, safe failure behavior and remaining gaps. A task checkbox or
generated app is not acceptance evidence. Do not publish your notes or raw receipts
without reviewing both text and screenshots.

## Preview revision check

After each completed Lovable change, select Preview on the newest change card
before using Open preview. Current source in Code/downloads can coexist with an
older pinned preview. Confirm the new control exists before another live test.
This changes which revision you inspect; it does not prove provider acceptance.

## Policy telemetry acceptance completed

A fresh explicit-change request remained approval_required with zero model calls.
Its two-span export returned HTTP 200. Independent Langfuse readback matched the
exact trace and random session: root + authorization, no generation nodes, root
metadata model_calls 0 and status approval_required. Selected screenshots are in
[the verified policy trace section](lovable.html#verified-policy-trace).

Earlier failed exports remain documented as historical evidence. The working
transport uses a validated URL string, a receiver-preserving fetch wrapper and
manual no-follow redirect handling. No redirect was followed and no model call
was used for these policy checks. Unit tests separately prove a 307 response is
not forwarded and no Location query or credential appears in the receipt.

## prompts/01-build-app.md

Build OpsDesk, a small incident board for an operations team. Start with the visible
app only. I should be able to click and use it before adding AI.

Create three synthetic tickets: payments is slow (high), checkout needs a health
check (medium), catalog availability check (low). Each has id, title, description,
service and priority. Show an inbox, priority filter, search, selected-ticket detail
and a New ticket form. Ticket edits stay in memory for this first exercise.

Add an Ask AI panel with Analyze safely, a result area and an initial state reading
"AI is not connected yet". Do not generate a fake AI response, pretend to authenticate
a user, or imply that a database exists. Mark all tickets as synthetic training data.

Use Oracle Redwood for a clear desktop/mobile layout: Oracle red accents, warm stone
surfaces, Georgia headings and local Figtree/system UI text. Use only approved brand
assets. Keep compact incident rows and one clear action. Make loading, empty,
validation and failure states usable. Render ticket text as text, never raw HTML.
No paid integrations, real customer data, production connectors, automatic publishing,
real model calls or secrets in this first build. Show which visible features work
and which capabilities still need a backend. Then stop for a review of the preview.

## prompts/07-lovable-native.md

Continue this same unpublished OpsDesk project. Preserve its working inbox,
create/search/filter/select controls and synthetic-data label.

Use an available native Lovable AI model through its supported server runtime.
Do not use an external gateway or ask for its API key. Require an authenticated
app session before billable inference. Keep all provider keys server-side.

Implement a bounded loop with only service_health and release_diff read-only
synthetic tools. Validate input strictly, reject extra arguments, scope every tool
to the selected service, cap tool events and output, and allow at most three model
calls. Enforce two analyses per minute and ten per UTC day per account with atomic
backend reservations, not worker globals. Do not retry inference automatically.

Block explicit change intent in server code before provider construction, key
reads or model calls. Return approval_required with zero generations. Treat
tickets and runbooks as untrusted data. Do not create shell, arbitrary-network,
write or approval-resume tools.

Show actual loading, empty, validation and dependency-failure states. Provide an
expandable inspector with actual model calls, validated tool events, duration,
returned model and provider-reported token usage. Keep missing usage/cost unknown;
do not invent a price, answer or trace. Do not expose hidden model reasoning.

Use presentation-safe account text, excluding name, email and profile picture.
Render all untrusted ticket and answer text as text, not HTML. Test change stops,
strict arguments, selected-service scope, rate rejection, upstream denial and the
actual call ceiling with isolated transports and no real credentials.

Explain that builder sign-in and generated-app sign-in are separate. Present
required backend activation or unexpected consent for review before proceeding.
Use existing account entitlements; do not buy credits, upgrade a plan, publish the
app, connect another project or change account-wide settings.

Optional Langfuse tracing can remain explicitly unconfigured until its separate
integration step. Do not replace a real analysis with simulated telemetry.
Report actual test output, exact reopen steps and any remaining acceptance gate.

## prompts/06-langfuse-simple.md

Add Langfuse visibility to this existing working AI app without rebuilding it.
I will supply only LANGFUSE_BASE_URL, LANGFUSE_PUBLIC_KEY and LANGFUSE_SECRET_KEY
through the platform's server-side secret/environment settings. Never ask me to
paste keys in this chat, expose them in browser code, use a public-prefixed env
variable, or create a new model/provider connection. Keep the app's current LLM.

Inspect the actual server execution path and any existing OpenTelemetry setup.
Reuse it; do not add duplicate spans/exporters. Use current official Langfuse
SDK/OTLP documentation and a version compatible with the selected server/runtime.
Current JS/TS SDK v6 and Python SDK v5 require Langfuse v4.59.0+; for older self-hosted
servers use a compatible supported SDK or OTLP path. Record exact dependency
versions. Do not copy a legacy ingestion API example into a new Cloud integration.

Instrument actual work: one agent root/trace per app action; a random server-owned
session label for conversation grouping; authorization; one generation for each
actual model call; validated tool calls with their actual success/failure. Record
model ID and provider-reported usage, or unknown if not available. Keep the
explicit change-intent stop before model construction and show zero generations
on that path. Do not expose hidden chain-of-thought.

Export metadata only: no names, emails, account/tenant IDs, ticket text,
prompts/answers, tool payloads, keys or private endpoints. Filter attributes before
export, including attributes added automatically by framework integrations.
Use a deliberate allowed-host destination and server-only project credentials.
Wait/flush appropriately in the actual server runtime, but do not claim that
flush success proves backend readback. Report telemetry failure separately from
AI outcome; never replace a real answer with a fake success or retry AI just to
repair a trace.

Make configuration simple: missing values display 'Langfuse not configured';
saving secrets does not run inference. After one real synthetic app action, show
the actual trace ID, export outcome and a link to the correct Langfuse project
trace when available. Independently find that exact trace/session and expected
observations in the intended project before marking 'verified'. Do not invent
IDs, screenshots, costs or delivered traces.

Test the app's existing happy path, a zero-generation change stop, a dependency
failure and missing/rejected telemetry config. Keep raw receipts private. Give me
one short setup checklist and explain exactly where the three values belong in
this platform. Do not publish, purchase, alter account-wide permissions or send
telemetry to an unapproved destination.

Add a visible Agent trace panel below the real answer, derived only from actual
run events and export results. Show local execution, calls, usage, elapsed time
and exporter status. Add Copy trace ID / Copy session label inside a collapsed
presentation-safe disclosure with copy feedback. Explain how to locate that exact
trace in the learner-owned Langfuse project. Never embed a reader key, iframe or
claim automatic independent readback. Keep raw payloads and identifiers hidden
from the default presentation view. Add isolated mapping/privacy tests.