measur-tools-suite 1.2.1-beta.4 → 1.2.1-beta.5

package/.claude/CLAUDE.md

@@ -1,33 +1,17 @@
-# Project Memory
+# Claude Project Guidance
 
-When generating code, always follow the coding standards and conventions in the [Style Guide](../contributing/style-guide.md). When documenting code, always follow the documentation standards in [Documentation](../contributing/documentation.md). If either linked file is not available in context, ask the user to provide it before proceeding.
+Follow the canonical repository instructions in [../AGENTS.md](../AGENTS.md). Do not duplicate long-form policy here; update `AGENTS.md` when project-wide agent guidance changes.
 
-When tasked to refactor code using namespaces, follow these phases in order. In all phases, maintain a **one file per logical module** rule: each .h/.cpp pair produces exactly one corresponding binding file, one C++ test file, and one wasm test file.
+## Quick Orientation
 
-**Phase 1 — Headers and Source**
-Update the .h and .cpp files to reflect the new structure.
+- Read [../ARCHITECTURE.md](../ARCHITECTURE.md) before broad edits.
+- Read [../BUILD.md](../BUILD.md) before changing build, package, WASM, or test workflows.
+- Follow [../contributing/style-guide.md](../contributing/style-guide.md) and [../contributing/documentation.md](../contributing/documentation.md).
+- For TypeScript WASM tests, follow [../tests/wasm-mocha/README.md](../tests/wasm-mocha/README.md).
 
-**Phase 2 — WebAssembly Bindings**
-For each .h/.cpp pair, create or update exactly one binding file in bindings-wasm/ (one binding file per logical module, matching its .h and .cpp filenames). If no existing binding file exists for a given pair, create one from scratch following the structure used in processHeat/bindings-wasm/.
+## Claude Workflow Notes
 
-**Phase 3 — C++ Unit Tests**
-Update the .cpp unit tests in tests/cpp to reflect the new structure. Each .cpp file must have its own dedicated test file. If an existing test file covers multiple classes that are being split into separate .cpp files, split the test file accordingly.
-
-**Phase 4 — WebAssembly Unit Tests**
-Update or add a unit test in tests/wasm-mocha for each binding file (one test file per binding file). Move old unit tests from tests/wasm to tests/wasm-mocha and update them to reflect the new structure. Once a test has been successfully migrated, delete the original file from tests/wasm.
-
-**Phase 5 — Documentation**
-Update the documentation in the docs/dox-content directory. Organize the content logically following the pattern that has already been established.
-
-**Reference example:** refer to processHeat/ as the canonical example of how to structure the code, WebAssembly bindings, unit tests, and documentation.
-
-**Checklist (verify before finishing):**
-- [ ] Phase 1: All .h and .cpp files updated
-- [ ] Phase 2: One binding file per .h/.cpp pair; new files created where none existed
-- [ ] Phase 3: One C++ test file per .cpp file; split if needed
-- [ ] Phase 4: One wasm test file per binding file; old tests/wasm files migrated and deleted
-- [ ] Phase 5: Documentation updated and organized
-
-## Context
-
-The MEASUR Tools Suite is a collection of industrial efficiency calculations written in C++ with WebAssembly bindings for browser and Node.js environments. The suite provides computational engines for the [MEASUR](https://github.com/ORNL-AMO/AMO-Tools-Desktop) (Manufacturing Energy Assessment Suite for Utility Reduction) application ecosystem.
+- Make a short plan for multi-file or cross-layer changes.
+- Inspect related C++ source, WASM bindings, `ts_def` declarations, and tests before editing.
+- Keep the one-module rule from `AGENTS.md`: source, binding, declaration, tests, and docs should move together.
+- Report exactly which validation commands were run and which were not.

package/AGENTS.md

@@ -1,33 +1,124 @@
-# Project Memory
+# Agent Development Guide
 
-When generating code, always follow the coding standards and conventions in the [Style Guide](../contributing/style-guide.md). When documenting code, always follow the documentation standards in [Documentation](../contributing/documentation.md). If either linked file is not available in context, ask the user to provide it before proceeding.
+This is the canonical repository guidance for AI agents and automation tools. Tool-specific files such as `.claude/CLAUDE.md` and `.github/copilot-instructions.md` should stay thin and point back here instead of duplicating policy.
 
-When tasked to refactor code using namespaces, follow these phases in order. In all phases, maintain a **one file per logical module** rule: each .h/.cpp pair produces exactly one corresponding binding file, one C++ test file, and one wasm test file.
+## Start Here
 
-**Phase 1 — Headers and Source**
-Update the .h and .cpp files to reflect the new structure.
+Before changing code, read the relevant project guidance:
 
-**Phase 2 — WebAssembly Bindings**
-For each .h/.cpp pair, create or update exactly one binding file in bindings-wasm/ (one binding file per logical module, matching its .h and .cpp filenames). If no existing binding file exists for a given pair, create one from scratch following the structure used in processHeat/bindings-wasm/.
+- [ARCHITECTURE.md](ARCHITECTURE.md) for repository layout, module boundaries, and the C++ to WebAssembly to TypeScript flow.
+- [BUILD.md](BUILD.md) for build, test, WebAssembly, package, and Docker commands.
+- [contributing/style-guide.md](contributing/style-guide.md) for C++ style and naming.
+- [contributing/documentation.md](contributing/documentation.md) for Doxygen and `.dox` documentation standards.
+- [ts_def/README.md](ts_def/README.md) when adding or correcting TypeScript declarations.
+- [tests/wasm-mocha/README.md](tests/wasm-mocha/README.md) when adding or migrating WebAssembly Mocha tests.
 
-**Phase 3 — C++ Unit Tests**
-Update the .cpp unit tests in tests/cpp to reflect the new structure. Each .cpp file must have its own dedicated test file. If an existing test file covers multiple classes that are being split into separate .cpp files, split the test file accordingly.
+If any referenced file is unavailable in context, ask the user for it before proceeding.
 
-**Phase 4 — WebAssembly Unit Tests**
-Update or add a unit test in tests/wasm-mocha for each binding file (one test file per binding file). Move old unit tests from tests/wasm to tests/wasm-mocha and update them to reflect the new structure. Once a test has been successfully migrated, delete the original file from tests/wasm.
+## Repository Context
 
-**Phase 5 — Documentation**
-Update the documentation in the docs/dox-content directory. Organize the content logically following the pattern that has already been established.
+MEASUR Tools Suite is a C++ calculation library with WebAssembly bindings for browser and Node.js use. The project exposes computational engines for the MEASUR / AMO-Tools-Desktop ecosystem.
 
-**Reference example:** refer to processHeat/ as the canonical example of how to structure the code, WebAssembly bindings, unit tests, and documentation.
+The core development pattern is:
 
-**Checklist (verify before finishing):**
-- [ ] Phase 1: All .h and .cpp files updated
-- [ ] Phase 2: One binding file per .h/.cpp pair; new files created where none existed
-- [ ] Phase 3: One C++ test file per .cpp file; split if needed
-- [ ] Phase 4: One wasm test file per binding file; old tests/wasm files migrated and deleted
-- [ ] Phase 5: Documentation updated and organized
+```text
+include/              public C++ headers
+src/                  C++ implementations
+bindings-wasm/        embind WebAssembly bindings
+ts_def/               TypeScript declaration files for the WASM package
+tests/cpp/            C++ unit tests
+tests/wasm-mocha/     browser-based WebAssembly tests
+docs/dox-content/     calculation documentation
+```
 
-## Context
+## Agent Operating Principles
 
-The MEASUR Tools Suite is a collection of industrial efficiency calculations written in C++ with WebAssembly bindings for browser and Node.js environments. The suite provides computational engines for the [MEASUR](https://github.com/ORNL-AMO/AMO-Tools-Desktop) (Manufacturing Energy Assessment Suite for Utility Reduction) application ecosystem.
+- Prefer small, reviewable changes that preserve existing module boundaries.
+- Read nearby implementation, bindings, declarations, and tests before editing.
+- Keep source, binding, TypeScript declaration, tests, and documentation in sync.
+- Do not invent new abstractions unless they reduce real duplication or match an established local pattern.
+- Preserve public API compatibility unless the user explicitly requests a breaking change. When a breaking change is necessary, document the old-to-new migration.
+- Do not revert or overwrite unrelated user changes in a dirty worktree.
+- Use structured tools and parsers when available. Avoid brittle ad hoc text rewrites for structured data.
+
+## One Module Rule
+
+Maintain one file per logical module whenever refactoring or adding calculations:
+
+- One `.h`/`.cpp` pair for the C++ module.
+- One matching binding file in `bindings-wasm/`.
+- One C++ test file for each C++ module where applicable.
+- One WebAssembly Mocha test file for each binding file.
+- One TypeScript declaration file for each public binding surface.
+- Documentation organized under `docs/dox-content/` following nearby examples.
+
+Use `processHeat/` as the canonical structural example when in doubt.
+
+## Namespace or Module Refactor Phases
+
+When asked to refactor code using namespaces or to split modules, work in this order:
+
+1. **Headers and Source**: Update `.h` and `.cpp` files first.
+2. **WebAssembly Bindings**: Create or update exactly one binding file in `bindings-wasm/` for each logical module.
+3. **C++ Unit Tests**: Update `tests/cpp/`; split tests when one old test covered multiple new modules.
+4. **WebAssembly Unit Tests**: Update or add `tests/wasm-mocha/` tests. Move successfully migrated tests from `tests/wasm/` and delete the obsolete originals.
+5. **TypeScript Declarations**: Update `ts_def/` to match the exact embind runtime surface and follow [ts_def/README.md](ts_def/README.md).
+6. **Documentation**: Update `docs/dox-content/` and related docs if public behavior, formulas, usage, or module organization changed.
+
+## WebAssembly and TypeScript Rules
+
+Match declarations to embind bindings:
+
+- `class_<T>("Name")` is a runtime class. Declare it as `export declare class Name` and include `delete(): void`.
+- `value_object<T>("Name")` is passed as a plain object. Declare it as an `interface`; do not require `delete()`.
+- `register_vector<T>("Name")` is a constructible runtime vector. Expose a constructor through the module type and clean instances up with `delete()`.
+- `enum_<T>("Name")` is a runtime enum. Add it to the module type only when the binding file exposes it.
+- Module types should include runtime properties only. Export type-only interfaces, but do not list them as module properties.
+- Document all public declarations. At minimum, every numeric property, parameter, and return value needs units or explicit dimensionless/unitless status.
+- Prefer importing from the package entrypoint in TypeScript tests:
+
+```ts
+import createModule, { type MeasurToolsSuite } from 'measur-tools-suite';
+```
+
+## Testing Expectations
+
+Choose verification based on the changed surface:
+
+- C++ source or headers: build and run relevant C++ tests.
+- WASM bindings or TypeScript declarations: run `./node_modules/.bin/tsc --noEmit` and relevant `npm run tests`.
+- Browser-facing changes: verify `bin/client.js` and `bin/client.wasm` are built and served correctly.
+- Documentation-only changes: run markdown or whitespace checks when available, and ensure links are correct.
+
+Common commands:
+
+```bash
+cmake -S . -B build-cpp
+cmake --build build-cpp
+./build-cpp/bin/cpp_tests
+emcmake cmake -S . -B build-wasm -DBUILD_WASM=ON
+emmake make -C build-wasm
+./node_modules/.bin/tsc --noEmit
+npm run tests
+git diff --check
+```
+
+Do not claim tests passed unless you ran them. If a command cannot run in the environment, report that plainly with the reason.
+
+## Documentation Expectations
+
+- Use Doxygen comments for public C++ classes, structs, functions, enums, and files.
+- Use `.dox` files for calculation-level documentation aimed at engineering users.
+- Keep formulas, units, and symbol tables consistent with [contributing/documentation.md](contributing/documentation.md).
+- Update examples when public WebAssembly or TypeScript usage changes.
+
+## Completion Checklist
+
+Before handing work back, verify:
+
+- [ ] Source changes match the existing module pattern.
+- [ ] Bindings match headers and runtime names exactly.
+- [ ] TypeScript declarations match embind semantics.
+- [ ] C++ and WASM tests cover the changed public behavior.
+- [ ] Documentation and examples are updated for public changes.
+- [ ] Formatting, whitespace, and generated artifacts are intentional.

package/ARCHITECTURE.md

@@ -1,3 +1,149 @@
 # Architecture Overview
 
-TODO: Add architecture overview content here.
+MEASUR Tools Suite is a layered calculation library. The authoritative calculations are implemented in C++, exposed to browser and Node.js consumers through Emscripten WebAssembly bindings, and described for TypeScript consumers through declaration files.
+
+## Layers
+
+```text
+Engineering formulas and data
+        |
+        v
+Public C++ headers          include/<domain>/
+C++ implementations         src/<domain>/
+C++ tests                   tests/cpp/
+        |
+        v
+WebAssembly bindings        bindings-wasm/<domain>/
+Browser WASM tests          tests/wasm-mocha/<domain>/
+TypeScript declarations     ts_def/ts_def_modules/<domain>/
+        |
+        v
+Package entrypoint          bin/client.js + bin/client.wasm
+TypeScript entrypoint       ts_def/client.d.ts
+```
+
+The public npm package exposes the WebAssembly module factory from `bin/client.js` and TypeScript declarations from `ts_def/client.d.ts`.
+
+## Repository Map
+
+| Path | Purpose |
+| --- | --- |
+| `include/` | Public C++ headers and module contracts. |
+| `src/` | C++ implementations. |
+| `bindings-wasm/` | Emscripten embind bindings that define the JavaScript/WASM runtime API. |
+| `ts_def/` | TypeScript declarations mirroring the runtime API. See [ts_def/README.md](ts_def/README.md). |
+| `tests/cpp/` | Catch2 C++ unit tests. |
+| `tests/wasm-mocha/` | Browser-based Mocha tests for the WebAssembly package. |
+| `tests/wasm/` | Legacy WASM tests; migrate active tests to `tests/wasm-mocha/`. |
+| `docs/dox-content/` | Doxygen calculation documentation for engineering users. |
+| `contributing/` | Style, documentation, formatting, and commit guidance. |
+| `BUILD.md` | Build, test, packaging, WebAssembly, and Docker workflows. |
+| `AGENTS.md` | Canonical guidance for AI agents and automation. |
+
+## Domain Modules
+
+Top-level domains are mirrored across `include/`, `src/`, `bindings-wasm/`, `ts_def/`, and tests where applicable:
+
+- `compressedAir`
+- `databases`
+- `motorDriven`
+- `other`
+- `physics`
+- `processCooling`
+- `processHeat`
+- `steam`
+- `steamModeler`
+- `treasureHunt`
+- `wasteWater`
+- `water`
+
+When adding or refactoring a calculation, keep the same logical module name across layers. For example, a new `src/processHeat/foo.cpp` should have a matching public header, binding file, declaration file, tests, and documentation where appropriate.
+
+## C++ Layer
+
+The C++ layer owns calculation behavior. Headers in `include/` define public data structures and calculator APIs. Implementations in `src/` should follow the project style guide:
+
+- Prefer explicit, named structs for passive data.
+- Use namespaces that match the module path.
+- Keep declarations and implementations paired.
+- Use `const` and references intentionally to avoid unnecessary copies.
+- Include what you use.
+
+Unit tests should exercise formulas and edge cases at the C++ layer when behavior changes independent of WebAssembly.
+
+## WebAssembly Binding Layer
+
+Bindings in `bindings-wasm/` define the JavaScript runtime surface. Treat binding names as public API:
+
+- `class_<T>("Name")` exposes a runtime constructor and embind instance methods.
+- `value_object<T>("Name")` accepts and returns plain JavaScript objects.
+- `register_vector<T>("Name")` exposes a runtime vector with `size()`, `get()`, `push_back()`, and `delete()`.
+- `enum_<T>("Name")` exposes a runtime enum object.
+
+Keep one binding file per logical C++ module. Avoid grouping unrelated modules into one binding file because it makes tests, declarations, and downstream migration harder.
+
+## TypeScript Declaration Layer
+
+Declarations in `ts_def/` describe the WebAssembly runtime API. They should match embind semantics exactly:
+
+- Runtime classes are `export declare class` declarations with `delete(): void`.
+- Value objects are `interface` declarations and should not require cleanup.
+- Registered vectors extend the shared `RegisteredVector<T>` type and are exposed through `RegisteredVectorsModule`.
+- Module type aliases should include only properties that exist on the initialized WebAssembly module.
+- `ts_def/client.d.ts` re-exports all module declarations and defines `MeasurToolsSuite`, the typed initialized module instance.
+
+Declaration comments are part of the public developer experience. Every numeric public property, constructor parameter, function parameter, and numeric return value should document units or explicitly say `dimensionless`, `unitless`, or `count`. Follow [ts_def/README.md](ts_def/README.md) for the full typing documentation checklist.
+
+When a TypeScript test needs casts such as `as any`, check the binding and declaration first; the declaration is often wrong or incomplete.
+
+## WebAssembly Test Layer
+
+`tests/wasm-mocha/` tests run in Karma/Chrome against `bin/client.js` and `bin/client.wasm`. New tests should use the typed package entrypoint:
+
+```ts
+import createModule, { type MeasurToolsSuite } from 'measur-tools-suite';
+```
+
+Follow [tests/wasm-mocha/README.md](tests/wasm-mocha/README.md) for migration details. Clean up embind classes and vectors with `delete()`. Do not call `delete()` on value-object results.
+
+## Documentation Layer
+
+Use Doxygen comments for public C++ APIs and `.dox` files for calculation narratives. Documentation should explain engineering intent, units, formulas, and assumptions, not just repeat code structure.
+
+Follow [contributing/documentation.md](contributing/documentation.md) for Doxygen commands, formula syntax, and symbol tables.
+
+## Build and Packaging
+
+Common build products:
+
+- Native C++ build: `build-cpp/`
+- WebAssembly build: `build-wasm/`
+- Runtime package artifacts: `bin/client.js` and `bin/client.wasm`
+
+Use separate build directories for native and WebAssembly builds to avoid stale CMake cache state. See [BUILD.md](BUILD.md) for full commands.
+
+## Development Workflow
+
+For calculation changes, work from the core outward:
+
+1. Update C++ headers and source.
+2. Update or add C++ tests.
+3. Update WebAssembly bindings.
+4. Update TypeScript declarations.
+5. Update WASM Mocha tests.
+6. Update documentation and examples.
+7. Run the narrowest useful validation first, then broader tests before handoff.
+
+For declaration-only or test migration work, still inspect the matching binding file before changing types. The binding file is the runtime source of truth for TypeScript declarations.
+
+## Validation Matrix
+
+| Change | Minimum validation |
+| --- | --- |
+| C++ formula or data model | Build C++; run relevant `tests/cpp` or `cpp_tests`. |
+| WASM binding | Rebuild WASM; run affected `tests/wasm-mocha` tests. |
+| TypeScript declarations | `./node_modules/.bin/tsc --noEmit`; run affected WASM tests. |
+| Packaging | Build package or inspect packed contents for `client.js`, `client.wasm`, and declarations. |
+| Documentation | Check links, Doxygen syntax, and `git diff --check`. |
+
+Prefer adding focused tests near the changed module instead of relying only on large integration coverage.

package/bin/README.md

@@ -0,0 +1,140 @@
+# TypeScript Declaration Authoring Guide
+
+This directory contains the public TypeScript declarations for the WebAssembly package. Declarations are part of the user-facing API and should be maintained with the same care as C++ headers and embind bindings.
+
+## Source of Truth
+
+Use the matching `bindings-wasm/` file as the runtime source of truth, then use C++ headers, implementations, tests, and docs to fill in semantics and units.
+
+```text
+bindings-wasm/<domain>/<module>.cpp     runtime names and embind kind
+include/<domain>/<module>.h             public C++ inputs, outputs, and units
+src/<domain>/<module>.cpp               formulas and default behavior
+tests/wasm-mocha/<domain>/              expected JavaScript usage
+docs/dox-content/                       calculation intent, equations, and units
+```
+
+Do not add a type because it seems useful downstream unless the initialized WebAssembly module actually exposes that runtime property.
+
+## Required Documentation
+
+Every public declaration file should include:
+
+- A top-level module summary describing the calculator or data group.
+- JSDoc/TSDoc comments for every exported enum, interface, class, and function.
+- Per-member comments for every public property.
+- Constructor parameter comments for every public class constructor.
+- Function `@param` and `@returns` comments for every exported function.
+- Cleanup guidance on embind classes and vectors that require `delete()`.
+
+Comments should explain user-facing meaning, not just restate the property name.
+
+## Units Requirement
+
+At minimum, every numeric property, constructor parameter, function parameter, and numeric return value must document units.
+
+Use one of these forms consistently:
+
+- `units kWh/year`
+- `units degF`
+- `units scfm`
+- `units $/kWh`
+- `dimensionless`
+- `dimensionless, 0-1`
+- `unitless enum`
+- `count`
+
+For booleans, strings, enums, and nested objects, document meaning instead of units. For example, `true when using nameplate data` or `enum selecting the measurement method`.
+
+Do not guess units. If bindings and C++ sources do not make units clear, inspect tests, documentation, and downstream usage. If units still cannot be established, call this out in the PR or handoff and avoid presenting a guessed unit as fact.
+
+## Embind Mapping Rules
+
+Match declarations to embind exactly:
+
+- `class_<T>("Name")`: declare `export declare class Name`. Include constructors, methods, public properties, and `delete(): void`.
+- `value_object<T>("Name")`: declare an `interface`. Use plain object shapes. Do not include `delete(): void`.
+- `register_vector<T>("Name")`: declare an interface extending `RegisteredVector<T>` and expose a constructor in `RegisteredVectorsModule`.
+- `enum_<T>("Name")`: declare an enum and expose it on the module type.
+- `function("name", ...)`: declare an exported function and expose it on the matching module type.
+
+Module type aliases should include only runtime properties that exist on the initialized module: classes, functions, enums, and registered vector constructors. Type-only interfaces should be exported, but should not appear as module properties.
+
+## File Structure
+
+Use this order unless a nearby module has a stronger established pattern:
+
+1. File-level summary.
+2. Imports, using `import type` for type-only imports.
+3. Enums.
+4. Input and output interfaces or classes.
+5. Calculator functions.
+6. Module type alias.
+
+Keep names aligned with embind runtime names. Do not rename declaration symbols independently of the binding surface.
+
+## Example Value Object
+
+```ts
+/**
+ * Input data for pipe sizing.
+ *
+ * @property airflow Airflow through the pipe, units scfm
+ * @property airlinePressure Airline pressure, units psig
+ * @property designVelocity Target design velocity, units ft/s
+ * @property atmosphericPressure Atmospheric pressure, units psia
+ */
+export interface PipeSizingInput {
+    /** Airflow through the pipe, units scfm */
+    airflow: number;
+    /** Airline pressure, units psig */
+    airlinePressure: number;
+    /** Target design velocity, units ft/s */
+    designVelocity: number;
+    /** Atmospheric pressure, units psia */
+    atmosphericPressure: number;
+}
+```
+
+Because this is a `value_object`, callers pass a plain object and do not call `delete()`.
+
+## Example Runtime Class
+
+```ts
+/**
+ * Dryer operating cost calculator.
+ */
+export declare class DryerOperatingCost {
+    /**
+     * @param airflow Dryer airflow, units scfm
+     * @param inletPressure Inlet pressure, units psig
+     * @param averageSystemDemand Average system demand, units %
+     */
+    constructor(airflow: number, inletPressure: number, averageSystemDemand: number);
+
+    /**
+     * Calculate dryer operating cost for the selected dryer type.
+     * @param dryerType Dryer type enum.
+     * @returns Annual dryer operating cost results.
+     */
+    calculate(dryerType: DryerType): DryerOperatingCostOutput;
+
+    /** Frees the underlying embind resource. Call when finished with the instance. */
+    delete(): void;
+}
+```
+
+Because this is a `class_`, callers must clean up instances and class outputs with `delete()`.
+
+## Validation Checklist
+
+Before finishing declaration work:
+
+- [ ] The matching `bindings-wasm/` file was inspected.
+- [ ] Each runtime class, function, enum, and vector is present in the module type.
+- [ ] Type-only interfaces are not listed as runtime module properties.
+- [ ] Every numeric public field, parameter, and return documents units or dimensionless status.
+- [ ] Cleanup requirements match embind semantics.
+- [ ] `ts_def/client.d.ts` exports the new declaration file and includes its module type in `MeasurToolsSuite`.
+- [ ] A typed WASM Mocha test exercises the declaration through `createModule`.
+- [ ] `./node_modules/.bin/tsc --noEmit` passes.

package/bin/package.json

@@ -1,6 +1,6 @@
 {
   "name": "measur-tools-suite",
-  "version": "1.2.1-beta.4",
+  "version": "1.2.1-beta.5",
   "engines": {
     "node": "20.19.4",
     "npm": "10.8.2"

package/bin/ts_def_modules/binding/registered_vectors.d.ts

@@ -27,12 +27,12 @@ export declare abstract class RegisteredVector<T> {
     /** Constructor for creating an array of elements of type <T> */
     constructor();
 
-    /** Returns the number of elements or size or length */
+    /** @returns Vector size, count. */
     size(): number;
 
     /**
      * Resizes and adds x elements of <T>
-     * @param size new size of the vector
+     * @param size new vector size, count
      * @param elementOfTypeT element of type <T> to add if the vector is resized to be larger than the current size; optional parameter, default value is determined by the implementation
      */
     resize(size: number, elementOfTypeT?: T): void;