open-index/open-npm huggingface dataset:
npm package: @qckfx/schema
Description: This package bundles the **versioned** Zod schema used for **Trigger configuration files** (e.g. `.qckfx/triggers/*.json`). It mirrors the layout & approach used by the agent schema package so maintainers can follow the same workflow.
Latest version: 0.0.4

# Trigger Schema Package

This package bundles the **versioned** Zod schema used for **Trigger
configuration files** (e.g. `.qckfx/triggers/*.json`). It mirrors the layout &
approach used by the agent schema package so maintainers can follow the same
workflow.

## Version folders

* `src/v1/` – schema version **1.0** (current latest).

Each version folder contains:

1. `trigger.ts` – Zod schema exported as `TriggerSchemaV1` plus its TypeScript
   type `TriggerV1`.
2. `migrate.ts` (optional) – functions that upgrade the parsed object to the
   latest canonical representation. For v1 it is an identity function.

## Registry & helpers

`src/index.ts` maintains a registry mapping version string → { schema, upgrade
fn }. The helper `parseTriggerConfig()`:

1. Extracts the version from the config’s `$schema` URL or string.
2. Removes `$schema` (root schemas are strict).
3. Validates via the correct Zod schema.
4. Applies the upgrade function so callers always receive the **latest**
   structure.

## Adding a new version

1. Create `src/vX.Y/trigger.ts` with the updated Zod schema.
2. Provide `upgradeVXYToLatest()` migration.
3. Register it in `src/index.ts` and bump `SCHEMA_VERSION_LATEST` plus the
   exported `Trigger` type alias.
4. Add unit tests.

That’s it – the server code keeps using `parseTriggerConfig()` or (for backward
compat) `TriggerSchema.parse()`.
npm package: @qckfx/sdk-schema
Description: qckfx Agent configuration schema and validation utilities (stand-alone).
Latest version: 1.0.1

# Agent SDK – Schema Package

This sub-package contains **only** the versioned JSON/Zod schema for agent
configuration files. It is intentionally kept lightweight so that users who
just want to validate a `agent.json` file do **not** have to depend on the
runtime SDK.

## Versioning strategy

1.  **One folder per major schema version** (`src/v<major>.<minor>`).
    _Version 1.0_ lives in `src/v1/`.

2.  Each folder exposes:

    - `agent.ts` – Zod schema (strict **+** `.strip()` to silently discard
      unknown keys like `$schema`). Exported as `AgentConfigSchemaV1`.
    - `migrate.ts` _(optional)_ – functions that upgrade that version to the
      latest representation.

3.  `src/index.ts` keeps a **registry**

    ```ts
    const schemaRegistry = {
      '1.0': { schema: AgentConfigSchemaV1, upgrade: upgradeV1ToLatest },
      // add new versions here
    };
    ```

4.  The helper `parseAgentConfig()`
    - reads the `$schema` value (if any) and extracts the version,
    - picks the matching entry from the registry (falls back to latest),
    - removes the `$schema` key, validates via Zod, then applies the upgrade
      function so callers always receive the **latest** type (`AgentConfig`).

## Adding a new version (check-list)

1. Copy the previous schema folder to `src/vX.Y` and adjust fields.
2. Export it as `AgentConfigSchemaVXY` and `AgentConfigVXY`.
3. Provide an `upgradeVXYToLatest()` that converts the parsed object to the
   current latest structure.
4. Update `schemaRegistry` in `src/index.ts`:

   ```ts
   schemaRegistry['X.Y'] = { schema: AgentConfigSchemaVXY, upgrade: upgradeVXYToLatest };

   export const SCHEMA_VERSION_LATEST = 'X.Y';
   export type AgentConfig = AgentConfigVXY; // new canonical type
   ```

5. Add unit tests that parse a sample `vX.Y` file and assert correctness.

Following this checklist keeps runtime code unchanged while permitting
backwards-compatible evolution of the configuration format.