10. Migration to v1.0-draft¶

For teams that already managed requirements "their own way" or on early RENAR drafts. The goal is no big-bang: preserve immutable IDs, replace deprecated constructs, and issue a new conformance manifest. The normative basis — standard/04 §4.14, CHANGELOG §Migration.

Do not confuse this with 02-transition-guide — that covers a staged entry into RENAR-1..5 from scratch; here we deal with a breaking rename and schema alignment when moving to the current edition of the standard.

1. When this migration is needed¶

Situation	Action
A project with no RENAR, but with a TZ + Jira	First 02-transition-guide, not this document
Files with `INT-SR`, `INT-TC`, `AIC`, `UIC`, `TS`	This guide
`verifies[].version` without `requirement-version`	Update the TC frontmatter (reference/02 §8)
Manifest `renar-version: 0.1-draft` or absent	Issue a new manifest (reference/08)

2. Type-replacement table (closed list, v1.0-draft)¶

Deprecated	Canonical	Migration step
`INT-SR`	`SR` + `constrained-by: [SPEC-INT-N]`	Rename the type; create / bind a SPEC-INT
`INT-TC`	`TC` + `tc-type: contract`	Add `type: TC`, `tc-type: contract`
`AIC`	`SPEC-AI`	Move the body into the SPEC-AI frontmatter
`UIC`	`SPEC-UI`	Move baselines into `specs/ui/baselines/`
`TS`	`SPEC-ARCH` or `SPEC-OPS`	By content (architecture vs ops runbook)
`TM` (module SR type)	`SR` + `level: module`	Drop the pseudo-type; set the level

Do not change IDs. If a filename contains a legacy prefix, a legacy-id field in the frontmatter is acceptable (informative traceability).

3. Step-by-step plan (1–2 sprints)¶

Phase A — inventory (1–2 days)¶

grep / search across the substrate: INT-SR, INT-TC, AIC, UIC, type: system (the erroneous TC type).
List the artifacts with broken verifies / missing source.adapt.
Record the current RENAR-CONFORMANCE.yaml (if any) as the baseline state.

Phase B — schema pass (3–5 days)¶

Batch-rename the types per the §14 table (one PR per type, or one atomic change-set per delta-TZ).
TC: type: TC, tc-type, verifies[].requirement-version, last-run.requirement-version.
SR: constrained-by[] on every SPEC in use.
BR: source.adapt on the approved ADAPT.

Phase C — validation (1–2 days)¶

Substrate hooks / CI: the frontmatter validator (reference/02).
Run the TCs; update last-run.
Self-assessment checklist — reference/08 §14.

Phase D — manifest (1 day)¶

Bump renar-version: "1.0-draft".
Increment manifest-version; new manifest-id.
Signature of the Architect / Tech Lead (V6).

4. Common pitfalls¶

Mistake	Consequence	Fix
Renaming `SR-05` → `SR-05-v2`	V1 immutable-ID violation	`deprecated` + a new ID with `replaces`
Leaving `type: system` on a TC	Validator fail; KG drift	`type: TC` + `tc-type: system`
Migrating code before the `.req`	SoT inversion violated	First the SR/SPEC/TC approved, then the TR
Skipping ADAPT "only for new TZs"	Non-conformant for legacy TZ	A retrospective ADAPT for every active TZ

5. Rollback¶

The migration runs through the substrate history (V1). Rollback means reverting the change-set / PR, not deleting artifacts. Deprecated artifacts remain with status: deprecated for audit.

Document	Why
02-transition-guide	RENAR-1..5 without schema breaking changes
09-worked-examples	Reference frontmatter after migration
reference/07	External ISO 29148 statement
standard/13 §13.7	Re-assessment after migration

RENAR Guide 1.0-draft — renar.tech