Reorganize repository structure to isolate the PowerShell module

[silverhack]

Summary

Monkey365 continues to grow as an open-source project. As adoption increases, the repository is also accumulating multiple assets that are not part of the PowerShell module itself, including documentation, pipelines, tooling, docker files, examples, etc...

To improve maintainability, packaging, CI/CD workflows, and future Azure DevOps integration, the repository structure should separate the PowerShell module from repository-level resources.

Proposed structure

repo_root/
  .github/
  src/
    monkey365/
  tests/
  docs/
  docker/
  examples/
  LICENSE
  README.md

Goals

• Establish a clear separation between:
  • The PowerShell module
  • Repository tooling and supporting resources
• Improve packaging and publishing workflows
• Simplify CI/CD pipeline integration
• Make the repository easier to scale without cluttering the module root

Important note

This proposal does not introduce major internal refactoring of the module.

The current internal structure (core/, collectors/, rules/, config/, etc.) would remain intact initially and simply move under:

src/monkey365/

Example:

src/
  monkey365/
    monkey365.psm1
    monkey365.psd1
    core/
    collectors/
    rules/
    config/

Benefits

• Cleaner repository organization
• Safer packaging boundaries
• Easier CI/CD automation
• Better scalability for additional tooling and documentation
• Consistency with common open-source and DevOps repository layouts

Implementation considerations

Achieving this repository reorganization will require several supporting tasks beyond simply moving directories.

Examples include:

• Updating documentation and examples
• Revising the main README.md
• Adjusting CI/CD and packaging workflows
• Updating import/module loading paths where required
• Improving Pester test coverage for the core module
• Removing outdated or unused GitHub Actions workflows
• Removing duplicated or legacy code where practical
• Validating compatibility with existing automation and scripts
• Reviewing tests and development tooling

These tasks should be handled incrementally to reduce migration risk and maintain backward compatibility during the transition.

Future work (separate enhancements)

Potential future improvements may include:

• Improving module loading logic
• Clearer separation of runtime and core components
• Modularization of internal services and providers
• Decoupling collectors, rules, and output components

These changes are intentionally outside the scope of this proposal to minimize migration risk.