eclipse-che · gtrivedi88 · Aug 24, 2026 · Sep 17, 2026 · svor · Sep 23, 2026
@@ -9,6 +9,7 @@ nav:
   - modules/install/nav.adoc
   - modules/get-started-admin/nav.adoc
   - modules/get-started-user/nav.adoc
+  - modules/develop/nav.adoc
   - modules/troubleshoot/nav.adoc
   - modules/end-user-guide/nav.adoc
   - modules/upgrade/nav.adoc

@@ -30,8 +30,8 @@ data:
   OPENAI_API_KEY: __<base64-encoded-api-key>__           <6>
 ----
 <1> Secret name is derived as `ai-provider-` + `envVarName.toLowerCase().replace(/_/g, '-')`. For `OPENAI_API_KEY` the name is `ai-provider-openai-api-key`.
-<2> Instructs the DevWorkspace Controller to mount this Secret into all `DevWorkspace` containers in the namespace.
-<3> Instructs the DevWorkspace Controller to watch for Secret changes and re-mount without a workspace restart.
+<2> Instructs the {devworkspace} Controller to mount this Secret into all `DevWorkspace` containers in the namespace.
+<3> Instructs the {devworkspace} Controller to watch for Secret changes and re-mount without a workspace restart.
 <4> Sanitized provider ID (characters other than letters, digits, dots, underscores, and dashes are replaced with dashes). Identifies which AI provider this Secret belongs to. Used by the {prod-short} dashboard to detect existing keys.
 <5> Mounts the Secret data keys as environment variables (not as files).
 <6> The data key is the environment variable name. The value is base64-encoded. The variable is injected directly into all workspace containers.
@@ -44,11 +44,11 @@ data:
 
 | `controller.devfile.io/mount-to-devworkspace`
 | `'true'`
-| Causes the DevWorkspace Controller to mount this Secret into every `DevWorkspace` in the namespace.
+| Causes the {devworkspace} Controller to mount this Secret into every `DevWorkspace` in the namespace.
 
 | `controller.devfile.io/watch-secret`
 | `'true'`
-| The DevWorkspace Controller re-mounts the Secret when its data changes, without requiring a workspace restart.
+| The {devworkspace} Controller re-mounts the Secret when its data changes, without requiring a workspace restart.
 
 | `controller.devfile.io/mount-as`
 | `env`
@@ -104,5 +104,5 @@ EOF
 .Additional resources
 
 * xref:configuring-ai-providers.adoc[]
-* xref:end-user-guide:mounting-secrets.adoc[Mounting secrets (end-user guide)]
+* xref:develop:mounting-secrets.adoc[Mounting secrets (end-user guide)]
 * link:https://devfile.io/docs/2.2.0/what-is-a-devfile[Devfile documentation]
@@ -9,7 +9,7 @@
 
 Learn how to use {prod-short}
 to synchronize `ConfigMaps`, `Secrets`, `PersistentVolumeClaim` and other {kubernetes} objects
-from `{prod-namespace}` namespace to numerous user-specific namespaces.
+from `{prod-namespace}` {namespace} to numerous user-specific namespaces.
 The {prod-short} automates the synchronization of important configuration data, such as
 shared credentials, configuration files, and certificates to user namespaces.
 
@@ -183,7 +183,7 @@ and `controller.devfile.io/mount-to-devworkspace-exclude` are set, the resource
 mounted only to workspaces that match the include pattern and do not match the exclude pattern.
 +
 For other labels and annotations, see link:https://github.com/devfile/devworkspace-operator/blob/main/docs/additional-configuration.adoc#automatically-mounting-volumes-configmaps-and-secrets[Mounting volumes, configmaps, and secrets].
-. To leverage the OpenShift Kubernetes Engine, you can create a `Template` object to replicate all resources defined within the template across each user {orch-namespace}.
+. To use the OpenShift {kubernetes} Engine, you can create a `Template` object to replicate all resources defined within the template across each user {orch-namespace}.
 +
 Aside from the previously mentioned `ConfigMap`, `Secret`, and `PersistentVolumeClaim`, `Template` objects can include:
 +
@@ -261,13 +261,13 @@ objects:
 parameters:
 - name: PROJECT_ADMIN_USER
 ----
-NOTE: Creating Template Kubernetes resources is supported only on OpenShift.
+NOTE: Creating Template {kubernetes} resources is supported only on OpenShift.
 ====
 
 .Additional resources
-* xref:end-user-guide:mounting-configmaps.adoc[]
-* xref:end-user-guide:mounting-secrets.adoc[]
-* xref:end-user-guide:requesting-persistent-storage-for-workspaces.adoc[]
+* xref:develop:mounting-configmaps.adoc[]
+* xref:develop:mounting-secrets.adoc[]
+* xref:develop:requesting-persistent-storage-for-workspaces.adoc[]
 * link:https://github.com/devfile/devworkspace-operator/blob/main/docs/additional-configuration.adoc#automatically-mounting-volumes-configmaps-and-secrets[Automatically mounting volumes, configmaps, and secrets]
 * link:https://docs.openshift.com/container-platform/latest/rest_api/template_apis/template-template-openshift-io-v1.html[OpenShift API reference for `Template`]
 * link:https://docs.openshift.com/container-platform/latest/applications/projects/configuring-project-creation.html[Configuring OpenShift project creation]
@@ -162,4 +162,4 @@ When you update the registry (for example, to remove a tool or change the inject
 .Additional resources
 
 * xref:ai-provider-api-key-secret-reference.adoc[]
-* xref:end-user-guide:using-ai-assistants-in-workspaces.adoc[]
+* xref:develop:using-ai-assistants-in-workspaces.adoc[]
@@ -18,4 +18,4 @@ This is not necessary for OpenShift versions 4.15 and later, since the `/dev/fus
 After enabling `/dev/fuse` access, fuse-overlayfs can be enabled in two ways:
 
 . For all user workspaces within the cluster. See xref:administration-guide:enabling-fuse-for-all-workspaces.adoc[]. 
-. For workspaces belonging to certain users. See xref:end-user-guide:using-the-fuse-overlay-storage-driver.adoc[].
+. For workspaces belonging to certain users. See xref:develop:using-the-fuse-overlay-storage-driver.adoc[].
@@ -7,7 +7,7 @@
 [id="configuring-the-storage-strategy"]
 = Configuring the storage strategy
 
-{prod-short} can be configured to provide persistent or non-persistent storage to workspaces by selecting a storage strategy. The selected storage strategy will be applied to all newly created workspaces by default. Users can opt for a non-default storage strategy for their workspace in their xref:end-user-guide:requesting-persistent-storage-for-workspaces.adoc[devfile] or through the xref:end-user-guide:url-parameter-for-the-workspace-storage.adoc[URL parameter].
+{prod-short} can be configured to provide persistent or non-persistent storage to workspaces by selecting a storage strategy. The selected storage strategy will be applied to all newly created workspaces by default. Users can opt for a non-default storage strategy for their workspace in their xref:develop:requesting-persistent-storage-for-workspaces.adoc[devfile] or through the xref:develop:url-parameter-for-the-workspace-storage.adoc[URL parameter].
 
 Available storage strategies:
 

@@ -14,7 +14,7 @@ integrated registry or link:https://quay.io[Quay.io], to store backup archives a
 
 The backup makes a snapshot of *stopped* Workspace PVCs and stores them as tar.gz archives in the specified OCI registry.
 
-Users can restore backups from the {prod-short} dashboard. See xref:end-user-guide:restoring-workspaces-from-backups.adoc[].
+Users can restore backups from the {prod-short} dashboard. See xref:develop:restoring-workspaces-from-backups.adoc[].
 
 NOTE: By default, the {devworkspace} backup job is disabled.
 
@@ -29,7 +29,7 @@ The value for `registry.path` is the first segment of the final location. The fu
 +
 `<registry.path>/<namespace>/<devworkspace-name>:latest`
 
-* `registry.authSecret`: (Optional) The name of the Kubernetes secret that contains credentials for the OCI registry. If you do not provide a secret, the system assumes the registry is public or uses the **Red Hat OpenShift** integrated registry.
+* `registry.authSecret`: (Optional) The name of the {kubernetes} secret that contains credentials for the OCI registry. If you do not provide a secret, the system assumes the registry is public or uses the **Red Hat OpenShift** integrated registry.
 * `oras.extraArgs`: (Optional) Additional arguments for to the `oras` CLI tool during push and pull operations.
 
 

@@ -139,4 +139,4 @@ sh-4.4# stat /host/etc/crio/crio.conf.d/99-podman-fuse
 ----
 
 == Using fuse-overlayfs for Podman and Buildah within a workspace
-Users can follow xref:end-user-guide:using-the-fuse-overlay-storage-driver.adoc[] to update existing workspaces to use the fuse-overlayfs storage driver for Podman and Buildah.
+Users can follow xref:develop:using-the-fuse-overlay-storage-driver.adoc[] to update existing workspaces to use the fuse-overlayfs storage driver for Podman and Buildah.
@@ -0,0 +1,52 @@
+.Develop
+* xref:using-credentials-and-configurations-in-workspaces.adoc[]
+** xref:mounting-secrets.adoc[]
+*** xref:creating-image-pull-secrets.adoc[]
+** xref:mounting-configmaps.adoc[]
+*** xref:mounting-git-configuration.adoc[]
+*** xref:mounting-ssh-configuration.adoc[]
+* xref:using-the-fuse-overlay-storage-driver.adoc[]
+** xref:accessing-fuse.adoc[]
+** xref:enabling-overlay-with-a-configmap.adoc[]
+** xref:running-containers-with-kubedock.adoc[]
+* xref:using-che-in-team-workflow.adoc[]
+** xref:first-time-contributors.adoc[]
+** xref:benefits-of-pull-requests-review-in-che.adoc[]
+** xref:try-in-web-ide-github-action.adoc[]
+* xref:requesting-persistent-storage-for-workspaces.adoc[]
+** xref:restoring-workspaces-from-backups.adoc[]
+*** xref:proc-viewing-backups-in-the-dashboard.adoc[]
+*** xref:proc-restoring-a-workspace-from-backup.adoc[]
+* xref:proc_preventing-workspace-idling-for-long-running-commands.adoc[]
+* xref:starting-a-workspace-from-a-raw-devfile-url.adoc[]
+* xref:optional-parameters-for-the-urls-for-starting-a-new-workspace.adoc[]
+** xref:url-parameter-concatenation.adoc[]
+** xref:url-parameter-for-the-ide.adoc[]
+** xref:url-parameter-for-the-ide-image.adoc[]
+** xref:url-parameter-for-starting-duplicate-workspaces.adoc[]
+** xref:url-parameter-for-the-existing-workspace-name.adoc[]
+** xref:url-parameter-for-the-devfile-file-name.adoc[]
+** xref:url-parameter-for-the-devfile-file-path.adoc[]
+** xref:url-parameter-for-the-workspace-storage.adoc[]
+** xref:url-parameter-for-additional-remotes.adoc[]
+** xref:url-parameter-for-container-image.adoc[]
+** xref:url-parameter-for-memory-limit.adoc[]
+** xref:url-parameter-for-cpu-limit.adoc[]
+** xref:url-parameter-for-the-ai-provider.adoc[]
+* Set up your development tools
+** xref:customizing-workspace-components.adoc[]
+*** xref:devfile-introduction.adoc[]
+** xref:ides-in-workspaces.adoc[]
+*** xref:microsoft-visual-studio-code-open-source-ide.adoc[]
+**** xref:using-github-copilot-chat.adoc[]
+*** xref:connect-visual-studio-code-to-che-workspace.adoc[]
+*** xref:defining-a-common-ide.adoc[]
+** xref:using-ai-assistants-in-workspaces.adoc[]
+*** xref:configuring-an-ai-provider-api-key.adoc[]
+*** xref:changing-the-ai-tool-on-a-workspace.adoc[]
+*** xref:persist-claude-code-configuration.adoc[]
+**** xref:share-claude-code-configuration-with-pvc-direct-mount.adoc[]
+**** xref:share-claude-code-configuration-with-pvc-tmp-copy.adoc[]
+**** xref:share-claude-code-configuration-with-gitops.adoc[]
+**** xref:troubleshoot-claude-code-configuration-persistence.adoc[]
+*** xref:distribute-claude-code-skills-with-lola.adoc[]
@@ -1,7 +1,7 @@
 :_content-type: PROCEDURE
 :description: {prod} workspace contains all tools you need to review pull and merge requests from start to finish.
 :keywords: user-guide, reviewing, pull request, merge request
-:navtitle: Reviewing pull and merge requests
+:navtitle: Benefits of reviewing pull and merge requests in {prod}
 :page-aliases:
 
 [id="title"]

@@ -1,7 +1,7 @@
 :_content-type: PROCEDURE
 :description: Switch or remove the AI coding assistant on a stopped workspace without recreating it, and optionally choose a specific version.
 :keywords: user-guide, ai, ai tool, ai provider, workspace, change, update, version
-:navtitle: Changing the AI tool on a workspace
+:navtitle: Change the AI tool on a workspace
 :page-aliases:
 
 [id="changing-the-ai-tool-on-a-workspace"]

@@ -1,7 +1,7 @@
 :_content-type: PROCEDURE
 :description: Store your AI provider API key so that it is automatically available as an environment variable in all your workspaces.
 :keywords: user-guide, ai, api key, ai provider, environment variable, secret
-:navtitle: Configuring an AI provider API key
+:navtitle: Configure an AI provider API key
 :page-aliases:
 
 [id="configuring-an-ai-provider-api-key"]

@@ -1,3 +1,4 @@
+:page-aliases: end-user-guide:connect-visual-studio-code-to-che-workspace.adoc
 [id="connect-visual-studio-code-to-che-workspace"]
 
 = Connecting Visual Studio Code to a {prod-short} workspace

@@ -10,7 +10,7 @@
 
 To customize workspace components:
 
-* xref:starting-a-workspace-from-a-git-repository-url.adoc[Choose a Git repository for your workspace].
+* xref:get-started-user:starting-a-workspace-from-a-git-repository-url.adoc[Choose a Git repository for your workspace].
 
 * xref:devfile-introduction.adoc[Use a devfile].
 

@@ -1,3 +1,4 @@
+:page-aliases: end-user-guide:devfile-introduction.adoc
 [id="introduction-to-devfile"]
 = Introduction to devfile in {prod-short}
 

@@ -8,15 +8,13 @@
 
 Use link:https://github.com/LobsterTrap/lola[Lola] to distribute team-authored skills, commands, and agents from a central Git repository into {prod-short} workspaces. Lola supports multiple AI assistants, including Claude Code, Cursor, Copilot, Gemini CLI, and OpenCode. It translates module content into each assistant's native file structure, so developers receive a consistent set of standards and tools without manual setup.
 
+A team maintains a Lola module in a Git repository containing skills (coding standards, guardrails), commands (on-demand audit macros), and agent definitions. Developers add a `.lola-req` file to their project referencing the module. Running `lola sync` fetches the module and installs it into the target assistant's native directory structure.
+
 [NOTE]
 ====
-Lola manages skills, commands, and agents — not the full AI assistant configuration. For example, to persist Claude Code settings, MCP servers, and plugins, see xref:persist-claude-code-configuration.adoc[].
+Lola manages skills, commands, and agents only. It does not persist assistant-specific settings, MCP server configurations, or plugin caches. For full Claude Code configuration persistence, see Additional resources.
 ====
 
-== How it works
-
-A team maintains a Lola module in a Git repository containing skills (coding standards, guardrails), commands (on-demand audit macros), and agent definitions. Developers add a `.lola-req` file to their project referencing the module. Running `lola sync` fetches the module and installs it into the target assistant's native directory structure.
-
 .Prerequisites
 
 * An AI assistant (Claude Code, Cursor, Copilot, Gemini CLI, or OpenCode) installed in the workspace container image.
@@ -40,19 +38,17 @@ module/
   AGENTS.md
 ----
 
-* Git credentials configured in the workspace if the module repository is private. See xref:authenticating-to-a-git-server-from-a-workspace.adoc[].
+* Git credentials configured in the workspace if the module repository is private. See xref:get-started-user:authenticating-to-a-git-server-from-a-workspace.adoc[].
 
 .Procedure
 
 . Create a `.lola-req` file at the root of your project repository with a reference to the module:
 +
-====
 [source,text,subs="+quotes"]
 ----
 __<git_repository_url>__@main#subdirectory=module&assistant=__<assistant>__ # <1>
 ----
 <1> Replace `__<git_repository_url>__` with the URL of your Lola module repository. Replace `__<assistant>__` with the target assistant: `claude-code`, `cursor`, `copilot`, `gemini-cli`, or `opencode`. The `subdirectory` fragment points to the module root inside the repository.
-====
 
 . Run `lola sync` to fetch and install the module:
 +
@@ -65,7 +61,6 @@ Lola clones the module, extracts skills and commands, and writes them into the t
 
 . Optional: To automate the sync at workspace startup, add a `postStart` command to your devfile:
 +
-====
 [source,yaml,subs="+quotes,+attributes"]
 ----
 commands:
@@ -80,7 +75,6 @@ events:
 ----
 <1> Replace with the name of your project directory.
 <2> Replace with the name of a container component from the `components` section of your devfile.
-====
 
 .Verification
 

@@ -1,7 +1,7 @@
 :_content-type: PROCEDURE
 :description: You can enable fuse-overlayfs storage driver for Podman
 :keywords: overlay, configmap, podman, storage, driver, fuse-overlayfs
-:navtitle: Enabling fuse-overlayfs with a ConfigMap
+:navtitle: Enabling fuse-overlayfs with a Configmap
 :page-aliases:
 
 [id="enabling-fuse-overlay-with-a-configmap"]

@@ -1,7 +1,7 @@
 :_content-type: PROCEDURE
 :description: Badge for first-time contributors
 :keywords: user-guide, first-time contributor
-:navtitle: Badge for first-time contributors
+:navtitle: Using a badge with a link to enable a first-time contributor to start a workspace
 :page-aliases:
 
 [id="using-a-badge-with-a-link-to-enable-a-first-time-contributor-to-start-a-workspace"]

@@ -1,15 +1,15 @@
 :_content-type: CONCEPT
 :description: Microsoft Visual Studio Code - Open Source IDE
 :keywords: user-guide, selecting, IDE, select, selecting, editor, ide, vs-code, visual-studio, visual-studio-code, jetbrains, intellij, pycharm, theia, che-theia
-:navtitle: Microsoft Visual Studio Code - Open Source
+:navtitle: Microsoft Visual Studio Code - Open Source IDE
 :page-aliases:
 
 [id="microsoft-visual-studio-code-open-source-ide"]
 = Microsoft Visual Studio Code - Open Source IDE
 
 The {prod-short} build of link:https://github.com/microsoft/vscode[Microsoft Visual Studio Code - Open Source] is the default IDE of a new workspace.
 
-You can automate installation of Microsoft Visual Studio Code extensions from the xref:administration-guide:extensions-for-microsoft-visual-studio-code-open-source.adoc[Open VSX registry] at workspace startup. See _Automating installation of Microsoft Visual Studio Code extensions at workspace startup_.
+You can automate installation of Microsoft Visual Studio Code extensions from the Open VSX registry at workspace startup. See _Automating installation of Microsoft Visual Studio Code extensions at workspace startup_. For AI-assisted coding with GitHub Copilot Chat in this IDE, see Additional resources.
 
 [TIP]
 ====
@@ -34,4 +34,10 @@ Configure IDE preferences on a per-workspace basis by invoking the link:https://
 
 NOTE: You might see your organization's branding in this IDE if your organization customized it through a branded build.
 
+[role="_additional-resources"]
+.Additional resources
+
+* xref:administration-guide:extensions-for-microsoft-visual-studio-code-open-source.adoc[]
+* xref:using-github-copilot-chat.adoc[]
+
 include::partial$proc_automating-installation-of-microsoft-visual-studio-code-extensions-at-workspace-startup.adoc[leveloffset=+1]
@@ -9,7 +9,7 @@
 
 [NOTE]
 ====
-The `user.name` and `user.email` fields will be set automatically to the `gitconfig` content from a git provider, connected to {prod-short} by a xref:using-a-git-provider-access-token.adoc[Git-provider access token] or a token generated via OAuth, if username and email are set on the provider's user profile page.
+The `user.name` and `user.email` fields will be set automatically to the `gitconfig` content from a git provider, connected to {prod-short} by a xref:get-started-user:using-a-git-provider-access-token.adoc[Git-provider access token] or a token generated via OAuth, if username and email are set on the provider's user profile page.
 ====
 Follow the instructions below to mount a Git config file in a workspace.
 
@@ -52,7 +52,7 @@ EOF
 
 .Verification
 
-. xref:starting-a-workspace-from-a-git-repository-url.adoc[Start a new workspace by using the URL of a remote Git repository] that the Git provider hosts.
+. xref:get-started-user:starting-a-workspace-from-a-git-repository-url.adoc[Start a new workspace by using the URL of a remote Git repository] that the Git provider hosts.
 . Once the workspace is started, open a new terminal in the `tools` container and run `git config --get-regexp user.*`. Your Git user name and email should appear in the output.