Skip to content
sdlc

B-U6ZY-new-task-ts-scaffolds-tasks-at-stale-schema-version-task-tem

Status: promoted/task

The new_*.ts scaffold scripts hardcode or copy values that the entity schema.json already declares, so a schema change silently drifts the scaffolders. This is a recurrence in the TS substrate of the problem T-ZU6V-new-scripts-derive-patterns-from-schema closed for the old Python scripts (#59 — regex patterns): the en-masse TS port (M0002) did not carry the schema-derivation forward, and it has now bitten two more fields.

Examples observed (both 2026-06-02):

  1. schema_version — new_task.ts. Scaffolds from plugin/lib/model/entities/task/template.md, whose frontmatter pins schema_version: '3' while the task schema is at version 5. Every new task is born schema-drifted (created at v3). Hit while scaffolding the autonomy-auto-define task (hand-bumped to v5).
  2. status enum — new_standard.ts. --status offers only active/superseded/deprecated and writes the bare value status: active, which is not in the schema enum (open/draft/open/proposed/open/active/closed/...). It cannot create a draft or proposed standard, and the value it does write fails schema validation. Hit while drafting S0006 (hand-fixed to open/draft).

Fix direction (same as #59): each new_*.ts derives its schema-bound values from schema.json at startup rather than hardcoding or copying a frozen template — the current schema_version from the schema’s version, the --status choices from the schema’s status enum (patterns as #59 already did). Add a project-check that asserts each entity’s template.md frontmatter schema_version equals its schema.json version, and that each scaffolder’s choice lists are subsets of the schema enums — so the next schema bump can’t silently re-introduce the drift.

Related: T-ZU6V-new-scripts-derive-patterns-from-schema (#59 — the Python-era fix the TS port regressed).

← Back to Backlog