While fixing a duplicate-generation problem in v3 (#3733), we found that the DirectoryObjects entry in config/ModulesMapping.jsonc on main still claimsdirectory.publicKeyInfrastructureRoot, but the module never actually ships that surface. The cmdlets get generated and then deleted again by 17 remove directives in src/DirectoryObjects/DirectoryObjects.md. The real owner is identity.DirectoryManagement - it has all 18 publicKeyInfrastructure files on main across v1.0 and beta, and every v1.0 row in MgCommandMetadata.json points there.
So today the tag just creates work that directives throw away, and the mapping says the wrong module owns the surface. v3 already removed the tag on its side; this issue is to do the same on v2, per the review discussion on #3733.
Suggested fix:
- Remove directory.publicKeyInfrastructureRoot from the DirectoryObjects entry in config/ModulesMapping.jsonc.
- Delete the 17 dead PublicKeyInfrastructure remove directives from src/DirectoryObjects/DirectoryObjects.md.
- Regenerate DirectoryObjects - the diff should be empty apart from the directives, which confirms the tag was producing nothing.
While fixing a duplicate-generation problem in v3 (#3733), we found that the DirectoryObjects entry in config/ModulesMapping.jsonc on main still claimsdirectory.publicKeyInfrastructureRoot, but the module never actually ships that surface. The cmdlets get generated and then deleted again by 17 remove directives in src/DirectoryObjects/DirectoryObjects.md. The real owner is identity.DirectoryManagement - it has all 18 publicKeyInfrastructure files on main across v1.0 and beta, and every v1.0 row in MgCommandMetadata.json points there.
So today the tag just creates work that directives throw away, and the mapping says the wrong module owns the surface. v3 already removed the tag on its side; this issue is to do the same on v2, per the review discussion on #3733.
Suggested fix: