Inspect generated state

Inspect the two state files that explain what Divekit actually recorded after rollout.

This lesson is not about hunting for errors. It is about genuinely understanding your first rollout: which repository got which variant, where on GitLab each repository landed, who was assigned — and that everyone has exactly the intended permissions.

The state files and a look into GitLab tell that story together.

The two most important generated files

After distribution, inspect:

.divekit/distributions/M0/individuals.json
.divekit/distributions/M0/remotes.json

Member input is stored separately in your user-level Divekit directory (~/.divekit/members/) and referenced from config.json. For this beginner lesson, the inspection focus is individuals.json and remotes.json.

What to inspect

What to inspect in individuals.json

Ask:

• does every generated UUID appear here?
• does each UUID have a concrete selection?
• do the selected options match the possibilities from individualization.json?

This file tells you whether the individualization logic actually produced concrete results.

Example shape:

{
  "version": "2.0",
  "individuals": [
    {
      "uuid": "b8520e99-2bad-c0de-b61c-1249a10f7a5a",
      "selection": {
        "objects": {
          "Vehicle": "Car"
        },
        "relations": {},
        "logic": {}
      }
    },
    {
      "uuid": "a70decaf-bad7-4c95-b211-d0bc95f48204",
      "selection": {
        "objects": {
          "Vehicle": "Bike"
        },
        "relations": {},
        "logic": {}
      }
    }
  ]
}

What to inspect in remotes.json

Ask:

• does every expected UUID appear here?
• does each UUID map to a created remote repository?
• does the remote state look complete enough for follow-up commands?

This file tells you how Divekit recorded the remote result operationally.
project_path and web_url answer the “where did it land?” question precisely — depending on the setup that can also be a subgroup of your target group, so this is the quickest way to locate every generated repository.

Example shape:

{
  "targets": {
    "work": {
      "remotes": [
        {
          "uuid": "b8520e99-2bad-c0de-b61c-1249a10f7a5a",
          "project_id": 1234,
          "project_path": "your-group/M0-b8520e99-2bad-c0de-b61c-1249a10f7a5a",
          "web_url": "https://gitlab.git.nrw/your-group/M0-b8520e99-2bad-c0de-b61c-1249a10f7a5a",
          "pages_url": "https://m0-b8520e99-2bad-c0de-b61c-1249a10f7a5a-3f9a1c.pages.git.nrw"
        },
        {
          "uuid": "a70decaf-bad7-4c95-b211-d0bc95f48204",
          "project_id": 1235,
          "project_path": "your-group/M0-a70decaf-bad7-4c95-b211-d0bc95f48204",
          "web_url": "https://gitlab.git.nrw/your-group/M0-a70decaf-bad7-4c95-b211-d0bc95f48204",
          "pages_url": "https://m0-a70decaf-bad7-4c95-b211-d0bc95f48204-c6de4c.pages.git.nrw"
        }
      ]
    }
  }
}

Useful inspection command

Run:

divekit overview -d M0

This command helps you compare:

• generated state
• higher-level repository overview
• visible GitLab result

If the comparison shows something unexpected, do not start fixing anything yet — the next lesson gives you a clear troubleshooting order for exactly that case.

Quick verification in GitLab

Open the target GitLab group and confirm:

• the repositories exist where you expect them — compare with project_path from remotes.json
• repository names include the visible UUIDs
• the expected members were assigned

Then open the member list of one repository (Manage → Members) and check the role.
In this course it should be reporter — read access, nothing more. That members have exactly the intended permission level, and not a higher one, is part of a correct rollout.

See the individualization

This is the moment the whole workflow was building towards.

Open the src/ folder of both generated repositories and compare them:

• one repository contains, for example, Car.java with public class Car
• the other contains Bike.java with public class Bike

One origin produced different, internally consistent repositories — and individuals.json recorded exactly which repository got which variant.

The variant per repository is chosen randomly, so with only three options two repositories can also receive the same vehicle.
That is not an error: individuals.json is the authoritative record of what each repository got.

Check

After the first real distribution, complete all of the following:

1. open individuals.json
2. open remotes.json
3. run divekit overview -d M0