Kontext Encyclopedia

App Studio

/workspace · version 3.45 · 2026-11-05

Capabilities

App Studio (/workspace) is where you build and change an app. Header: App · Preview · Agents. Code, Publish, Domains, Servers & fuel, Logs, Connections, Build kit, Data, Files and Grow are sections inside App. There is no Chat tab — the composer sits beside Preview. Talk is not this lane. If you shared the project and allowed an editor to run AI, a banner says a collaborator is running an update and offers Stop it. Anything already saved stays. The person you shared with does not get that button.

What is App Studio?

App Studio (/workspace) is where you build and change an app. The switcher says App Studio chat. That is the writing lane, not a tab named Chat. Talk on My Kontext is where you reach Kontext. This page is generate, files, preview, and deploy for one project. Pick the project first.

The header tabs

Header: App · Preview · Agents. Code, Publish, Domains, Servers & fuel, Logs, Connections, Build kit, Data, Files and Grow are sections inside App. There is no Chat tab.

Publish

There is no Platform menu. Publish beside the views opens App → Publish; the sections are always in view inside App. General Chat in the left rail lands on Preview. On a phone, a Chat icon opens a sheet — same lane, not another header view.

New app vs an update

A new app starts from a description in the App sidebar (or General Chat). You get a new project. An update is a targeted change to an app you already have — “fix the settings page,” not “invent a second product.” Launchpad is a twelve-step Path you approve (ten planning steps, two after the build; your mode hides some), then phased build. It is not this composer, and it is not Talk.

Deploy and your app’s data

There is no “only the look” deploy. If people already use the app, ask for an upgrade so the data stays. A reinstall can wipe it. Hosting fuel keeps that server running. AI credits pay generate. Emptying one does not fill the other.

App Studio Agents vs /agents

App Studio Agents is What chat sees plus Connect tools for this project. The Agents module button opens /agents. Connect tools stays off until at least one agent is on under What chat sees.

Your Kontext address

After Servers & fuel and a deploy, each app gets a free address like your-app.kontext.network. Open App → Domains. The top card is Your Kontext address — included with the app. People visit this unless you connect your own domain below. To rename it, press Change this address, type the New address, and Save address. The old address stops working so someone else can use it. HTTPS on the new one can take a minute. Collaborators cannot rename it — the owner does. A purchased or existing domain is optional, in the tabs under that card: New Domain, Existing Domain, Manage. Hub → Money → Your domains lists the free names (they say free) and purchased ones. Rename happens on Domains, not on Hub.

Not yet

App Studio is where project work happens — App, Preview (with the composer) and Agents; App holds Code, Publish, Domains, Servers & fuel, Logs, Connections, Build kit, Data, Files and Grow. All WS- and WT- journeys below cover opening the right project, every leaf, and returning without losing context.

The App Studio is where deep project work happens once you’ve picked a project: AI chat, files, context, infrastructure, deploy, and preview. Open it from Kontext OS, the global module switcher, or deep links; it uses the same project selector pattern as other project-aware modules app-wide.

App Studio → App → Grow (formerly Ecosystem)

Entry: App Studio → select project → App → Grow · Also: post-generation modal after AI build

Grow is the post-build flywheel — one checklist linking your project to every distribution module.

Feature Intent
Growth flywheel checklist Promote on Network, Community post, Marketplace listing, University course, Business solution live, Creator video
Flywheel progress Tracks completed steps; KTX rewards when steps complete
Convert to Business One-click retrofit generated app → Business solution
Marketplace listing Start seller flow from project context
Linked KRNs on courses/programs University instructor settings reference project KRNs
Additional platform modules (quick reference)
Module Route Intent
Agents /agents Recipe-first agent & automation studio
Collaborations /collaborations Collaboration rooms directory
Refine OS window Design polish on generated apps
App Studio publish window OS window Live site, database, hosting, deploy without the full App Studio layout
Project Management /projectManagement Internal team project tracking
Kontext Team hub OS desktop (team role) Helpdesk, PM, Google Workspace, Social shortcuts
Profile (business card) /profile/:handle Public portfolio — projects, stats, message button
Pricing /pricing Subscription tiers and checkout
Gas Station /gas-station Fuel hosted lanes
KRN resolver /r/<krn> (the older /r?krn= still resolves) Open any platform resource by canonical ID
Cross-module sharing
Feature Intent
Unified ShareMenu Network, Messenger, copy link, KRN — from listings, posts, projects
OG / link previews Rich cards when sharing URLs across modules
Site Lift Background design improvement jobs with notification when ready
PWA install Add Kontext to home screen; mobile-optimized module shells
Main Features
1. AI-Powered Chat Interface
2. Intelligent File Management
3. Monaco Code Editor
4. Side Panel System
5. Live Preview

User journeys

WS-01. Create or open a project

Path: Kontext OS → App Studio → project picker

You do:

  1. Open App Studio from the dock, module switcher, or /workspace route.
  2. Click the project dropdown in the window chrome (or Create project if the list is empty).
  3. Enter a name and confirm type (standard app vs template) when creating new.
  4. Wait for project metadata and canister bindings to load.
  5. Confirm the project name appears in the title bar before switching tabs.
  6. Note the project id in the URL ?project= param if you need a bookmarkable link.

Result: Project-scoped tabs (Chat, Context, Deploy, …) load against the correct canister data — not general chat.

WS-02. Confirm project context before tab work

Path: App Studio window chrome → active project indicator

You do:

  1. Glance at the chrome title and project dropdown — wrong project causes wrong deploys.
  2. If multiple OS windows are open, check which window has focus.
  3. Switch projects from the dropdown instead of opening a second App Studio blindly.
  4. After switching, wait for tab content to reload project-scoped data.
  5. Open Hosting briefly to verify canister IDs match your mental model of this app.
  6. Proceed to Chat, Deploy, or other tabs only after the active project is confirmed.

Result: Every tab action targets one project; avoids cross-project file saves and deploy mistakes.

WS-03. Navigate primary App Studio tabs

Path: App Studio → header App · Preview · Agents

You do:

  1. With a project selected, scan the header — App, Preview, Agents. Preview is the live preview (label Document or Media on those project kinds).
  2. Open App → Build kit for this project’s AI knowledge; App → Code for raw files; Agents for What chat sees / Connect tools only.
  3. Use App → Grow after builds for flywheel and Business convert — not during first prompt.
  4. Talk to the assistant in the composer beside Preview (desktop) or the Chat sheet (phone). There is no Chat tab.
  5. Notice General Chat in the left rail is the shared composer — it lands on Preview.
  6. Bookmark: write in the composer, validate in Preview, ship under App → Publish.

Result: You know which surface owns which job — generation, knowledge, code, project agents, growth.

WS-04. Use the App → Go live sections

Path: App Studio → App → Publish · Domains · Servers & fuel · Logs

You do:

  1. Open App (or press Publish beside the views).
  2. Start at Servers & fuel — credits, server pairs, canister IDs — before every deploy.
  3. Move to Publish for build logs and release actions.
  4. Open Logs after deploy when debugging runtime traps or HTTP failures.
  5. Configure Domains only after a successful deploy to a live frontend canister.
  6. Use deep links (?tab=deploy&project=…) when returning from Launchpad or OS shortcuts.

Result: Infrastructure and shipping stay in one ordered path — fund, deploy, diagnose, brand.

WS-05. Use the App → Data sections

Path: App Studio → App → Data · Files

You do:

  1. Open App — Data and Files are sections there, not header views.
  2. Open Data to browse schema and run read queries against live backend data.
  3. Open Files for secrets, uploads, and static assets — not for Motoko table rows.
  4. Add secrets in Files before referencing names in Build kit or agent profiles.
  5. Cross-check Chat answers against Data when data shape questions matter.
  6. Return to App → Publish if schema changes require a backend upgrade on chain.

Result: Data inspection and asset/secrets management stay separated and discoverable.

WS-06. Hand off from Launchpad to App Studio

Path: Launchpad generation complete → Open in App Studio

You do:

  1. Finish a Launchpad build or iteration session for a project.
  2. Click Open in App Studio, Continue in Chat, or the equivalent handoff CTA.
  3. Confirm navigation lands on /workspace with project and often tab=chat or tab=preview intent.
  4. Wait for Chat or Preview to consume the pending generation payload.
  5. Accept files in Chat if the handoff left pending applies.
  6. Follow the post-generation flywheel modal if it appears — or dismiss and use App → Grow later.

Result: Launchpad output becomes durable App Studio sources without re-describing the app.

WS-07. Open a project from My Kontext

Path: /os → My Kontext explorer → project icon shortcuts

You do:

  1. Open My Kontext or the OS project explorer from the shell.
  2. Locate your project card or row in the recent / all projects list.
  3. Click a shortcut icon — Chat, Preview, Deploy, etc. — if offered on the card.
  4. Confirm App Studio opens with the correct tab and project query params.
  5. If the wrong tab opens, use App Studio's own rail without re-picking the project.
  6. Pin frequently used projects in OS if your layout supports favorites.

Result: Faster entry from OS home into the exact App Studio surface you need.

WS-08. Share a project link or KRN

Path: App Studio or Share menu → copy link / KRN

You do:

  1. With the project open, open Share from the chrome or ecosystem surfaces if available.
  2. Copy the App Studio deep link with project id and optional tab param.
  3. Copy the project KRN when collaborating across Marketplace, University, or Network modules.
  4. Send the link to teammates who already have Kontext access — they still pick their own login.
  5. Avoid sharing secrets; links open project context, not Storage values.
  6. Verify recipients land on the same project name in their chrome after opening.

Result: Collaborators and modules reference one canonical project identity.

WS-09. Jump from App Studio to OS Intelligence

Path: App Studio chrome → OS / My Kontext → /os

You do:

  1. From App Studio, open the OS shell or module switcher — do not confuse with project Agents tab.
  2. Navigate to /os or My Kontext for Daily Brief, Employees, and Automations.
  3. Keep the same Kontext account — OS reads account-level state, not per-project Chat files.
  4. Delegate tasks to linked project agents from OS Chat when employees are configured.
  5. Return to App Studio via dock App Studio or recent project shortcut when coding again.
  6. Use OS for operations; use App Studio for app source and deploy.

Result: Clear boundary — OS Intelligence runs the business layer; App Studio builds the app.

WS-10. Jump from App Studio to Kontext Business

Path: App Studio → App → Grow → Convert to Business · or Business handoff chrome

You do:

  1. Ensure the app is deploy-ready and core flows work in Live Preview.
  2. Open App → Grow and start Convert to Business (or use Business chrome entry when shown).
  3. Complete the conversion wizard — solution name, blueprint, agent hooks.
  4. Land on /business and locate the new solution under Your solutions.
  5. Confirm CRM surfaces — leads, inbox, pipeline — reference the same project KRN.
  6. Continue code changes in App Studio; run campaigns and inbox in Business.

Result: One project powers both the custom app and the owner-operated Business cockpit.

WS-11. Jump from App Studio to Agents module

Path: App Studio → Agents tab → Agents module · or module switcher → /agents

You do:

  1. In App Studio, open Agents for awareness toggles — not for full agent authoring.
  2. Click Agents module to open /agents with project context when supported.
  3. Create or edit agents, automations, and Connected services in the recipe-first studio.
  4. Link to project on agents that should appear in App Studio What chat sees.
  5. Return to App Studio Agents tab and enable chat awareness for linked agents.
  6. Invoke them from Chat on this project.

Result: Build and registry in /agents; project-scoped enablement stays in App Studio.

WS-12. Return from a module to the same project tab

Path: External module → back to /workspace?project=&tab=

You do:

  1. Note your project id and tab before leaving App Studio — e.g. mid-deploy on Deploy.
  2. Complete work in Business, /agents, Marketplace, or Network via flywheel deep links.
  3. Use browser back, OS dock App Studio, or a bookmarked ?project=&tab= URL to return.
  4. Confirm the chrome project name matches before clicking Deploy or Accept in Chat.
  5. If session intent expired, re-select the project from the dropdown — tab intent TTL is short.
  6. Resume the interrupted task — deploy, Chat iteration, or DNS verify.

Result: Cross-module workflows do not strand you on the wrong project or tab.

WS-13. Follow the post-generation flywheel modal

Path: Chat generation complete → post-generation modal → App → Grow / next steps

You do:

  1. After a major generation, read the post-generation modal — preview, deploy, ecosystem CTAs.
  2. Choose Preview to validate UI before spending deploy credits.
  3. Or choose Deploy when preview already passed your checklist.
  4. Open App → Grow from the modal to see the full flywheel checklist.
  5. Dismiss only when you know your next step — modal is a map, not a blocker.
  6. Reopen the same checklist anytime from App → Grow.

Result: New builders get a guided path from files saved → preview → ship → distribute.

WS-14. Open App Manager instead of the full layout

Path: Kontext OS → compact App Studio publish window · project-scoped shortcut

You do:

  1. From OS app catalog, open the compact App Studio publish window for a lighter deploy/database/hosting shell.
  2. Select the same project you use in full App Studio when prompted.
  3. Use the compact window for quick hosting top-up, deploy, or database peek when Chat is not needed.
  4. Switch to full App Studio when you need Preview, Build kit, or the Grow flywheel.
  5. Keep project ids aligned — the compact window and full App Studio share one backend project record.
  6. Close the compact window when done; OS window state does not auto-deploy by itself.

Result: Power users get a compact ops surface; full App Studio remains the build + growth home.

WS-15. Switch projects with pending Chat work

Path: App Studio → project dropdown · pending apply banner

You do:

  1. Before changing projects, check Chat for pending file applies or unsent composer drafts.
  2. Accept or discard pending changes for the current project — they do not carry over.
  3. Switch project from the chrome dropdown; wait for tab content reload.
  4. Verify Hosting canister ids changed to the new project's infrastructure.
  5. Re-open Agents awareness toggles — they are per-project metadata.
  6. Avoid deploying until you re-confirm which project is active.

Result: Clean project switches without losing work silently or deploying to the wrong canisters.

WS-16. Stop a collaborator’s AI update

Path: App Studio → a project you own and shared → the banner

You do:

  1. Share the project and allow that editor to run AI.
  2. While they are running an update, read A collaborator is running an AI update on this project.
  3. Press Stop it.
  4. If several are running, the banner says how many.

Result: The update stops. Anything already saved stays in the project. The person you shared with does not see this button. You also get a notice when their update starts, finishes, or does not finish.

WT-01. Generate a greenfield app from Chat

Path: App Studio → App tab (sidebar composer or General Chat) → new or selected project

You do:

  1. Open App Studio and select the target project (or create one from the picker).
  2. Use the App sidebar composer (or General Chat) and describe the app in plain language — audience, core screens, and data it should store. There is no Chat tab.
  3. Answer any follow-up questions the assistant asks about auth, styling, or integrations.
  4. Wait for generation to finish; watch the progress panel for spec and file phases.
  5. When files appear in the side pane, skim the file list for expected routes and backend modules.
  6. Confirm the project title in the chrome matches the app you asked for before leaving Chat.

Result: New app files persist to the project; Context, Deploy, and Live Preview read the same files next visit. This is greenfield (a new app). A precision update edits an existing project. Launchpad is phased work you approve — not this Chat generate. A default deploy can wipe the app database; ask for an upgrade to keep data.

WT-02. Iterate on an existing app in Chat

Path: App Studio → App sidebar composer → follow-up prompt

You do:

  1. Select the project that already has saved files.
  2. In the App sidebar (or phone Chat sheet), describe the change — e.g. add a screen, fix copy, extend the backend API.
  3. Reference specific files or UI areas if you know them; otherwise let the assistant locate targets.
  4. Review the assistant's plan or diff summary before accepting large structural changes.
  5. Send clarifying follow-ups until the side pane shows the files you expect.
  6. Save or accept pending changes when the iteration matches your intent.

Result: Incremental edits land in project storage without a full regen; Deploy and Preview reflect accepted files.

WT-03. Review generated files in the side pane

Path: App Studio → App tab → file side pane beside the composer

You do:

  1. During or after generation, open the file side pane beside the composer.
  2. Expand folders and open key files — entry component, main page, backend main.mo or API layer.
  3. Compare filenames and paths against what you asked for in the prompt.
  4. Flag missing routes or assets in a follow-up Chat message instead of editing blindly elsewhere.
  5. Use preview links or Code tab if you need a read-only view outside the pane.
  6. Note any files marked pending until you accept them in the next step.

Result: You validate structure before accept/save; fewer surprise deploy failures from unchecked output.

WT-04. Accept and persist file changes from Chat

Path: App Studio → Chat tab → accept / apply files

You do:

  1. When generation or an update completes, review pending changes in the side pane or apply banner.
  2. Open diffs for critical files — auth, payments, schema — before accepting all.
  3. Click Accept, Apply, or equivalent to write files to the project canister.
  4. Wait for the save confirmation toast or status line in Chat.
  5. Switch to Code or Live Preview briefly to confirm files loaded without stale cache.
  6. Return to Chat only if something still looks wrong; avoid double-applying the same batch.

Result: Accepted files are durable project sources; Context rules and Deploy see the latest version.

WT-05. Add code rules in Context

Path: App Studio → App → Build kit → Code rules

You do:

  1. Open the project and go to App → Build kit (project AI knowledge — not OS AME on /os).
  2. Select Code rules (or the rules section in the Context layout).
  3. Add conventions — naming, folder layout, forbidden patterns, preferred libraries.
  4. Paste or write short, testable rules the model can follow on the next turn.
  5. Save Context; confirm the timestamp or saved indicator updates.
  6. Send a small Chat prompt to verify the assistant cites or follows a new rule.

Result: Project-scoped rules steer Chat and generation without polluting global OS memory.

WT-06. Document environment notes in Context

Path: App Studio → App → Build kit → environment / env notes

You do:

  1. Open App → Build kit for the active project.
  2. Open the environment or Env notes section (non-secret configuration only).
  3. Document public URLs, feature flags, staging vs production behavior, and third-party sandbox modes.
  4. Cross-reference secret names here if needed — store actual values in Storage, not Context prose.
  5. Save Context after edits.
  6. In Chat, ask the assistant to respect an env note you just added and confirm it does.

Result: The AI understands deployment context; secrets stay in Storage where Deploy resolves them.

WT-07. Add documentation items for AI reference

Path: App Studio → App → Build kit → documentation items

You do:

  1. Open App → Build kit and navigate to Documentation items (or linked docs / reference files).
  2. Add items the assistant should read — API notes, product briefs, support macros, PDF summaries.
  3. Set titles and tags so Chat can pick the right item when you @-mention or ask by name.
  4. Upload or link content per the in-product controls; avoid duplicating huge blobs in Chat.
  5. Save Context and note which items are included in chat context vs archive-only.
  6. Test with a Chat question that should pull from one documentation item.

Result: Long-lived reference material feeds project AI turns without re-pasting every session.

WT-08. Configure design palettes in Context

Path: App Studio → App → Build kit → design / color palettes

You do:

  1. Open App → Build kit and find Design palettes, color tokens, or styling references.
  2. Enter brand primary/secondary colors, typography hints, and spacing preferences.
  3. Attach inspiration links or palette screenshots if the UI supports design references.
  4. Align palette names with tokens you expect in generated CSS or Tailwind config.
  5. Save Context.
  6. Run a small Chat change (e.g. restyle a header) and confirm colors match the palette.

Result: Visual consistency across Chat iterations; Refine and generation share the same design signals.

WT-09. Edit template Config (form and JSON)

Path: App Studio → Config tab (template / WASM projects)

You do:

  1. Open a template or WASM-scaffold project where Config appears in the tab rail.
  2. Go to Config — not available on all standard React projects.
  3. Use the form editor for high-level template fields (labels, defaults, feature toggles).
  4. Switch to the JSON view for advanced keys; validate syntax before saving.
  5. Save Config and note any reload prompt for Live Preview.
  6. Open Live Preview to confirm template-driven UI reflects Config changes.
  7. If Deploy is required for backend template hooks, queue Deploy after Config save.

Result: Template metadata updates without hand-editing generated scaffold files in Code.

WT-10. Browse Database tables

Path: App Studio → App → Data

You do:

  1. Select a deployed project with a Motoko or platform database backend.
  2. Open the Data group and choose Database.
  3. Wait for schema load — tables and columns list from the live canister or dev binding.
  4. Click a table to inspect rows; use pagination if the table is large.
  5. Note primary keys and relationships before writing ad-hoc queries.
  6. Copy sample row values only if they are non-sensitive test data.

Result: You understand live data shape before queries, Chat schema questions, or Business retrofits.

WT-11. Run ad-hoc Database queries

Path: App Studio → Database tab → query runner

You do:

  1. Open Database for the project with a connected backend.
  2. Select the query or SQL/Motoko runner panel (per project type).
  3. Write a read-only query first — SELECT-style or Motoko query method — to limit risk.
  4. Execute and review results in the grid; check row counts and nulls.
  5. Adjust filters or joins; re-run until the answer matches your question.
  6. Export or copy results if the UI offers it for support tickets or Chat context.
  7. Avoid destructive writes unless you intend a data migration and have a backup plan.

Result: Direct data answers without a full redeploy; findings can inform Chat or Business field mapping.

WT-12. Store secrets in Storage

Path: App Studio → App → Files → secrets

You do:

  1. Open Storage for the project.
  2. Navigate to Secrets or env key storage (not public asset buckets).
  3. Add a secret name and value — API keys, webhook signing secrets, OAuth client secrets.
  4. Mark scope per product guidance (deploy-only vs agent-resolvable).
  5. Save and confirm the secret appears in the list without exposing the value in Code.
  6. Reference the secret name from Config, Context env notes, or agent profiles — never paste the raw value in Chat.

Result: Deploy and linked agents resolve secrets at runtime; repo files stay free of credentials.

WT-13. Upload project assets to Storage

Path: App Studio → Storage tab → uploads / assets

You do:

  1. Open Storage and choose the uploads or assets area for the project.
  2. Upload images, fonts, PDFs, or static files the app or agents should serve.
  3. Wait for upload completion and copy the asset URL or storage key if shown.
  4. Reference the asset from Chat ("use logo from Storage") or from code paths the assistant maintains.
  5. Verify file size and MIME type meet hosting limits.
  6. Open Live Preview or deployed URL to confirm the asset renders.

Result: Static files live in project storage; Chat and Deploy can bind them without external hosting.

WT-14. Review Hosting credits and balance

Path: App Studio → App → Servers & fuel

You do:

  1. Open Hosting under the Publish group for the active project.
  2. Read current credits balance and recent debit lines (deploy, agent server, cycles top-up).
  3. Note whether the project uses a shared Main Agent pair or dedicated infrastructure.
  4. If balance is low, follow the in-product link to Gas Station or account billing to add credits.
  5. Confirm hosting status shows healthy — not frozen or pending provisioning.
  6. Keep this tab open when planning Deploy so you know charges will succeed.

Result: Deploy and agent operations won't fail mid-flight for insufficient hosting credits.

WT-15. Inspect server pairs and canister IDs

Path: App Studio → Hosting tab → infrastructure details

You do:

  1. Open Hosting for the project.
  2. Locate server pairs — Main Agent runtime, app server, or workflow host assignments.
  3. Expand frontend and backend canister IDs assigned to this project.
  4. Copy IDs to a support ticket or runbook if debugging with the team.
  5. Check cycle or health indicators per pair when shown.
  6. Do not swap canister IDs manually unless documentation explicitly guides a recovery flow.

Result: You know which on-chain identities serve this app — essential for DNS, support, and Business handoffs.

WT-16. Run a deploy and read the build log

Path: App Studio → App → Publish

You do:

  1. Confirm Hosting has credits and canister IDs provisioned.
  2. Open Deploy and review pre-deploy summary — changed files, target environment.
  3. Click Deploy (or Build & deploy) and watch the build log stream.
  4. Note compile steps for frontend bundle and backend Motoko (or template) phases.
  5. Wait for success confirmation and recorded canister upgrade hashes if shown.
  6. On success, open Live Preview or the live URL to spot-check the build.
  7. Copy deploy timestamp from the log for your release notes.

Result: Production canisters match accepted project files; log is your audit trail for what shipped.

WT-17. Recover from a failed deploy

Path: App Studio → Deploy tab → failed build log

You do:

  1. After a failed deploy, stay on Deploy and scroll the build log to the first error line.
  2. Read the structured error summary — missing import, Motoko type error, bundler failure, cycles.
  3. Use Copy fix message or equivalent to paste context into Chat if offered.
  4. Apply fixes via Chat; accept files; optionally validate in Live Preview first.
  5. Return to Deploy and retry — do not spam deploy if Hosting credits are exhausted.
  6. If errors mention infrastructure, check Hosting and Gas Station before a third attempt.
  7. Escalate with log excerpt and canister IDs if the same error repeats unchanged.

Result: Failures become actionable fixes instead of blind retries; fewer broken production states.

WT-18. Read canister logs after deploy

Path: App Studio → App → Logs (canisterLogs)

You do:

  1. Open Logs (canister logs) under Publish after a deploy or when debugging runtime errors.
  2. Select frontend or backend canister if the UI splits streams.
  3. Filter or scroll to the time window matching your repro steps.
  4. Look for trap messages, HTTP 500 equivalents, or actor call failures.
  5. Copy relevant log lines into Chat or a support ticket with the deploy timestamp from Deploy.
  6. Cross-check Live Preview — client-only bugs may not appear in canister logs.

Result: Runtime evidence complements build logs; faster diagnosis of post-deploy bugs.

WT-19. Validate UI in Live Preview

Path: App Studio → App tab

You do:

  1. Open App (live preview) for the active project. On a Docs or Media project the label is Document or Media.
  2. Wait for the embedded preview to compile and mount — note any compile overlay errors.
  3. Click through primary user flows: sign-in, create/read data, navigation, forms.
  4. Resize or toggle device frames if mobile layout matters for your app.
  5. Compare preview behavior to what you described in Chat; log gaps as follow-up prompts.
  6. Do not treat preview as production DNS — it validates UI and client logic pre-deploy.

Result: Lower-risk releases — many compile and UX issues caught before Deploy.

WT-20. Close the Preview → Chat fix loop

Path: App preview → composer → back to preview

You do:

  1. Reproduce an issue in App (live preview) — layout break, wrong data, missing route.
  2. Note the screen name and action that failed; screenshot mentally or copy error text.
  3. Use the App sidebar composer (or phone Chat sheet) and describe the bug with repro steps; reference preview, not production URL.
  4. Accept fixed files from the assistant; wait for save confirmation.
  5. Return to App preview — hard refresh if the embed caches aggressively.
  6. Re-run the same flow until preview passes your checklist.
  7. Proceed to Deploy only when preview matches acceptance criteria.

Result: Tight iteration loop without editing raw files unless you choose Code tab.

WT-21. Configure Mobile / EAS build panel

Path: Live Preview or Deploy → App Store & Play — EAS panel

You do:

  1. Open Live Preview, Deploy, or follow a Launchpad handoff to the EAS / mobile panel.
  2. Confirm the project includes a mobile/ tree or React Native scaffold from generation.
  3. Enter or upload Expo / EAS credentials, app identifiers, and store listing assets per checklist.
  4. Set build profile (development vs production) and trigger a cloud build if ready.
  5. Monitor build status and download artifacts when complete.
  6. Follow App Store Connect and Google Play submission steps linked in-product.
  7. Keep secrets in Storage, not in committed mobile config files.

Result: Mobile shipping stays in one App Studio surface instead of scattered CLI notes.

WT-22. Set your Kontext address or add a custom domain

Path: App Studio → App → Domains

You do:

  1. Deploy once with Hosting so the app can claim a free address like your-app.kontext.network.
  2. Open Domains. The top card is Your Kontext address — included with the app. People visit this unless you connect your own domain below.
  3. To rename it, press Change this address, type the New address, and Save address. The old address stops working so someone else can use it. HTTPS on the new one can take a minute.
  4. If you are a collaborator (not the owner), Change this address stays off — the owner changes it.
  5. A purchased or existing domain is optional. Use New Domain, Existing Domain, or Manage below the Kontext card.
  6. Hub → Money → Your domains lists free *.kontext.network names (labeled free) and purchased ones. Rename happens on Domains, not on Hub.
  7. *.icp0.io is the canister URL, not the Kontext address. Use it only as a fallback while a custom name is still connecting.

Result: Visitors use your-app.kontext.network (or your own domain if you connected one). Hosting canister IDs stay the same.

WT-23. Toggle chat-aware agents (Agents tab)

Path: App Studio → Agents tab → What chat sees

You do:

  1. Open the project and go to Agents — the project powers hub, not full /agents studio.
  2. Stay on What chat sees (chat awareness).
  3. Review linked agents and automations eligible for this project.
  4. Toggle chat awareness on for agents App Studio chat may invoke; leave off what you want dormant.
  5. Save selection — persisted as project metadata for the next Chat session.
  6. Open Chat and ask a task that should use an enabled agent; confirm routing in the trace if shown.

Result: Chat uses only agents you explicitly enabled for this project — awareness without rebuilding agents here.

WT-24. Connect tools from Agents tab

Path: App Studio → Agents tab → Connect tools

You do:

  1. Enable at least one agent under What chat sees — Connect tools stays locked otherwise.
  2. Switch to Connect tools.
  3. Open Connected services for agent-scoped OAuth — Gmail, Notion, Slack, etc.
  4. Complete OAuth for apps the enabled agents need; prefer least-privilege scopes.
  5. Enable KESA (Kontext Ecosystem) before external apps when the task can stay in-platform.
  6. Return to Chat and run a task that requires the service you connected.

Result: Project-scoped tool wiring for chat-aware agents; full agent create/edit remains in /agents.

WT-25. Open full Agents module from App Studio

Path: App Studio → Agents tab → Agents module CTA

You do:

  1. From Agents tab, click Agents module (external link) in the header.
  2. Land on /agents with project context preserved where supported.
  3. Create, edit, or deploy agents and automations in the recipe-first studio.
  4. Use Link to project on an agent card to attach it back to this App Studio project.
  5. Return to App Studio → Agents → What chat sees to enable chat awareness.
  6. Test from Chat — build in /agents, operate awareness in App Studio.

Result: Clear split — registry and deploy in /agents; project powers and chat toggles in App Studio.

WT-26. Advance the Grow flywheel checklist

Path: App Studio → App → Grow → growth flywheel

You do:

  1. Open App → Grow after a successful build or deploy (or from the post-generation modal).
  2. Review the Growth flywheel checklist — Network post, Community, Marketplace, University, Business, Creator video, etc.
  3. Pick the next incomplete step aligned with your go-to-market plan.
  4. Click the step CTA — deep links open the target module with project KRN context prefilled.
  5. Complete the action in the target module (e.g. draft Marketplace listing, publish Network post).
  6. Return to App → Grow and confirm the step marks complete and progress advances.
  7. Note any KTX or rewards messaging when steps complete.

Result: One checklist ties the project to distribution modules instead of hunting links manually.

WT-27. Convert project to Business from Grow

Path: App Studio → App → Grow → Convert to Business

You do:

  1. Open App → Grow when the app is deploy-ready and data model is stable enough for CRM use.
  2. Find Convert to Business (or Business flywheel step) on the checklist.
  3. Start the wizard — confirm project KRN, solution name, and owner account.
  4. Review blueprint preview — forms, pipeline, and agent hooks Business will inherit.
  5. Complete conversion and follow the handoff link to /business.
  6. Verify the solution appears under Your solutions with linked App Studio project.
  7. Keep iterating app code in App Studio; operate leads and inbox in Business.

Result: Same underlying project becomes a Business solution without rebuilding from scratch.

How it works

Route /workspace. Project-scoped App Studio. Views App · Preview · Agents; App sections Overview, Code, Publish, Domains, Servers & fuel, Logs, Connections, Build kit, Data, Files, Grow; the composer sits beside Preview. Project files and credits on the user canister; compile/bundle via platform tooling; deploy to IC server pairs.

Benefits

Who it's for

Primary: builders generating and iterating apps. Also: owners editing solutions from Business or Launchpad. Not: non-technical owners who only want CRM/inbox (use Kontext Business).