# 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.