fix: standardize terminology — CDE defined once, workspace throughout

- Add CDE=workspace=DevWorkspace equivalence to your-first-workspace overview
- Change title from "Cloud Development Environment" to "cloud workspace"
  for consistency with rest of Get Started guide and UI terminology
- After the first definition, "workspace" is used consistently

Follows Google/Microsoft pattern: define the full term once, use the
short product term throughout.

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: gtrivedi88

CLAUDE.md

@@ -0,0 +1,159 @@
+# CLAUDE.md - Eclipse Che Documentation
+
+## Project Overview
+
+Eclipse Che documentation built with **Antora** and **AsciiDoc**. Published at https://www.eclipse.org/che/docs/.
+
+## Build Commands
+
+```bash
+# Local preview (requires container tools)
+./tools/preview.sh
+
+# Build documentation site
+antora generate antora-playbook-for-development.yml
+
+# Build and verify container
+./tools/build-and-verify-container.sh
+
+# Validate language (Vale) on changed files
+./tools/validate_language_changes.sh
+
+# Detect unused/orphaned content
+./tools/detect_unused_content.sh
+
+# Validate AsciiDoc attributes
+./tools/validate_attributes_processing.sh
+
+# Verify cross-references
+./tools/verify_xrefs.sh
+```
+
+## Repository Structure
+
+```
+modules/                          # Content modules
+  administration-guide/           # Deployment, configuration, management
+  end-user-guide/                 # User-facing features
+  extensions/                     # Extension development
+  glossary/                       # Terminology
+  hosted-che/                     # Hosted solution docs
+  overview/                       # Introduction and overview
+  <module>/
+    pages/                        # Full navigable pages
+    partials/                     # Reusable content snippets
+    images/                       # Module-specific images
+    examples/                     # Code/content examples
+    nav.adoc                      # Navigation structure
+
+tools/                            # Build and validation scripts
+supplemental-ui/                  # Custom UI overrides (CSS, fonts, images)
+templates/                        # Content templates (assembly, concept, procedure, reference)
+extensions/                       # Antora extensions (PDF, htmltest)
+.github/workflows/                # CI/CD (10 workflows)
+```
+
+## Key Configuration Files
+
+- `antora.yml` - Component descriptor, version, 200+ AsciiDoc attributes
+- `antora-playbook-for-development.yml` - Build playbook for local/PR builds
+- `antora-assembler.yml` - PDF generation playbook
+- `.htmltest.yml` - Link validation config
+- `.vale.ini` - Language/style validation config
+- `Containerfile` - Build container definition
+- `devfile.yaml` - Eclipse Che workspace definition
+
+## Branch Strategy
+
+- `main` - Next version development (currently targets 7.115.x)
+- `7.115.x`, `7.113.x`, etc. - Stable release branches
+- `publication` - Published documentation (read-only)
+- Backport branches: `backport-<PR#>-to-<version>` (e.g., `backport-3017-to-7.113.x`)
+
+### Remotes
+
+- `origin` - User's fork (e.g., `gtrivedi88/che-docs`)
+- `upstream` - Canonical repo (`eclipse-che/che-docs`)
+
+## Backporting Workflow
+
+1. Ensure the PR is merged to `main` first
+2. Fetch upstream and checkout the target release branch:
+   ```bash
+   git fetch upstream <branch>
+   git checkout upstream/<branch>
+   git checkout -b backport-<PR#>-to-<branch>
+   ```
+3. Cherry-pick the **merge commit** (not the individual commits):
+   ```bash
+   gh pr view <PR#> --json mergeCommit
+   git cherry-pick <merge-commit-sha>
+   ```
+4. Push and create PR against the release branch:
+   ```bash
+   git push -u origin backport-<PR#>-to-<branch>
+   gh pr create --base <branch> --head <user>:backport-<PR#>-to-<branch>
+   ```
+
+## AsciiDoc Conventions
+
+### File Naming
+- Lowercase with dashes: `installing-che-on-openshift.adoc`
+- Partials prefixed in includes: `include::partial$filename.adoc[]`
+
+### Page Structure
+```asciidoc
+[id="page-id"]
+= Page Title
+:description: Brief description
+:keywords: comma, separated, keywords
+:navtitle: Navigation Title
+:_content-type: ASSEMBLY|CONCEPT|PROCEDURE|REFERENCE
+```
+
+### Content Types
+- **ASSEMBLY** - Collection of modules describing a user story
+- **CONCEPT** - Explanation/description
+- **PROCEDURE** - Step-by-step how-to
+- **REFERENCE** - Reference material
+
+### Attributes
+Product-specific values are defined in `antora.yml` (200+ attributes). Use attributes instead of hardcoded values:
+- `{prod-short}` - Short product name
+- `{prod}` - Full product name
+- `{prod-ver}` - Product version (e.g., 7.115)
+
+## CI/CD Pipeline (GitHub Actions)
+
+On PRs:
+- **build-and-validate-on-pr** - Antora build + htmltest link validation
+- **vale** - Language linting (fails on errors)
+- **container-on-pull-request** - Verifies container builds
+- **publish-netlify** - Deploys preview site, posts comment with URL
+
+On merge to main:
+- **build-and-validate-on-push** - Full build + validation
+- **container-build** - Build and push container to Quay.io
+- **call-publication-builder** - Publishes to publication branch
+
+## Common Gotchas
+
+### AsciiDoc Callout Lists
+An IMPORTANT/NOTE/TIP block between callout items breaks numbering. The block must be integrated as a sub-paragraph of the preceding callout using the `+` continuation, not placed standalone between callout items.
+
+### Container Build Failures
+The `@antora/assembler` npm package must be pinned (e.g., `@1.0.0-beta.14`) in the Containerfile. Unpinned versions can cause exit code 1 during container builds.
+
+### External Link Failures
+Transient external link failures (e.g., cert-manager.io timeouts) are handled by `IgnoreExternalBrokenLinks: true` in `.htmltest.yml`. Persistently broken URLs should be added to the `IgnoreURLs` list.
+
+### Cherry-pick Conflicts
+When cherry-picking between branches, the `configuring-proxy.adoc` file has had formatting differences between branches. Always verify the cherry-pick applied cleanly.
+
+## PR Conventions
+
+### Title Prefixes
+- `docs:` - Documentation (no procedures), engineering review mandatory
+- `procedures:` - Includes procedures, testing mandatory
+- `chore:` - Routine, release, tooling, version upgrades
+- `fix:` - Fix build, language, links, or metadata

modules/get-started/pages/starting-a-workspace-from-a-git-repository-url.adoc

@@ -1,11 +1,11 @@
 :_content-type: PROCEDURE
 :description: Starting a workspace from a Git repository URL
 :keywords: start-new-workspace, start-a-new-workspace, how-to-start-new-workspace, how-to-start-a-new-workspace, starting-a-new-workspace, clone-git-repository, clone-a-git-repository, how-to-start-workspace, how-to-start-a-workspace
-:navtitle: Open your project in a Cloud Development Environment
+:navtitle: Open your project in a cloud workspace
 :page-aliases: end-user-guide:starting-a-workspace-from-a-git-repository-url.adoc
 
 [id="starting-a-workspace-from-a-git-repository-url"]
-= Open your project in a Cloud Development Environment
+= Open your project in a cloud workspace
 
 In the context of this procedure, "Git repository URL" refers to a git clone URL of a repository. Usually, you can fetch this URL by clicking on the *Clone* button in the SCM repository's main page.
 Alternatively, you can copy the URL from the address bar of your browser when you are on the main page of the repository.

modules/get-started/pages/your-first-workspace.adoc

@@ -7,7 +7,7 @@
 = Your first-day experience
 
 [role="_abstract"]
-When you open the {prod-short} URL for the first time, you go from login to coding in about three minutes. The following sections cover the login flow, first workspace creation, workspace tools, and common errors.
+{prod-short} creates a Cloud Development Environment for your project, called a *workspace* in the dashboard and CLI. Each workspace runs as a {orch-name} `DevWorkspace` custom resource on your cluster. You go from login to coding in about three minutes.
 
 include::partial$snip_persona-developer.adoc[]