Schema & Custom Fields

The structure of your test cases - which fields exist, their types, options, and constraints - is fully customizable and lives in .tms/schema.yaml, versioned in git alongside the cases.

#Field types

Eight types cover the common needs:

text · textarea · select · multiselect · number · date · checkbox · url

Each field has a key (an immutable identifier), a display name, a type, and optional required, default, description, options (for select/multiselect), and order.

#System fields are part of the schema

As of the v2 schema format, the built-in fields - priority, status, tags, preconditions - are no longer hard-coded. They appear in the schema marked system: true, which means you can:

• retype them (e.g. change the set of status options),
• reorder them among your custom fields,
• mark them not-required,

…the same way you'd edit a custom field. Tools, the CLI, and the case form all introspect the one schema, so the structure is consistent everywhere.

#The split-screen Structure designer

Settings → Structure (and an onboarding step) opens a split-screen editor:

• Left pane - the field definitions: system + custom fields, each with type, required flag, constraints, and order. Drag to reorder, edit inline.
• Right pane - a live preview of a sample case rendered under the draft schema, updating in real time as you edit. Nothing is written to disk until you apply.

There's also a diff mode so you can see exactly what your changes do before committing them.

#Seeding a schema from a sample

Starting from scratch? Upload a sample case - a Kensa .md file or a CSV exported from another test tool - and the designer infers field suggestions: it detects custom-field keys and guesses their type (text, number, date, or enum-candidate). Suggestions arrive as editable proposals you refine before applying, and merge/dedupe against any fields you already have.

#Versioned, non-destructive migrations

Changing the schema (including upgrading an old v1 project to v2) runs through a migration engine with strong safety guarantees:

• Backup first. Every affected case is copied to .tms/trash/ before any change is applied, so you can always recover.
• Non-destructive. Legacy values that fall outside a new set of options are preserved with a warning, never silently dropped.
• Idempotent. Re-running a migration on an already-migrated project is a safe no-op.

#Migration preview

Before applying, a preview dialog shows:

• how many cases are affected,
• any lossy warnings (e.g. "3 cases have priority values outside the new schema"), and
• a detailed diff of the first affected case.

You confirm or cancel with zero changes on cancel.

#Editing simple field definitions

A simpler Test Cases settings tab (formerly "Fields") lets you add / edit / delete individual custom fields directly:

• field key is validated (^[a-z][a-z0-9_]*$) and immutable after creation;
• options for select/multiselect are entered one-per-line;
• changing a field's type drops now-irrelevant options and resets incompatible defaults;
• deleting a field is non-destructive - existing case values become preserved legacy data.

#CLI parity

The Rust kensa CLI implements the same v2 schema and 1→2 migration byte-for-byte. kensa schema migrate performs the real versioned migration from the command line.