chore: remove dead templates/ build toolchain and orphaned cdmq scripts

CLAUDE.md

@@ -5,13 +5,13 @@ Defines a unified data model for storing and querying performance test data in O
 
 ## Languages
 - **JavaScript/Node.js**: Query library and server (`queries/cdmq/`)
-- **Bash**: Template management scripts (`templates/`)
+- **Bash**: `templates/delete.sh`, a standalone index-cleanup script
 
 ## Key Directories
 | Path | Purpose |
 |------|---------|
 | `queries/cdmq/` | Node.js query library and HTTP server |
-| `templates/` | OpenSearch index templates and management scripts |
+| `templates/` | Just `delete.sh` — a destructive cleanup script invoked by crucible's `reinit_opensearch()`. Index mappings themselves are defined in `queries/cdmq/cdm.js` (see Templates section below) |
 | `workflows/` | Documentation (result-calculation methodology) |
 
 ## Key Files in `queries/cdmq/`
@@ -38,10 +38,9 @@ Supporting document types: `param`, `tag`, `config_*`
 - v10dev's key addition is `default-aggregation` — a per-metric field on `metric_desc` (`sum`/`avg`/`max`/`min`) telling query-time aggregation how to combine values across breakout dimensions, instead of always duration-weighted summing
 
 ## Templates (`templates/`)
-- `.base` files define index mappings for each document type
-- `build.sh` / `Makefile` generate actual template commands
-- `init.sh` initializes the OpenSearch indices
-- All indices are `"dynamic": "strict"` — every `metric_desc.names` breakout dimension a tool/benchmark might emit must be pre-registered as an explicit `keyword`/`double` field in `metric_desc.base`, or indexing rejects it. `dynamic_templates` do NOT provide an exception to this (verified empirically) — a field matching a `dynamic_templates` glob is rejected exactly like any other unregistered field under `"dynamic": "strict"`. A dimension family with an unbounded/platform-dependent set of names (e.g. one field per CPU cache level) still needs each concrete name registered explicitly (e.g. `shared-l1-domain` .. `shared-l4-domain`) rather than a wildcard shortcut.
+- Index mappings for every document type are defined in `queries/cdmq/cdm.js`'s `indexDefs` object (`v8dev` hand-written, `v9dev`/`v10dev` built forward via `deepClone`). This is the only live schema — `add-run.js`'s `checkCreateIndex()`/`updateIndexMappings()` use it to create/update OpenSearch indices, and also use it as a client-side validation gate, rejecting any document field not present in it before the document is ever sent to OpenSearch.
+- `templates/delete.sh` is the sole surviving file in this directory — a standalone, destructive script (deletes every index on `localhost:9200`) invoked by crucible's `reinit_opensearch()`. It has no dependency on `cdm.js` or any schema definition.
+- All indices are `"dynamic": "strict"` — every `metric_desc.names` breakout dimension a tool/benchmark might emit must be pre-registered as an explicit `keyword`/`double` field in `cdm.js`'s `indexDefs`, or indexing rejects it. `dynamic_templates` do NOT provide an exception to this (verified empirically) — a field matching a `dynamic_templates` glob is rejected exactly like any other unregistered field under `"dynamic": "strict"`. A dimension family with an unbounded/platform-dependent set of names (e.g. one field per CPU cache level) still needs each concrete name registered explicitly (e.g. `shared-l1-domain` .. `shared-l4-domain`) rather than a wildcard shortcut.
 
 ## Code Style
 - JavaScript: Prettier formatting enforced (2-space indent, checked in CI via `cdm-ci.yaml`)

README.md

@@ -7,14 +7,15 @@ Our Data is the problem.  When it comes to performance benchmarking, or just mon
 We can define a common way to store information about our environment, our performance tests (if any), and metrics and events we collect.  Having a common way to process this information allows us to query, summarize, and visualize performance data across many situations, from comparing compiler performance to identifying bottlenecks in large cloud deployments.
 ### What This Project Includes
 We provide enough information so that anyone can start storing and querying this data in a common way:
-* OpenSearch index templates
+* OpenSearch index mapping definitions (`queries/cdmq/cdm.js`)
 * A Node.js query library and HTTP query server (`queries/cdmq/`)
 ### What This Project Does Not Include
 * data conversion scripts: conversion of data is expected to be in the other projects, for example: [uperf-post-process](https://github.com/perftool-incubator/bench-uperf/blob/master/uperf-post-process)
 * data indexing scripts: indexing of data is also expected to be in other projects, for example: [rickshaw-index](https://github.com/perftool-incubator/rickshaw/blob/master/rickshaw-index)
 ## Directory/Layout
 [./templates](./templates)
-OpenSearch index templates and management scripts (init, build, delete).
+`delete.sh`, a destructive OpenSearch index cleanup script. Index mapping
+definitions themselves live in `queries/cdmq/cdm.js`, not here.
 
 [./queries](./queries)
 The `cdmq` query implementation, built on Node.js.  Includes a core query library (`cdm.js`), command-line query scripts, and an HTTP server (`server.js`) that exposes CDM queries as REST endpoints.

queries/cdmq/README.md

@@ -5,12 +5,12 @@
 [Node.js](https://nodejs.org) and npm must be installed. Dependencies are installed automatically when you run any of the shell wrapper scripts (e.g., `get-result-summary.sh`). You can also install them manually:
 
 ```bash
-./setup.sh
+npm install
 ```
 
 ## Introduction
 
-The contents of this directory contain a collection of scripts in Javascript intended to be executed with [node.js](https://nodejs.org). These scripts get data from an OpenSearch instance. The data must be in Common Data Format. which is documented in this project under [templates](../templates). The scripts here are meant to help inspect, compare, and export data from benchmarks and performance & resource-utilization tools, in order to report and investigate performance.
+The contents of this directory contain a collection of scripts in Javascript intended to be executed with [node.js](https://nodejs.org). These scripts get data from an OpenSearch instance. The data must be in Common Data Format, whose index mapping definitions are documented in [cdm.js](./cdm.js)'s `indexDefs` object. The scripts here are meant to help inspect, compare, and export data from benchmarks and performance & resource-utilization tools, in order to report and investigate performance.
 
 In order to generate this data, you must run a benchmark via automation framework which uses the Common Data Format and index that data into OpenSearch. One of those automation frameworks is the [crucible](https://github.com/perftool-incubator/crucible) project. A subproject of crucible, [crucible-examples](https://github.com/perftool-incubator/crucible-examples), includes scenarios to run some of these benchmarks.