Consistency between state, phase and phaseStatus

After using kogito-runtimes and the data-index, etc., I have seen this potential inconsistency that I'd like to remark for reviewing/investigation:

In general, at the kogito-api we have the following definitions:

At the "process" level we have:

	org.kie.kogito.process.WorkItem {
	    int getState();
    	    String getPhase();
	    String getPhaseStatus();
	}

And at the "runtime" level we have:

	org.kie.api.runtime.process.WorkItem {
	    int getState();
    	    String getPhase();
	    String getPhaseStatus();
	}

All right, both things are consistent.

Imagine that we have a hello world process "CreateClient" and we create an instance of this process that has a "CompleteInfo" human task.

When we execute the corresponding REST api for getting the tasks for a given process instanceId we typically get the following result:

GET /CreateClient/{id}/tasks

  {
    "id": "7fd89562-c9f2-499a-80eb-9ec4b56b77f3",
    "nodeInstanceId": "b81f5389-6da8-456a-878e-214f84991b95",
    "name": "CompleteInfo",
    "state": 0,                             //all right, is consistent with the API
    "phase": "active",               //idem
    "phaseStatus": "Ready",   //idem
    "parameters": { no matter  },
    "results": { no matter }
  }

However when we execute the UserTasksInstances query at the data-index for the same process instance, etc. We get the following information instead:

      {
        "id": "7fd89562-c9f2-499a-80eb-9ec4b56b77f3",
        "name": "CompleteInfo",
        "state": "Completed"    //not consistent with the API
      },

I believe this doesn't look consistent. See that:

1) we query the same human task instance and get different values for the same "state field"
2) but also as part of "kogito" we somehow expose the LifeCycle API, since we let users for example define customized life-cycles, etc. So a potential user that tunes/provides
it's own LifeCycle would want to see both the "phase" and the "phaseStatus" for the
phases it created, etc.

I believe that for having a cross consistency, the data-index should expose the following information instead:

"state": 0
"phase": "active"
"phaseStatus": "Ready"

If for some reason, it's not possible to change, or this kind of "renaming" is intentionally
for hiding the real kind of internal state, I believe it still makes sense to expose the "phase" at the data-index level. Since as I commented above we somehow give the chance to uses to provide their own tuned LiveCyles. And thus, I'll be very helpful to see the phase at the data index level too, etc.

I believe one of the following two actions should be taken:

1) consistent with the API exposure

"state": 0
"phase": "active"
"phaseStatus": "Ready"

2) expose
"phase": "active"
"state": "Ready"

WDYT cnicolai@redhat.com ?