product: assert audience: test-developer authority: normative

Package Structure

Directory layout

{package-name}/
├── package.json              ← Package manifest (required)
├── README.md                 ← Package documentation (recommended)
├── validate.py               ← Two-level YAML validation script
├── .vscode/
│   └── settings.json         ← VS Code YAML schema wiring
├── docs/                     ← Assert documentation (this folder)
│   └── Accordion/            ← Accordion hardware docs (if applicable)
├── tests/
│   ├── my-test.yaml          ← YAML test definitions
│   └── sub-sequence.yaml     ← Reusable sequences
├── assemblies/               ← .NET test DLLs (optional)
│   └── MyTests.dll
├── python_modules/           ← Python test scripts (optional)
│   └── my_instruments.py
├── wheels/                   ← Vendored pip wheels for offline install (optional)
│   └── requests-2.32.3-py3-none-any.whl
└── data/                     ← Supporting files (optional)
    ├── calibration.bin
    └── config.json

package.json schema

{
  "name": "my-package-name",
  "version": "1.0.0",
  "author": "Author Name",
  "authorEmail": "author@example.com",
  "description": "Short description",
  "lifecycleStatus": "NotReleased",
  "supportedProductIds": ["PCB-100"],
  "publishedDate": "2025-01-15T00:00:00Z",
  "requirements": {}
}

requirements fields

pipPackages drives automatic installation. For production (air-gapped) stations, vendor wheel files in wheels/ — see sdk/python-dependencies.md.

Supporting files (data/ directory)

Place calibration tables, firmware images, lookup files, certificates, or any other non-code supporting files in data/.

Do not use paths relative to the working directory. The working directory during a step is the runner's own directory, not your package. The runners are long-lived services shared by every execution on the station, so there is no per-step current directory they can safely change. Ask for the package root instead.

.NET — declare a packageRoot parameter

A step method that declares a string packageRoot parameter is handed the absolute path of its own package, with no YAML wiring:

public static NumericMeasurementPoint MeasureGain(string packageRoot)
{
    var calPath = Path.Combine(packageRoot, "data", "calibration.bin");
    // ...
}

The value is resolved per execution from the step's own assembly, so a sequence that spans packages gives each step the root of its package. An explicit parameters: entry or a variable of the same name still wins, if you need to point a step somewhere else.

YAML / Python — use {{package.root}}

The package root is also published as the variable {{package.root}}, so it can be passed to any runner as a normal parameter:

- name: Load calibration
  module: cal
  function: load
  parameters:
    cal_path: "{{package.root}}/data/calibration.bin"

# Python
def load(cal_path):
    ...

MUST NOT use absolute paths or Assembly.Location — the package may be deployed to different directories, and Assembly.Location breaks the moment assemblies are loaded from anywhere but the package.

Test file discovery

The engine automatically discovers all *.yaml / *.yml files inside the installed package directory. You DO NOT need to list test files anywhere — place them under tests/.

VS Code authoring setup

Every scaffolded package includes files for zero-setup authoring support:

Install the redhat.vscode-yaml extension, then open the package folder as a workspace root (File → Open Folder).

Two validation levels

tat-test-schema.json and validate.py are read-only reference files — DO NOT edit them. They are updated and re-copied with each TAT platform release.