Kontext Encyclopedia

Workspace Chat

/workspace · version 3.13 · 2026-10-06

Capabilities

Workspace (/workspace) is where you build and change an app. Header: App · Agents · Context · Ecosystem · Code. Platform holds Publish and Data. There is no Chat tab — the assistant lives on App. 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 Workspace?

Workspace (/workspace) is where you build and change an app. The switcher says Workspace 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

Primary row, in this order: App · Agents · Context · Ecosystem · Code. There is no Chat tab, no Publish tab, and no Data tab in the header.

Platform menu

The button is named Platform (not Publish). General Chat in the left rail still lands on App. On a phone, a Chat icon opens a sheet — same lane, not a sixth header tab.

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 ten-step path you approve, 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.

Workspace Agents vs /agents

Workspace 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 Hosting and a deploy, each app gets a free address like your-app.kontext.network. Open Platform → Publish → 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

Workspace is where project work happens — App (preview + composer), Agents, Context, Ecosystem, Code, then Platform (Publish and Data). All WS- and WT- journeys below cover opening the right project, every leaf, and returning without losing context.

The Workspace 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.

Workspace Ecosystem tab

Entry: Workspace → select project → Ecosystem tab · Also: post-generation modal after AI build

The Ecosystem tab 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
Featured Project KRNs Gallery of linked resource identities
Convert to Business One-click retrofit generated app → Business solution
Labs shortcuts Stripe Lab, Funnel Lab, Make videos (Kontext Media) cards
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 OS window Live site, database, hosting, deploy without full Workspace
Project Management /pm (team) 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=... 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 → Workspace → project picker

You do:

  1. Open Workspace 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: Workspace 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 Workspace 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 workspace tabs

Path: Workspace → header App · Agents · Context · Ecosystem · Code

You do:

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

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

WS-04. Use the Platform → Publish group

Path: Workspace → Platform → Publish → Hosting · Deploy · Logs · Domains

You do:

  1. Open the Platform button (not a Publish tab in the header). Choose Publish.
  2. Start at Hosting — credits, server pairs, canister IDs — before every deploy.
  3. Move to Deploy 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 Platform → Data group

Path: Workspace → Platform → Data → Database · Storage

You do:

  1. Open Platform and choose Data — there is no Data tab in the header.
  2. Open Database to browse schema and run read queries against live backend data.
  3. Open Storage for secrets, uploads, and static assets — not for Motoko table rows.
  4. Add secrets in Storage before referencing names in Context or agent profiles.
  5. Cross-check Chat answers against Database when data shape questions matter.
  6. Return to Platform → Deploy 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 Workspace

Path: Launchpad generation complete → Open in Workspace

You do:

  1. Finish a Launchpad build or iteration session for a project.
  2. Click Open in Workspace, 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 Ecosystem later.

Result: Launchpad output becomes durable Workspace 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 Workspace opens with the correct tab and project query params.
  5. If the wrong tab opens, use the in-Workspace 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 Workspace surface you need.

WS-08. Share a project link or KRN

Path: Workspace 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 workspace 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 Workspace to OS Intelligence

Path: Workspace chrome → OS / My Kontext → /os

You do:

  1. From Workspace, 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 Workspace via dock Workspace or recent project shortcut when coding again.
  6. Use OS for operations; use Workspace for app source and deploy.

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

WS-10. Jump from Workspace to Kontext Business

Path: Workspace → Ecosystem → 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 Ecosystem 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 Workspace; run campaigns and inbox in Business.

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

WS-11. Jump from Workspace to Agents module

Path: Workspace → Agents tab → Agents module · or module switcher → /agents

You do:

  1. In Workspace, 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 Workspace What chat sees.
  5. Return to Workspace 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 Workspace.

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 Workspace — 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 Workspace, 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 → Ecosystem / 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 Ecosystem 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 Ecosystem tab.

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

WS-14. Open App Studio without full Workspace layout

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

You do:

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

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

WS-15. Switch projects with pending Chat work

Path: Workspace → 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: Workspace → 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: Workspace → App tab (sidebar composer or General Chat) → new or selected project

You do:

  1. Open Workspace 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: Workspace → 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: Workspace → 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: Workspace → 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: Workspace → Context tab → Code rules

You do:

  1. Open the project and go to Context (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: Workspace → Context tab → environment / env notes

You do:

  1. Open Context 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: Workspace → Context tab → documentation items

You do:

  1. Open Context 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: Workspace → Context tab → design / color palettes

You do:

  1. Open Context 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: Workspace → 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: Workspace → Platform → Data → Database tab

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: Workspace → 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: Workspace → Platform → Data → Storage tab → 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: Workspace → 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: Workspace → Platform → Publish → Hosting tab

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: Workspace → 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: Workspace → Platform → Publish → Deploy tab

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: Workspace → 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: Workspace → Platform → Publish → Logs tab (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: Workspace → 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 Workspace surface instead of scattered CLI notes.

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

Path: Workspace → Platform → Publish → 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: Workspace → 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 Workspace 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: Workspace → 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 Workspace

Path: Workspace → 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 Workspace project.
  5. Return to Workspace → Agents → What chat sees to enable chat awareness.
  6. Test from Chat — build in /agents, operate awareness in Workspace.

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

WT-26. Advance the Ecosystem flywheel checklist

Path: Workspace → Ecosystem tab → growth flywheel

You do:

  1. Open Ecosystem 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 Ecosystem 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 Ecosystem

Path: Workspace → Ecosystem tab → Convert to Business

You do:

  1. Open Ecosystem 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 Workspace project.
  7. Keep iterating app code in Workspace; 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 Workspace: Chat (generation/precision via Zoe Assistant), Files, Context, Database, Hosting/Deploy, Live Preview, Ecosystem tab. 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).