Zum Hauptinhalt springen
VelinStyle v1.4.0
⌂ Home

Migration Intelligence 1.4.0

Migration Intelligence analysiert Migrationen zuerst, strukturiert fachliche Entscheidungen und lässt Residual-Änderungen nur zu, wenn ein eindeutiges Mapping vorliegt. English: Migration Intelligence

Sicherheitsgrenze: Im aktuellen Pilot gibt es 0 freigegebene Residual- source→target-Mappings. Deshalb SAFE_REWRITE = 0. v1.4.0 erfindet keine Rewrite-Ziele. Das ist Absicht — kein fehlendes Feature.
Nicht dasselbe wie Design Intelligence. Design Intelligence ist eine separate Produktfläche. Migration Intelligence liegt unter .velin/migration/intelligence/ nach velinstyle migrate tailwind.

Status v1.4.0

Migration Intelligence ist dokumentarisch und technisch vorbereitet. Residual-Mappings besitzen derzeit keine fachlich freigegebenen source→target-Paare. Deshalb:

FlächeWert
Catalog Entries0 (catalogVersion: 0.0.0-empty)
Manifest Entries0
SAFE_REWRITE0
Apply-Kandidaten0
THEME_CATALOG_READY0 (16 Sources geprüft, 16 nicht freigegeben)
PALETTE_CATALOG_READY0 (39 Sources geprüft, 39 nicht freigegeben)

Das ist ein bewusstes Sicherheitsresultat — kein fehlender Implementierungsstatus. Schichten bleiben getrennt: Policy · Strategy · Acceptance · Catalog · Manifest · Apply.

Pipeline

Analysis (Classifier)
→ Groups
→ Decision Clusters
→ Policy
→ Strategy Blocks
→ User Actions
→ Acceptance (+ persistence)
→ Rewrite Catalog (fachlich)
→ Rewrite Manifest
→ Apply-Gate Preflight
→ Dry-Run
→ Apply (+ Snapshot / Rollback)

Harte Trennungen

AussageBedeutung
Analyse ≠ AcceptanceReports erklären Residuals; Acceptance speichert Entscheidungen
Acceptance ≠ MappingStrategie-Optionen sind keine Token-Targets
Mapping ≠ ManifestCatalog ist fachlich; Manifest ergänzt file/hash/occurrence
Manifest ≠ ApplyApply braucht GATE_READY + DRY_RUN_OK
ACCEPTED ≠ APPLIEDapplied bleibt false bis Apply Write erfolgreich ist
Enrichment ≠ RewriteStrategy Blocks spiegeln Policies; sie schreiben keine Sources um

Pilot-Metriken (unverändert durch Intelligence)

MetrikWert
User Actions23 (1 clear · 18 fachlich · 4 info)
Strategy Blocks6/6 enriched
Rewrite Catalog entries0 (0.0.0-empty)
Manifest entries0
SAFE_REWRITE0
Apply-Kandidaten0
Coverage806 / 559 / 74 / 173 / 69.4% / 351
Tests (Intelligence + migrate CLI)94 (41 intelligence · 53 cli-migrate)
Tests (+ release-sync)102 (+ 8 release-sync)

Sechs Strategy Blocks

Alle Blocks sind aus bestehenden Decision Policies enriched. safeMappingExists ist für jeden Block false. Enrichment erzeugt keine Mappings.

THEME

STATE

HALF_STEP

PALETTE

DIM_PX

TYPO

Acceptance (Akzeptanz)

Store: .velin/migration/intelligence/acceptance.json · schemaVersion: 1

Acceptance speichert Entwicklerentscheidungen, aber keine Rewrite-Ziele. Statuswerte: OPEN · ACCEPTED · DEFERRED.

CLI: velinstyle migrate acceptance <project> --show · --ua …

FeldRolle
userActionId / actionKeyStabile Resume-Keys
selectedOptionIdGewählte Strategie-Option (A/B/C…)
statusOPEN · ACCEPTED · DEFERRED
decisionStatusSpiegelt Policy-Review (z. B. NEEDS_POLICY · REVIEW)
acceptanceKindz. B. CHOSE_OPTION
decidedAt / user / noteAudit-Trail
caseRefs / groupRefsVerknüpfte Cases/Groups
coverageSnapshotCoverage zum Entscheidungszeitpunkt
appliedImmer false, bis Apply Write erfolgreich ist

Queue Drift / Orphans werden beim Laden gemeldet; Resume über userActionId, dann actionKey. Acceptance schreibt keine Sources um. ACCEPTED ≠ APPLIED.

Rewrite Catalog (fachlich)

Rewrite Manifest

Separate Datei: rewrite-manifest.json (nicht Acceptance). Pilot: 0 produktive Entries.

Apply-Gate → Dry-Run → Apply

Load → Validate → Acceptance → Path → Target → MappingSource
→ Hash → TOCTOU → Conflict → Occurrence → Snapshot-Preflight
→ GATE_READY

Then:
Dry-Run → re-check Gate → Snapshot → TOCTOU → Write
→ Rollback on failure → applied:true only after success
velinstyle migrate acceptance ./my-project --show
velinstyle migrate rewrite-manifest ./my-project --preflight
velinstyle migrate rewrite-manifest ./my-project --dry-run
# --apply only with GATE_READY + DRY_RUN_OK and explicit mappings

Bewusste Nicht-Ziele in 1.4.0

Spätere Versionen

Erst nach expliziter Design/Dev-Catalog-Zeile: Manifest --add → Preflight → Dry-Run-Review → Apply.

Historische Phase-Dokumente beschreiben den jeweiligen Entwicklungsstand und wurden nachträglich nicht umgeschrieben.