From 628822a3fa9aa954eb2b5b3d824b46644e175549 Mon Sep 17 00:00:00 2001 From: Tom Alexander Date: Fri, 6 Nov 2026 12:29:47 -0500 Subject: [PATCH] docs: rename HyperDX to ClickStack in README and docs HyperDX is being retired as a product name. Update prose in the README, CONTRIBUTING, DEPLOY, LOCAL and agent_docs. Identifiers (env vars, package names, metric/span attributes, image names) and hyperdx.io URLs are unchanged. Also fixes the README logo, which pointed at a favicon directory that no longer exists. --- CONTRIBUTING.md | 10 +++---- DEPLOY.md | 26 +++++++++--------- LOCAL.md | 30 ++++++++++----------- README.md | 51 +++++++++++++++++------------------ agent_docs/README.md | 2 +- agent_docs/architecture.md | 6 ++--- agent_docs/code_style.md | 2 +- agent_docs/data_viz_colors.md | 2 +- agent_docs/evals.md | 12 ++++----- agent_docs/observability.md | 14 +++++----- agent_docs/page_layout.md | 2 +- agent_docs/tech_stack.md | 2 +- 12 files changed, 79 insertions(+), 80 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2d79cbd207..e37d95c5b9 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -96,7 +96,7 @@ problem (or the fix) for themselves. If a maintainer can't reproduce it, they can't triage the issue or review the PR. **Try the demo environment first.** [play.hyperdx.io](https://play.hyperdx.io) -is a hosted HyperDX connected to a public demo dataset (logs, traces, metrics +is a hosted ClickStack instance connected to a public demo dataset (logs, traces, metrics and session replays from the OpenTelemetry demo app). If your bug shows up there, link the exact URL β€” search and chart explorer keep their query, filters and time range in the URL β€” and that's most of the repro. @@ -176,13 +176,13 @@ Service Descriptions: - OpenTelemetry Collector (otel-collector): Receives OpenTelemetry data from instrumented applications and forwards it to ClickHouse for storage. Includes - OpAMP supervisor that dynamically pulls configuration from HyperDX API. + OpAMP supervisor that dynamically pulls configuration from ClickStack API. - ClickHouse (ch-server): ClickHouse database, stores all telemetry. - MongoDB (db): Stores user/saved search/alert/dashboard data. -- HyperDX API (api): Node.js API, executes ClickHouse queries on behalf of the +- ClickStack API (api): Node.js API, executes ClickHouse queries on behalf of the frontend and serves the frontend. serves the frontend. Can also run alert checker. -- HyperDX UI (app): Next.js frontend, serves the UI. +- ClickStack UI (app): Next.js frontend, serves the UI. ## Development @@ -335,7 +335,7 @@ pin. Drop it if that blanket resolution is ever narrowed. ## AI-Assisted Development -HyperDX includes an [MCP server](https://modelcontextprotocol.io/) that lets AI assistants query observability data, manage dashboards, and +ClickStack includes an [MCP server](https://modelcontextprotocol.io/) that lets AI assistants query observability data, manage dashboards, and explore data sources. See [MCP.md](/MCP.md) for setup instructions. The repo also ships with configuration for AI coding assistants that enables interactive browser-based E2E test generation and debugging via diff --git a/DEPLOY.md b/DEPLOY.md index 34a40bcbc1..3710de6c00 100644 --- a/DEPLOY.md +++ b/DEPLOY.md @@ -1,11 +1,11 @@ -# HyperDX Deployment Guide +# ClickStack Deployment Guide -[HyperDX](https://hyperdx.io) helps engineers quickly figure out why production +[ClickStack](https://hyperdx.io) helps engineers quickly figure out why production is broken by making it easy to search & visualize logs and traces on top of any ClickHouse cluster (imagine Kibana, for ClickHouse). You can learn more about -HyperDX in our [README](/README.md). +ClickStack in our [README](/README.md). -HyperDX can be deployed in a few different ways: +ClickStack can be deployed in a few different ways: - [Bring Your Own ClickHouse](#bring-your-own-clickhouse) - [All-in-one Docker Compose Stack](#all-in-one-docker-compose-stack) @@ -18,7 +18,7 @@ and are also served from `docker.clickhouse.com`: | Image | Name | | --------------------------- | -------------------------------------- | -| HyperDX (UI + API) | `clickhouse/clickstack` | +| ClickStack (UI + API) | `clickhouse/clickstack` | | All-in-one (with auth) | `clickhouse/clickstack-all-in-one` | | Local (all-in-one, no auth) | `clickhouse/clickstack-local` | | OpenTelemetry collector | `clickhouse/clickstack-otel-collector` | @@ -31,8 +31,8 @@ stop updating will be announced in the changelog. ## Bring Your Own ClickHouse -If you already have an existing ClickHouse cluster, you can simply deploy a -HyperDX container that connects to your ClickHouse cluster. You'll need a +If you already have an existing ClickHouse cluster, you can simply deploy the +ClickStack container that connects to your ClickHouse cluster. You'll need a separate MongoDB instance to persist your users, dashboards, searches and more. To get started, you can run the following image: @@ -52,13 +52,13 @@ replicas from sharing sessions. The old public value `hyperdx is cool πŸ‘‹` is also replaced with a per-process secret when authentication is enabled. To customize the frontend URL, set the `FRONTEND_URL` environment variable to -the URL your HyperDX instance is hosted on. +the URL your ClickStack instance is hosted on. ## All-in-one Docker Compose Stack -The easiest way to get started with HyperDX from scratch is to use our +The easiest way to get started with ClickStack from scratch is to use our all-in-one Docker Compose stack. This stack will start ClickHouse, an -OpenTelemetry collector, and HyperDX with a MongoDB instance. +OpenTelemetry collector, the ClickStack UI and API, and MongoDB. To get started, clone this repository and run the following command: @@ -66,7 +66,7 @@ To get started, clone this repository and run the following command: docker compose up -d ``` -This will start the HyperDX stack and open a port for the UI, API, and OTel +This will start the ClickStack stack and open a port for the UI, API, and OTel collector. When deploying into production, you'll want to disable any extra ports outside @@ -91,9 +91,9 @@ replicas from sharing sessions. The old public value is not a production secret. ## Local Development Mode -HyperDX can also be deployed alongside your existing local development stack to +ClickStack can also be deployed alongside your existing local development stack to help you debug issues locally. This mode will start an OpenTelemetry collector, -ClickHouse, and HyperDX with a MongoDB in a single instance, without any +ClickHouse, the ClickStack UI and API, and MongoDB in a single container, without any authentication or configuration persistence. To get started, spin up the local mode container: diff --git a/LOCAL.md b/LOCAL.md index 359ffe4e1d..8ee39f52e0 100644 --- a/LOCAL.md +++ b/LOCAL.md @@ -1,13 +1,13 @@ -# HyperDX Local +# ClickStack Local -HyperDX Local is a single container local-optimized version of [HyperDX](https://www.hyperdx.io/) that allows you to pipe OpenTelemetry telemetry (logs, metrics, traces) to a local instance of HyperDX running on your own machine. This makes it easily to debug complex applications locally using the same telemetry you have in prod or to test your instrumentation before pushing it into production. +ClickStack Local is a single container local-optimized version of [ClickStack](https://www.hyperdx.io/) that allows you to pipe OpenTelemetry telemetry (logs, metrics, traces) to a local instance of ClickStack running on your own machine. This makes it easily to debug complex applications locally using the same telemetry you have in prod or to test your instrumentation before pushing it into production. -HyperDX Local has a few additional benefits tuned to local development over the regular version: +ClickStack Local has a few additional benefits tuned to local development over the regular version: - πŸ“¦ Packaged in a single container, to slot alongside your existing dev environment (ex. Docker Compose stack) - πŸ”‘ No need to auth to send and view telemetry - 🐏 Optimized for lower memory footprint -And it has all the features you would expect from HyperDX: +And it has all the features you would expect from ClickStack: - πŸ”­ Native OpenTelemetry logs, metrics, and traces support - πŸ” Full text searching of logs and traces - `{` Automatic JSON structured log parsing @@ -15,7 +15,7 @@ And it has all the features you would expect from HyperDX: - πŸ“ˆ Charting logs, metrics and traces in a single UI
-Demo of using HyperDX Local for debugging a local app +Demo of using ClickStack Local for debugging a local app ## Getting Started @@ -25,24 +25,24 @@ To get started, simply run the Docker container with the appropriate ports forwa docker run -p 8000:8000 -p 4318:4318 -p 4317:4317 -p 8080:8080 -p 8002:8002 docker.clickhouse.com/clickhouse/clickstack-local ``` -Afterwards, you can visit `http://localhost:8080` and immediately jump into the HyperDX UI. +Afterwards, you can visit `http://localhost:8080` and immediately jump into the ClickStack UI. > We recommend having _at least_ 1GB of RAM and 1 CPU core available for the container. ## Configuring Instrumentation -Configuring instrumentation for HyperDX local is similar to configuring it for the regular open source version. You should point your OpenTelemetry instrumentation to the OpenTelemetry endpoints: +Configuring instrumentation for ClickStack Local is similar to configuring it for the regular open source version. You should point your OpenTelemetry instrumentation to the OpenTelemetry endpoints: - `http://localhost:4318` for HTTP - `localhost:4317` for gRPC Most instrumentations can be configured using the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. Ex: `OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318`. -If you're using a HyperDX maintained SDK, you may need to give a non-empty `HYPERDX_API_KEY` as well, API keys are not validated in HyperDX Local and therefore can be any non-empty value. +If you're using a ClickStack maintained SDK, you may need to give a non-empty `HYPERDX_API_KEY` as well, API keys are not validated in ClickStack Local and therefore can be any non-empty value. ## Customizing Ports -If you need to customize the app (8080) or api (8000) ports that HyperDX Local runs on, you'll need to modify the `docker run` command to forward the appropriate ports and set a few environment variables. +If you need to customize the app (8080) or api (8000) ports that ClickStack Local runs on, you'll need to modify the `docker run` command to forward the appropriate ports and set a few environment variables. Customizing the OpenTelemetry ports can simply be changed by modifying the port forwarding flags. Ex. Replacing `-p 4318:4318` with `-p 4999:4318` to change the OpenTelemetry HTTP port to 4999. @@ -61,13 +61,13 @@ docker.clickhouse.com/clickhouse/clickstack-local ## Open Source & Cloud Versions (Beyond Local) -If you're looking to deploy HyperDX to monitor a production environment (or anything outside your local environment), you can check out the [regular open source version](https://github.com/ClickHouse/ClickStack) or the [cloud hosted version](https://hyperdx.io/). +If you're looking to deploy ClickStack to monitor a production environment (or anything outside your local environment), you can check out the [regular open source version](https://github.com/ClickHouse/ClickStack) or the [cloud hosted version](https://hyperdx.io/). ### Local vs Non-Local Versions -There are a few missing features in HyperDX Local compared to the other versions of HyperDX: +There are a few missing features in ClickStack Local compared to other ClickStack deployments: -- HyperDX Local is single-user only (due to skipping auth) +- ClickStack Local is single-user only (due to skipping auth) - Has no support for [management APIs](https://www.hyperdx.io/docs/api/alerts) - No alerting support (alerts will not fire) - DB queries will not be reduced into query patterns @@ -79,9 +79,9 @@ There are a few missing features in HyperDX Local compared to the other versions - `4317` - OpenTelemetry gRPC endpoint - `4318` - OpenTelemetry HTTP endpoint -- `8000` - Private HyperDX API for the UI -- `8002` - HyperDX HTTP Logging Endpoint -- `8080` - HyperDX UI (Next.js) +- `8000` - Private ClickStack API for the UI +- `8002` - ClickStack HTTP Logging Endpoint +- `8080` - ClickStack UI (Next.js) ### Build Image (Only For Development) diff --git a/README.md b/README.md index f4a2281441..448ae5a076 100644 --- a/README.md +++ b/README.md @@ -1,27 +1,26 @@

- hyperdx logo + ClickStack logo

-

HyperDX

+

ClickStack

GitHub stars License Release - Join the HyperDX Discord + Join the ClickStack Discord

- hyperdxio%2Fhyperdx | Trendshift + ClickHouse%2FClickStack | Trendshift

-[HyperDX](https://hyperdx.io), a core component of -[ClickStack](https://clickhouse.com/use-cases/observability), helps engineers -quickly figure out why production is broken by making it easy to search & -visualize logs and traces on top of any ClickHouse cluster (imagine Kibana, for -ClickHouse). +[ClickStack](https://clickhouse.com/use-cases/observability) (formerly HyperDX) +helps engineers quickly figure out why production is broken by making it easy to +search & visualize logs and traces on top of any ClickHouse cluster (imagine +Kibana, for ClickHouse).

Documentation β€’ Chat on Discord β€’ Live Demo β€’ Bug Reports β€’ Contributing β€’ Website @@ -43,16 +42,16 @@ ClickHouse).
Search logs and traces all in one place -## Spinning Up HyperDX +## Spinning Up ClickStack -HyperDX can be deployed as part of ClickStack, which includes ClickHouse, -HyperDX, OpenTelemetry Collector and MongoDB. +The all-in-one image bundles ClickHouse, the ClickStack UI, the OpenTelemetry +Collector and MongoDB. ```bash docker run -p 8080:8080 -p 4317:4317 -p 4318:4318 docker.clickhouse.com/clickhouse/clickstack-all-in-one ``` -Afterwards, you can visit http://localhost:8080 to access the HyperDX UI. +Afterwards, you can visit http://localhost:8080 to access the ClickStack UI. If you already have an existing ClickHouse instance, want to use a single container locally, or are looking for production deployment instructions, you @@ -67,18 +66,18 @@ can view the different deployment options in our ### Hosted ClickHouse Cloud -You can also deploy HyperDX with ClickHouse Cloud, you can +You can also deploy ClickStack with ClickHouse Cloud, you can [sign up for free](https://console.clickhouse.cloud/signUp) and get started in just minutes. ## Instrumenting Your App -To get logs, metrics, traces, session replay, etc into HyperDX, you'll need to -instrument your app to collect and send telemetry data over to your HyperDX -instance. +To get logs, metrics, traces, session replay, etc into ClickStack, you'll need +to instrument your app to collect and send telemetry data over to your +ClickStack instance. We provide a set of SDKs and integration options to make it easier to get -started with HyperDX, such as +started with ClickStack, such as [Browser](https://clickhouse.com/docs/use-cases/observability/clickstack/sdks/browser), [Node.js](https://clickhouse.com/docs/use-cases/observability/clickstack/sdks/nodejs), and @@ -89,7 +88,7 @@ You can find the full list in **OpenTelemetry** -Additionally, HyperDX is compatible with +Additionally, ClickStack is compatible with [OpenTelemetry](https://opentelemetry.io/), a vendor-neutral standard for instrumenting your application backed by CNCF. Supported languages/platforms include: @@ -107,13 +106,13 @@ include: (Full list [here](https://opentelemetry.io/docs/instrumentation/)) -Once HyperDX is running, you can point your OpenTelemetry SDK to the +Once ClickStack is running, you can point your OpenTelemetry SDK to the OpenTelemetry collector spun up at `http://localhost:4318`. -## HyperDX CLI +## ClickStack CLI Prefer the terminal? [`@hyperdx/cli`](./packages/cli) provides an interactive -TUI and CLI (`hdx`) for working with your HyperDX data without leaving the +TUI and CLI (`hdx`) for working with your ClickStack data without leaving the shell: ```bash @@ -166,7 +165,7 @@ a few ways: 3. They requiring hopping from tool to tool (logs, session replay, APM, exceptions, etc.) to stitch together the clues yourself. -We hope you give HyperDX in ClickStack a try and let us know how we're doing! +We hope you give ClickStack a try and let us know how we're doing! ## Contact @@ -174,14 +173,14 @@ We hope you give HyperDX in ClickStack a try and let us know how we're doing! - [Discord](https://discord.gg/FErRRKU78j) - [Email](mailto:support@hyperdx.io) -## HyperDX Usage Data +## ClickStack Usage Data -HyperDX collects anonymized usage data for open source deployments. This data +ClickStack collects anonymized usage data for open source deployments. This data supports our mission for observability to be available to any team and helps support our open source product run in a variety of different environments. While we hope you will continue to support our mission in this way, you may opt out of usage data collection by setting the `USAGE_STATS_ENABLED` environment -variable to `false`. Thank you for supporting the development of HyperDX! +variable to `false`. Thank you for supporting the development of ClickStack! ## License diff --git a/agent_docs/README.md b/agent_docs/README.md index a8aafa3cb3..58ff6241aa 100644 --- a/agent_docs/README.md +++ b/agent_docs/README.md @@ -1,6 +1,6 @@ # Agent Documentation Directory -This directory contains detailed documentation for AI coding agents working on the HyperDX codebase. These files use **progressive disclosure** - they're referenced from `AGENTS.md` but only read when needed. +This directory contains detailed documentation for AI coding agents working on the ClickStack codebase. These files use **progressive disclosure** - they're referenced from `AGENTS.md` but only read when needed. ## Purpose diff --git a/agent_docs/architecture.md b/agent_docs/architecture.md index 30dfce4528..b42eaebe5d 100644 --- a/agent_docs/architecture.md +++ b/agent_docs/architecture.md @@ -1,9 +1,9 @@ -# HyperDX Architecture +# ClickStack Architecture ## Core Services -- **HyperDX UI (`packages/app`)**: Next.js frontend serving the user interface -- **HyperDX API (`packages/api`)**: Node.js/Express backend handling queries and business logic +- **ClickStack UI (`packages/app`)**: Next.js frontend serving the user interface +- **ClickStack API (`packages/api`)**: Node.js/Express backend handling queries and business logic - **OpenTelemetry Collector**: Receives and processes telemetry data - **ClickHouse**: Primary data store for all telemetry (logs, metrics, traces) - **MongoDB**: Metadata storage (users, dashboards, alerts, saved searches) diff --git a/agent_docs/code_style.md b/agent_docs/code_style.md index a925429dce..16b4836eb1 100644 --- a/agent_docs/code_style.md +++ b/agent_docs/code_style.md @@ -410,7 +410,7 @@ Mantine theme overrides in `packages/app/src/theme/**` may map Mantine’s scale `@clickhouse/click-ui` is a dependency of `packages/app`. `ThemeWrapper` mounts `ClickUIProvider` inside `MantineProvider` with `persistTheme={false}`, so it -follows the HyperDX color mode and never writes its own theme to localStorage. +follows the app color mode and never writes its own theme to localStorage. Storybook and `renderWithMantine` in tests get the provider for free. - **Do**: Prefer a click-ui component over a new Mantine one when click-ui has diff --git a/agent_docs/data_viz_colors.md b/agent_docs/data_viz_colors.md index 92d7960281..bc7209e2f9 100644 --- a/agent_docs/data_viz_colors.md +++ b/agent_docs/data_viz_colors.md @@ -1,6 +1,6 @@ # Data Visualization Colors -> Single source of truth for chart and visualization colors in HyperDX. Read +> Single source of truth for chart and visualization colors in ClickStack. Read > this before adding, changing, or hard-coding a color in any chart, sparkline, > heatmap, legend, status pill, or other data display. diff --git a/agent_docs/evals.md b/agent_docs/evals.md index ff918e3df4..d7e091aa3f 100644 --- a/agent_docs/evals.md +++ b/agent_docs/evals.md @@ -41,7 +41,7 @@ This is the standard workflow for comparing a feature branch against main. ### Architecture Evals run from **one worktree** (the branch being tested). The eval harness -talks to **two separate HyperDX API instances** running on different slots: +talks to **two separate ClickStack API instances** running on different slots: ``` β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” @@ -68,7 +68,7 @@ talks to **two separate HyperDX API instances** running on different slots: ``` Each slot runs its own ClickHouse instance. `setup-hyperdx` (step 2) creates -the HyperDX account, Connection, and Sources on each instance, but does **not** +the ClickStack account, Connection, and Sources on each instance, but does **not** seed telemetry data. The `run` command auto-seeds on first run, but only into the single ClickHouse specified in the top-level `clickhouse` config β€” so for dual-slot comparisons you must seed each instance explicitly (step 4b). @@ -106,7 +106,7 @@ curl -s -o /dev/null -w "Slot 99 CH: %{http_code}\n" http://localhost:30599/ > branch under test). This registers an eval account, creates a ClickHouse Connection, and creates -per-scenario Sources on each HyperDX instance. The command is **idempotent** β€” +per-scenario Sources on each ClickStack instance. The command is **idempotent** β€” it skips anything that already exists, so it's safe to run every time. **Skip this step** if `eval.config.branch.json` and `eval.config.main.json` @@ -189,7 +189,7 @@ curl -s -o /dev/null -w "Main MCP: %{http_code}\n" \ ### 5. Seed both ClickHouse instances -`setup-hyperdx` creates the HyperDX account and Sources but does **not** seed +`setup-hyperdx` creates the ClickStack account and Sources but does **not** seed telemetry data. The `run` command's auto-seed only writes to the single ClickHouse in the top-level `clickhouse` config, so you must seed each instance explicitly: @@ -267,10 +267,10 @@ yarn workspace @hyperdx/hdx-eval dev run error-root-cause \ --mcp hyperdx --model claude-opus-4-6 --runs 3 ``` -### Non-HyperDX MCP (e.g. raw ClickHouse) +### Non-ClickStack MCP (e.g. raw ClickHouse) The framework works with any MCP. The `clickhouse` stdio MCP is included by -default in `eval.config.json` after setup. Use it to compare HyperDX's MCP +default in `eval.config.json` after setup. Use it to compare ClickStack's MCP against querying ClickHouse directly. ```bash diff --git a/agent_docs/observability.md b/agent_docs/observability.md index a814e3643f..758ed5edb3 100644 --- a/agent_docs/observability.md +++ b/agent_docs/observability.md @@ -1,6 +1,6 @@ # Observability & Instrumentation -HyperDX is an observability product, so our own code should be a shining example +ClickStack is an observability product, so our own code should be a shining example of well-instrumented software. When you add or change a feature, instrument it as part of the change - not as an afterthought. @@ -30,7 +30,7 @@ aligned with the already in flight, and put point-in-time / gauge-style values (sizes, counts, depths, current state) there rather than in a gauge. This is an internal engineering preference, not a rule against metrics β€” counters and histograms - remain first-class, feed alerts and SLOs, and many HyperDX deployments depend + remain first-class, feed alerts and SLOs, and many ClickStack deployments depend heavily on them. See [Wide events over gauges](#wide-events-over-gauges). 5. **Use the shared helpers** in [`packages/api/src/utils/instrumentation.ts`](../packages/api/src/utils/instrumentation.ts). @@ -57,7 +57,7 @@ types, so a single import is usually enough. ### Tracing -Rely on the HyperDX SDK auto-instrumentation (HTTP, Express, Mongo, etc.) for +Rely on the ClickStack SDK auto-instrumentation (HTTP, Express, Mongo, etc.) for the common path. Add a **manual span only for a meaningful unit of work** that auto-instrumentation can't see - a background job step, a fan-out, an expensive computation, an external tool invocation. @@ -91,7 +91,7 @@ Span rules to follow (from the Instrumentation Score spec): ### Business context Attach team/user context as early as possible (at the auth boundary or the top -of a job). `setBusinessContext` writes both to the whole trace (via the HyperDX +of a job). `setBusinessContext` writes both to the whole trace (via the ClickStack SDK, requires `HDX_NODE_BETA_MODE=1`) and to the active span. ```ts @@ -120,9 +120,9 @@ Standard attribute keys: ### Wide events over gauges -> **Scope:** this is HyperDX's _internal_ instrumentation philosophy for the +> **Scope:** this is ClickStack's _internal_ instrumentation philosophy for the > code in this repo β€” not a recommendation that users pick wide events over -> metrics. Metrics are a first-class HyperDX signal that many operators rely on; +> metrics. Metrics are a first-class ClickStack signal that many operators rely on; > nothing here discourages them. What follows is simply how _we_ prefer to > instrument our own services. @@ -237,7 +237,7 @@ auto-instrumentation and error middleware already cover. ## Query attribution -Every ClickHouse query HyperDX runs is tagged with what asked for it, so a row +Every ClickHouse query ClickStack runs is tagged with what asked for it, so a row in the customer's `system.query_log` points back to a dashboard tile, a saved search, an alert, or an MCP tool. This is the one piece of our instrumentation that lands in *their* data rather than ours, so it stays small, carries no diff --git a/agent_docs/page_layout.md b/agent_docs/page_layout.md index c1ca244760..cde50f3c04 100644 --- a/agent_docs/page_layout.md +++ b/agent_docs/page_layout.md @@ -1,6 +1,6 @@ # Page layout and headers -HyperDX app pages share a sticky top header bar and a scrollable content region below it. Use the shared layout primitives so titles, controls, and spacing stay consistent across Search, list pages, and tool pages (Service Map, Kubernetes, Chart Explorer). +ClickStack app pages share a sticky top header bar and a scrollable content region below it. Use the shared layout primitives so titles, controls, and spacing stay consistent across Search, list pages, and tool pages (Service Map, Kubernetes, Chart Explorer). ## Components diff --git a/agent_docs/tech_stack.md b/agent_docs/tech_stack.md index 1fb61f34e0..efe0f3c552 100644 --- a/agent_docs/tech_stack.md +++ b/agent_docs/tech_stack.md @@ -1,4 +1,4 @@ -# HyperDX Technology Stack +# ClickStack Technology Stack ## Frontend (`packages/app`)