version-migration

Feature: Version Migration Overview Migrate pre-1.0 RoleX data to the current version. The old format stores data as Gherkin feature files in ~/.rolex/. The new format uses a structured graph via RoleX runtime commands.

Scenario: When to use this skill Given a user mentions migrating from an old RoleX version Or a user has data in ~/.rolex that needs to be brought forward When they want to preserve their roles, organizations, and knowledge Then load this skill and follow the migration process

Scenario: Migration is non-destructive Given the old data lives in ~/.rolex When migration runs Then old files are only read, never modified or deleted And new entities are created in the current RoleX runtime And the user can verify before cleaning up old data

Feature: Legacy Data Format (pre-1.0) Understanding the old directory structure and file conventions.

Scenario: Root directory structure Given the legacy data lives at ~/.rolex/ Then the structure is: """ ~/.rolex/ ├── rolex.json # Root manifest ├── .seed-version # Version string (e.g. "0.11.0") └── roles/ ├── / │ ├── identity/ │ │ ├── persona.identity.feature # Who this role is │ │ └── *.knowledge.identity.feature # Knowledge files │ └── goals/ # Goal files (if any) └── / └── ... """

Scenario: rolex.json manifest Given rolex.json is the root manifest Then it contains: """ { "roles": ["nuwa", "waiter"], // List of role names "organizations": {}, // Organization definitions "assignments": {} // Role-to-org assignments } """ And roles array lists all individuals to migrate And organizations object may contain org definitions with charters And assignments object may contain role-to-position mappings

Scenario: Persona files Given a file named persona.identity.feature exists per role Then it contains a Gherkin Feature defining who the role is And the Feature title is the role's name And Scenarios describe personality, thinking style, and behavior And this maps to the individual's identity content in new format

Scenario: Knowledge files Given files named *.knowledge.identity.feature exist per role Then each file contains a Gherkin Feature with domain knowledge And the filename prefix (before .knowledge) is the knowledge topic And these map to principles (teach) in the new format And the knowledge id is derived from the filename prefix

Scenario: Goal files Given a goals/ directory may exist per role Then it may contain Gherkin files representing active goals And goals can be recreated via want in the new format And goals are optional — many roles have empty goals directories

Feature: Migration Process Step-by-step process to migrate legacy data.

Scenario: Step 1 — Scan and analyze Given the user wants to migrate When you begin the migration process Then read ~/.rolex/rolex.json to get the manifest And list all roles from the roles array And for each role, read all files under identity/ and goals/ And present a summary to the user: """ Found X roles to migrate: - : persona + N knowledge files + M goals - : persona + N knowledge files + M goals

  Organizations: X
  Assignments: X
  """
And ask the user to confirm before proceeding

Scenario: Step 2 — Migrate individuals Given the user confirmed migration When migrating each role from the manifest Then for each role: """ 1. Read persona.identity.feature → use as born content 2. locator: "!individual.born" args: id: "" content: "" """ And the role-name from the directory becomes the individual id