# OpsDesk complete workflow — No IT knowledge / C-level

Six sequential parts. This bundle contains agent instructions, not provider acceptance. Keep the same app; finish and verify each part before proceeding.

---

# OpsDesk · Business leaders & first-time builders · Part 1

## Instructions for the agent

Extend the same working OpsDesk app. Read applicable project instructions, inspect the baseline and preserve unrelated work. Use synthetic data and the learner’s explicitly selected model. Never invent an answer, token count, trace or acceptance result. Keep credentials in private server-side configuration. Do not publish, buy credits, activate cloud services, change IAM or expand access without exact authority.

## Learner and method

No IT knowledge / C-level

Browser-first. Describe the outcome, use a builder and validate the result in plain language.

## Prerequisites

An owned builder account, available build credits and an explicitly selected app AI/backend option. No terminal is required for this route.

## Starting state

A fresh learner workspace and a working, student-owned tool-capable model endpoint.

## New capability

A functional incident inbox and one real AI investigation.

## Follow this workflow

## Words used in this route

- **Backend:** The private part of the app that calls AI and runs approved lookups; your builder can generate it.
- **Tool evidence:** Information returned by an actual permitted lookup, not a model’s guess.
- **Guardrail:** A rule enforced by the app before an action can run.

1. Describe the operator and payments incident in one sentence; choose one builder and confirm available credits.
2. Paste the app definition. Click create, search, filter and select; ask the builder to fix one actual usability issue.
3. Use an explicitly selected managed AI option or a supported private server integration. Add keys only through its server-side secret UI, never the project chat.
4. Click Analyze safely on the selected ticket. Require a real answer with actual evidence, then verify loading and failure messages.

## Request for the implementation agent

Extend our existing OpsDesk app for Part 1: A functional incident inbox and one real AI investigation. Follow this No IT knowledge / C-level learner route. Explain the next action in plain language and use the builder UI; do not require me to run terminal commands. Implement backend checks in code, not just in a prompt. Use synthetic data and my explicitly selected backend. Never invent a successful answer, usage or trace. Keep keys in server secrets. Do not publish, buy credits, activate cloud services or change permissions without specific authority. Complete the route actions, verify actual results and report blockers honestly.

## Completion gates

- [ ] Create, search, filter and select an invented ticket in the actual app.
- [ ] Analyze the selected ticket using a real configured model and at least one permitted tool; display the actual answer.
- [ ] Show loading, busy and failure states without fake AI success, browser keys or automatic retries.
- [ ] Restart the app using documented commands and reproduce the core journey. Persistence beyond the documented memory lifetime is not required.

## If blocked

If access, credentials or native model support are missing, preserve the working app and mark that acceptance checkpoint blocked. A local model-double test or static preview is not a real app/model/provider result.

## Handoff

Record files or builder changes, exact synthetic input, actual app outcome, start/stop or reopen steps, evidence references and unresolved gaps. Preserve the working app for the next part. Mark results as local/model-double/browser-reference/provider-verified; do not merge these evidence classes. Never claim that a successful login or preview completes the real AI journey.

## Deeper explanations

- [Lovable quick start](https://docs.lovable.dev/introduction/getting-started): Understand the prompt → preview loop and build-credit prerequisites.
- [Course implementation reference](../replicate.html): Use the detailed setup, contracts and troubleshooting when you need the technical layer.

## First-time builder help

Start with the visible app definition in prompts/01-build-app.md. Then connect the actual AI action using prompts/02-connect-agent.md and API-CONTRACT.md. Ask your builder to implement server code through its supported backend features; a chat subscription alone is not a runtime integration. Use langfuse.html for observability and GUARDRAILS.md for enforced controls. If you require a local-code alternative, switch explicitly to the IT starter route rather than pretending the browser-only route has been executed.

## 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/02-connect-agent.md

Connect OpsDesk's AI panel to a server-owned agent, keeping the visible app unchanged.
Use the workshop API contract and the exact operator-approved endpoint supplied
outside this prompt. Do not invent a URL, model, key or successful response.

The agent must inspect the selected synthetic incident, use read-only service_health
and release_diff if registered, separate observations from hypotheses and recommend
one safe next check. It cannot run shell, read credentials, deploy or roll back.
Use the explicitly selected model; no automatic provider or scripted fallback.

Keep credentials in your platform's server-side secret store. Browser code calls
our same-origin server function, not the provider or OCI IAM endpoint directly.
Derive session/user scope on the server; never trust a browser-supplied tenant or
permission claim. Validate ticket IDs/fields and cap body size, steps and output.

Add a Test a change request control. Enforce its change intent in code before model
construction; return approval_required without any model invocation or real change.
Implement busy, failure and unavailable-backend states. No automatic retry of AI.
Keep real failures visible and verify that creating/filtering tickets still works.
Do not expose a local server through a public tunnel or enable wildcard CORS.

---

# OpsDesk · Business leaders & first-time builders · Part 2

## Instructions for the agent

Extend the same working OpsDesk app. Read applicable project instructions, inspect the baseline and preserve unrelated work. Use synthetic data and the learner’s explicitly selected model. Never invent an answer, token count, trace or acceptance result. Keep credentials in private server-side configuration. Do not publish, buy credits, activate cloud services, change IAM or expand access without exact authority.

## Learner and method

No IT knowledge / C-level

Browser-first. Describe the outcome, use a builder and validate the result in plain language.

## Prerequisites

An owned builder account, available build credits and an explicitly selected app AI/backend option. No terminal is required for this route.

## Starting state

The working OpsDesk app from Part 1, with a saved baseline revision or source copy.

## New capability

A learner-owned tool registry and bounded agent engine behind the existing app.

## Follow this workflow

## Words used in this route

- **Backend:** The private part of the app that calls AI and runs approved lookups; your builder can generate it.
- **Tool evidence:** Information returned by an actual permitted lookup, not a model’s guess.
- **Guardrail:** A rule enforced by the app before an action can run.

1. Keep the working inbox. Write the agent’s allowed job: read health and release clues; do not apply changes.
2. Ask the builder to implement those rules in server code with a narrow tool list and limits.
3. Try one permitted question, one change request and one unavailable capability using synthetic data.
4. Compare the UI result with the actual action log. A refusal paragraph alone is insufficient.

## Request for the implementation agent

Extend our existing OpsDesk app for Part 2: A learner-owned tool registry and bounded agent engine behind the existing app. Follow this No IT knowledge / C-level learner route. Explain the next action in plain language and use the builder UI; do not require me to run terminal commands. Implement backend checks in code, not just in a prompt. Use synthetic data and my explicitly selected backend. Never invent a successful answer, usage or trace. Keep keys in server secrets. Do not publish, buy credits, activate cloud services or change permissions without specific authority. Complete the route actions, verify actual results and report blockers honestly.

## Completion gates

- [ ] Existing inbox and analysis still work after the engine change.
- [ ] The fixed harness contracts pass; an unknown tool and invalid arguments cannot execute handlers.

## If blocked

If access, credentials or native model support are missing, preserve the working app and mark that acceptance checkpoint blocked. A local model-double test or static preview is not a real app/model/provider result.

## Handoff

Record files or builder changes, exact synthetic input, actual app outcome, start/stop or reopen steps, evidence references and unresolved gaps. Preserve the working app for the next part. Mark results as local/model-double/browser-reference/provider-verified; do not merge these evidence classes. Never claim that a successful login or preview completes the real AI journey.

## Deeper explanations

- [Lovable connector types](https://docs.lovable.dev/integrations/introduction): Distinguish chat context from capabilities available to the running app.
- [Course implementation reference](../replicate.html): Use the detailed setup, contracts and troubleshooting when you need the technical layer.

## First-time builder help

Start with the visible app definition in prompts/01-build-app.md. Then connect the actual AI action using prompts/02-connect-agent.md and API-CONTRACT.md. Ask your builder to implement server code through its supported backend features; a chat subscription alone is not a runtime integration. Use langfuse.html for observability and GUARDRAILS.md for enforced controls. If you require a local-code alternative, switch explicitly to the IT starter route rather than pretending the browser-only route has been executed.

---

# OpsDesk · Business leaders & first-time builders · Part 3

## Instructions for the agent

Extend the same working OpsDesk app. Read applicable project instructions, inspect the baseline and preserve unrelated work. Use synthetic data and the learner’s explicitly selected model. Never invent an answer, token count, trace or acceptance result. Keep credentials in private server-side configuration. Do not publish, buy credits, activate cloud services, change IAM or expand access without exact authority.

## Learner and method

No IT knowledge / C-level

Browser-first. Describe the outcome, use a builder and validate the result in plain language.

## Prerequisites

An owned builder account, available build credits and an explicitly selected app AI/backend option. No terminal is required for this route.

## Starting state

The same app with the bounded engine from Part 2.

## New capability

Model selection, capability checks and transparent token/cost reporting.

## Follow this workflow

## Words used in this route

- **Backend:** The private part of the app that calls AI and runs approved lookups; your builder can generate it.
- **Tool evidence:** Information returned by an actual permitted lookup, not a model’s guess.
- **Guardrail:** A rule enforced by the app before an action can run.

1. Keep the same app. Choose only explicitly supported models in your own backend/provider settings.
2. Ask the builder to add a model selector backed by a server-owned allowlist; never a free-text endpoint field.
3. Run the same synthetic investigation once per available model and compare correctness, time and reported usage.
4. Display estimated cost only with matching sourced rates. Leave missing values unknown.

## Request for the implementation agent

Extend our existing OpsDesk app for Part 3: Model selection, capability checks and transparent token/cost reporting. Follow this No IT knowledge / C-level learner route. Explain the next action in plain language and use the builder UI; do not require me to run terminal commands. Implement backend checks in code, not just in a prompt. Use synthetic data and my explicitly selected backend. Never invent a successful answer, usage or trace. Keep keys in server secrets. Do not publish, buy credits, activate cloud services or change permissions without specific authority. Complete the route actions, verify actual results and report blockers honestly.

## Completion gates

- [ ] Switch only among explicitly configured model aliases; preserve the same ticket workflow.
- [ ] Display actual reported usage and sourced estimated cost, or unknown when missing.

## If blocked

If access, credentials or native model support are missing, preserve the working app and mark that acceptance checkpoint blocked. A local model-double test or static preview is not a real app/model/provider result.

## Handoff

Record files or builder changes, exact synthetic input, actual app outcome, start/stop or reopen steps, evidence references and unresolved gaps. Preserve the working app for the next part. Mark results as local/model-double/browser-reference/provider-verified; do not merge these evidence classes. Never claim that a successful login or preview completes the real AI journey.

## Deeper explanations

- [OpenTelemetry trace concepts](https://opentelemetry.io/docs/concepts/signals/traces/): Understand parent/child spans and causal correlation.
- [Course implementation reference](../replicate.html): Use the detailed setup, contracts and troubleshooting when you need the technical layer.

## First-time builder help

Start with the visible app definition in prompts/01-build-app.md. Then connect the actual AI action using prompts/02-connect-agent.md and API-CONTRACT.md. Ask your builder to implement server code through its supported backend features; a chat subscription alone is not a runtime integration. Use langfuse.html for observability and GUARDRAILS.md for enforced controls. If you require a local-code alternative, switch explicitly to the IT starter route rather than pretending the browser-only route has been executed.

---

# OpsDesk · Business leaders & first-time builders · Part 4

## Instructions for the agent

Extend the same working OpsDesk app. Read applicable project instructions, inspect the baseline and preserve unrelated work. Use synthetic data and the learner’s explicitly selected model. Never invent an answer, token count, trace or acceptance result. Keep credentials in private server-side configuration. Do not publish, buy credits, activate cloud services, change IAM or expand access without exact authority.

## Learner and method

No IT knowledge / C-level

Browser-first. Describe the outcome, use a builder and validate the result in plain language.

## Prerequisites

An owned builder account, available build credits and an explicitly selected app AI/backend option. No terminal is required for this route.

## Starting state

The same app with a verified model binding and usage display from Part 3.

## New capability

Correlated OTel spans, Langfuse readback and an OCI app/log integration path.

## Follow this workflow

## Words used in this route

- **Backend:** The private part of the app that calls AI and runs approved lookups; your builder can generate it.
- **Tool evidence:** Information returned by an actual permitted lookup, not a model’s guess.
- **Guardrail:** A rule enforced by the app before an action can run.

1. Create your own hosted Langfuse project or use your own existing installation. Keep its project keys private.
2. Give the builder the instrumentation prompt. Store project keys in server secrets and disable content capture.
3. Run one synthetic ticket action and find its actual trace ID in your own Langfuse project.
4. Explain local recording, delivery and readback in plain language. APM/log integration is an optional separate setup.

## Request for the implementation agent

Extend our existing OpsDesk app for Part 4: Correlated OTel spans, Langfuse readback and an OCI app/log integration path. Follow this No IT knowledge / C-level learner route. Explain the next action in plain language and use the builder UI; do not require me to run terminal commands. Implement backend checks in code, not just in a prompt. Use synthetic data and my explicitly selected backend. Never invent a successful answer, usage or trace. Keep keys in server secrets. Do not publish, buy credits, activate cloud services or change permissions without specific authority. Complete the route actions, verify actual results and report blockers honestly.

## Completion gates

- [ ] Show actual generation/tool spans and an exact Langfuse trace readback in the configured project.
- [ ] Keep existing app features working; treat APM/log delivery as separate acceptance.

## If blocked

If access, credentials or native model support are missing, preserve the working app and mark that acceptance checkpoint blocked. A local model-double test or static preview is not a real app/model/provider result.

## Handoff

Record files or builder changes, exact synthetic input, actual app outcome, start/stop or reopen steps, evidence references and unresolved gaps. Preserve the working app for the next part. Mark results as local/model-double/browser-reference/provider-verified; do not merge these evidence classes. Never claim that a successful login or preview completes the real AI journey.

## Deeper explanations

- [Langfuse OTel integration](https://langfuse.com/integrations/native/opentelemetry): Check endpoint/auth conventions and ingestion-version behavior.
- [Course implementation reference](../langfuse.html): Use the detailed setup, contracts and troubleshooting when you need the technical layer.

## First-time builder help

Start with the visible app definition in prompts/01-build-app.md. Then connect the actual AI action using prompts/02-connect-agent.md and API-CONTRACT.md. Ask your builder to implement server code through its supported backend features; a chat subscription alone is not a runtime integration. Use langfuse.html for observability and GUARDRAILS.md for enforced controls. If you require a local-code alternative, switch explicitly to the IT starter route rather than pretending the browser-only route has been executed.

---

# OpsDesk · Business leaders & first-time builders · Part 5

## Instructions for the agent

Extend the same working OpsDesk app. Read applicable project instructions, inspect the baseline and preserve unrelated work. Use synthetic data and the learner’s explicitly selected model. Never invent an answer, token count, trace or acceptance result. Keep credentials in private server-side configuration. Do not publish, buy credits, activate cloud services, change IAM or expand access without exact authority.

## Learner and method

No IT knowledge / C-level

Browser-first. Describe the outcome, use a builder and validate the result in plain language.

## Prerequisites

An owned builder account, available build credits and an explicitly selected app AI/backend option. No terminal is required for this route.

## Starting state

The same app with the instrumentation and evidence map from Part 4.

## New capability

Focused policy, ownership, injection and failure regression coverage.

## Follow this workflow

## Words used in this route

- **Backend:** The private part of the app that calls AI and runs approved lookups; your builder can generate it.
- **Tool evidence:** Information returned by an actual permitted lookup, not a model’s guess.
- **Guardrail:** A rule enforced by the app before an action can run.

1. Review the allowed actions in plain language and ask which are enforced by code.
2. Run the explicit change-request control; require zero model generations for that branch.
3. Use the synthetic malicious-runbook case and a controlled failed request. Check the actual outcome, not just the wording.
4. Ask the builder to document remaining gaps such as production identity and PII filtering; do not claim they already exist.

## Request for the implementation agent

Extend our existing OpsDesk app for Part 5: Focused policy, ownership, injection and failure regression coverage. Follow this No IT knowledge / C-level learner route. Explain the next action in plain language and use the builder UI; do not require me to run terminal commands. Implement backend checks in code, not just in a prompt. Use synthetic data and my explicitly selected backend. Never invent a successful answer, usage or trace. Keep keys in server secrets. Do not publish, buy credits, activate cloud services or change permissions without specific authority. Complete the route actions, verify actual results and report blockers honestly.

## Completion gates

- [ ] Prove policy stop before model construction, cross-session isolation and explicit dependency failure.
- [ ] Rerun prior app/model/trace checks after each mitigation.

## If blocked

If access, credentials or native model support are missing, preserve the working app and mark that acceptance checkpoint blocked. A local model-double test or static preview is not a real app/model/provider result.

## Handoff

Record files or builder changes, exact synthetic input, actual app outcome, start/stop or reopen steps, evidence references and unresolved gaps. Preserve the working app for the next part. Mark results as local/model-double/browser-reference/provider-verified; do not merge these evidence classes. Never claim that a successful login or preview completes the real AI journey.

## Deeper explanations

- [OWASP prompt injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/): Understand why instruction guidance alone cannot enforce permissions.
- [Course implementation reference](../GUARDRAILS.md): Use the detailed setup, contracts and troubleshooting when you need the technical layer.

## First-time builder help

Start with the visible app definition in prompts/01-build-app.md. Then connect the actual AI action using prompts/02-connect-agent.md and API-CONTRACT.md. Ask your builder to implement server code through its supported backend features; a chat subscription alone is not a runtime integration. Use langfuse.html for observability and GUARDRAILS.md for enforced controls. If you require a local-code alternative, switch explicitly to the IT starter route rather than pretending the browser-only route has been executed.

---

# OpsDesk · Business leaders & first-time builders · Part 6

## Instructions for the agent

Extend the same working OpsDesk app. Read applicable project instructions, inspect the baseline and preserve unrelated work. Use synthetic data and the learner’s explicitly selected model. Never invent an answer, token count, trace or acceptance result. Keep credentials in private server-side configuration. Do not publish, buy credits, activate cloud services, change IAM or expand access without exact authority.

## Learner and method

No IT knowledge / C-level

Browser-first. Describe the outcome, use a builder and validate the result in plain language.

## Prerequisites

An owned builder account, available build credits and an explicitly selected app AI/backend option. No terminal is required for this route.

## Starting state

The same app with the tested security controls from Part 5.

## New capability

A reviewed hosting adapter, release packet and optional authorized OCI deployment.

## Follow this workflow

## Words used in this route

- **Backend:** The private part of the app that calls AI and runs approved lookups; your builder can generate it.
- **Tool evidence:** Information returned by an actual permitted lookup, not a model’s guess.
- **Guardrail:** A rule enforced by the app before an action can run.

1. Keep the app baseline and ask the coding assistant for a hosting handoff packet.
2. Review who can access it, which identity it uses, how costs are monitored and who owns rollback.
3. Use only a separately authorized prepared OCI target for a live walkthrough; otherwise label the handoff design-only.
4. Explain the actual app result and available trace evidence. Leave hosted acceptance pending when you cannot invoke the target.

## Request for the implementation agent

Extend our existing OpsDesk app for Part 6: A reviewed hosting adapter, release packet and optional authorized OCI deployment. Follow this No IT knowledge / C-level learner route. Explain the next action in plain language and use the builder UI; do not require me to run terminal commands. Implement backend checks in code, not just in a prompt. Use synthetic data and my explicitly selected backend. Never invent a successful answer, usage or trace. Keep keys in server secrets. Do not publish, buy credits, activate cloud services or change permissions without specific authority. Complete the route actions, verify actual results and report blockers honestly.

## Completion gates

- [ ] Validate the local release and adapter contract without losing prior features.
- [ ] Live deployment completion additionally requires authenticated hosted invocation and independent telemetry readback; otherwise mark deployment pending.

## If blocked

If access, credentials or native model support are missing, preserve the working app and mark that acceptance checkpoint blocked. A local model-double test or static preview is not a real app/model/provider result.

## Handoff

Record files or builder changes, exact synthetic input, actual app outcome, start/stop or reopen steps, evidence references and unresolved gaps. Preserve the working app for the next part. Mark results as local/model-double/browser-reference/provider-verified; do not merge these evidence classes. Never claim that a successful login or preview completes the real AI journey.

## Deeper explanations

- [OCI applications and deployments](https://docs.oracle.com/en-us/iaas/Content/generative-ai/applications-deployments.htm): Understand runtime configuration versus an active deployment image.
- [Course implementation reference](../replicate.html): Use the detailed setup, contracts and troubleshooting when you need the technical layer.

## First-time builder help

Start with the visible app definition in prompts/01-build-app.md. Then connect the actual AI action using prompts/02-connect-agent.md and API-CONTRACT.md. Ask your builder to implement server code through its supported backend features; a chat subscription alone is not a runtime integration. Use langfuse.html for observability and GUARDRAILS.md for enforced controls. If you require a local-code alternative, switch explicitly to the IT starter route rather than pretending the browser-only route has been executed.