Not sure how this got mangled during the port from wildfly-clustering-common, but AddResourceOperationStepHandler should be verifying that the OperationStepHandler of the parent resource's add operation implements DescribedOperationStepHandler, not AddResourceOperationStepHandlerDescriptor.
This affects the ability of the add operation to act as a replace operation.

The general issue is:

If a ResourceDescriptor of some resource defines any require child resources (or required singleton child resources), then its add operation will auto-create add operation for the required child resources. Add operations for required child resources (or singleton child resources) are meant to behave as a replace operation.
This was implemented in wildfly-clustering-common and is utilised in a number of subsystems.
While migrating these subsystem to wildfly-subsystem, I noticed that the second part was not happening correctly (somewhere, in the renaming of classes, this got botched).

For example:

• /subsystem=distributable-web/infinispan-session-management=foo:add(...) will automatically add an affinity=primary-owner child resource if it is missing, since its ResourceDescriptor defines this as one of its required singleton children.
• If a subsubsequent add operation arrives for the same resource type, e.g. /subsystem=distributable-web/infinispan-session-management=foo/affinity=ranked:add(...), then the existing affinity=primary-owner child (added in the previous step) is meant to be auto-removed prior to executing the add operation.