Consolidate PSModule documentation into Process-PSModule and retire PSModule/docs #423

PSModule/docs currently contains Process-PSModule behavior documentation, while PSModule/Process-PSModule contains the actual workflows and actions. This split causes drift risk and slows changes because behavior and implementation are maintained in separate repositories.

Request

Consolidate Process-PSModule documentation and workflow guidance into PSModule/Process-PSModule, then retire PSModule/docs after migration gates are complete.

Desired experience

• Process-PSModule behavior, standards, and operational guidance live next to the implementation.
• Documentation updates for Process-PSModule are made in one repository with one review path.
• Existing open work in PSModule/docs is preserved and moved without losing traceability.

Acceptance criteria

• All open PRs in PSModule/docs are merged or explicitly resolved before migration lock.
• All relevant open issues in PSModule/docs are transferred to Process-PSModule with preserved links.
• Process-PSModule documentation source-of-truth content is migrated into Process-PSModule.
• Process-PSModule publish/release decision design (artifact checksum model) is tracked in Process-PSModule issue hierarchy.
• PSModule/docs is marked deprecated, then archived or removed after cutover validation.

Technical decisions

Single authoritative repository: Process-PSModule becomes the temporary hub for PSModule GitHub Actions docs and standards.

Migration gating: No docs repo retirement work starts until open PRs are merged/resolved and issues are transferred.

Hierarchy and decomposition: Work is tracked through native GitHub sub-issues per Issue Hierarchy.

Issue structure: Parent and children follow the three-section format from Issue Format.

Checksum publish design tracking: Existing release-trigger work in #184 remains in Process-PSModule and is refined under this consolidation effort so behavior policy and implementation tracking stay together.

Implementation plan

Execution is managed through the parent issue's native GitHub sub-issues relationship (not checklist links in this body).

This issue is structured per Workflow: capture -> refine -> plan -> build.