Move Process-PSModule documentation to the site root

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Author: MariusStorhaug

AGENTS.md

@@ -15,7 +15,7 @@ If you find a problem or improvement, fix if small; otherwise open an issue.
 Regarding repo structure, module source code, and how the Process-PSModule workflow
 works. For PSModule-specific build, layout, and process guidance:
 
-- [Process-PSModule docs](https://psmodule.github.io/docs/Modules/Process-PSModule/) —
+- [Process-PSModule docs](https://psmodule.io/docs/) —
   repository structure, module anatomy, and the build/test/pack/publish pipeline.
 - [Repository defaults](https://psmodule.github.io/docs/Modules/Repository-Defaults/) —
   the expected repository layout and required files.
@@ -28,11 +28,11 @@ works. For PSModule-specific build, layout, and process guidance:
 
 For cross-cutting ways of working and standards:
 
-- [Agentic Development](https://msxorg.github.io/docs/Ways-of-Working/Agentic-Development/) —
+- [Agentic Development](https://msx.no/docs/Ways-of-Working/Agentic-Development/) —
   how agents and humans collaborate in this ecosystem.
-- [Ways of Working](https://msxorg.github.io/docs/Ways-of-Working/) — contribution
+- [Ways of Working](https://msx.no/docs/Ways-of-Working/) — contribution
   workflow, branching, PRs, issues.
-- [Coding Standards](https://msxorg.github.io/docs/Coding-Standards/) — language-level
+- [Coding Standards](https://msx.no/docs/Coding-Standards/) — language-level
   conventions.
 - [MSXOrg/memory](https://github.com/MSXOrg/memory) — durable agent working memory:
   gotchas, knowledge, and agent role notes.

docs/content/Modules/Catalog/index.md

@@ -2,7 +2,7 @@
 
 This catalog tracks modules maintained in the PSModule organization and what each module does.
 
-The catalog is separate from the [Process-PSModule framework](../Process-PSModule/index.md). Use the framework documentation to build and release a module; use this page to discover the modules available to install and use.
+The catalog is separate from the [Process-PSModule framework](../../index.md). Use the framework documentation to build and release a module; use this page to discover the modules available to install and use.
 
 ## Scope
 

docs/content/Modules/Module-Types.md

@@ -1,7 +1,7 @@
 # Module types
 
 Most PSModule modules fall into one of a few archetypes. The general rules in
-[PowerShell module standard](Standards.md) and [MSX PowerShell Standards](https://msxorg.github.io/docs/Coding-Standards/PowerShell/) always apply; this
+[PowerShell module standard](Standards.md) and [MSX PowerShell Standards](https://msx.no/docs/Coding-Standards/PowerShell/) always apply; this
 page adds the conventions that are specific to a module's type so that modules of the same kind feel
 the same to use.
 

docs/content/Modules/Process-PSModule/index.md

@@ -2,7 +2,7 @@
 
 This is the PSModule organization's Repository Standard. It applies to the PSModule organization and is the standard for PowerShell module repositories. It describes what a newly created or maintained module repository should look like before module-specific code, tests, documentation, and managed repository files are considered.
 
-This standard operates at the same altitude as the [MSX Enterprise Repository Standard](https://msxorg.github.io/docs/Ways-of-Working/Repository-Standard/): MSX sets the enterprise-wide default, and this standard adds to and adjusts that default for PowerShell module repositories. Rules this standard does not change are inherited from the MSX default; where this standard adds or overrides a rule, it governs PowerShell module repositories.
+This standard operates at the same altitude as the [MSX Enterprise Repository Standard](https://msx.no/docs/Ways-of-Working/Repository-Standard/): MSX sets the enterprise-wide default, and this standard adds to and adjusts that default for PowerShell module repositories. Rules this standard does not change are inherited from the MSX default; where this standard adds or overrides a rule, it governs PowerShell module repositories.
 
 The implementation standard still lives in [PowerShell module standard](Standards.md). Type-specific conventions for integration (API) and data modules live in [Module types](Module-Types.md). This page covers the repository standard for module repositories: files, metadata, README shape, release integration, placeholder handling, shared community files, and managed-file distribution.
 
@@ -70,7 +70,7 @@ Local work should use the organization worktree convention:
 - `main/` tracks the default branch.
 - Feature worktrees use `<type>-<slug>` directories and `<type>/<slug>` branches.
 
-For branch and worktree details, see [Git Worktrees](https://msxorg.github.io/docs/Ways-of-Working/Git-Worktrees/).
+For branch and worktree details, see [Git Worktrees](https://msx.no/docs/Ways-of-Working/Git-Worktrees/).
 
 ## Default repository layout
 
@@ -173,7 +173,7 @@ See [PSModule/Template-PSModule](https://github.com/PSModule/Template-PSModule)
 
 `AGENTS.md` and `CLAUDE.md` are the required set. `AGENTS.md` is the entry point that AGENTS.md-aware runtimes read directly, so a repository is usable by an agent without a per-runtime copy of the same pointer.
 
-Runtime-specific adapter files such as `.github/copilot-instructions.md` and `.github/instructions/*.instructions.md` are optional. MSX treats them as client adapters that *may* add runtime-specific loading or path rules, described in [Agentic Development](https://msxorg.github.io/docs/Ways-of-Working/Agentic-Development/) and its [capability specification](https://msxorg.github.io/docs/Capabilities/agentic-development/spec/). Add one when a runtime needs loading or path rules that `AGENTS.md` cannot express, and keep it pointing at `AGENTS.md` rather than restating it. `Template-PSModule` ships without one.
+Runtime-specific adapter files such as `.github/copilot-instructions.md` and `.github/instructions/*.instructions.md` are optional. MSX treats them as client adapters that *may* add runtime-specific loading or path rules, described in [Agentic Development](https://msx.no/docs/Ways-of-Working/Agentic-Development/) and its [capability specification](https://msx.no/docs/Capabilities/agentic-development/spec/). Add one when a runtime needs loading or path rules that `AGENTS.md` cannot express, and keep it pointing at `AGENTS.md` rather than restating it. `Template-PSModule` ships without one.
 
 These files are the agent equivalent of the README: pointers, not copies. Keep them short so the linked documentation stays the single source of truth. Like the other governance files, they live in the repository itself so it can stand on its own.
 

docs/content/Modules/Repository-Standard.md

@@ -2,7 +2,7 @@
 
 Standards for implementing and reviewing PowerShell modules in the PSModule organization. These rules apply to modules built with the [PSModule framework](https://github.com/PSModule/Process-PSModule).
 
-For general PowerShell coding standards (naming, style, function structure, documentation, readability, error handling), see [MSX PowerShell Standards](https://msxorg.github.io/docs/Coding-Standards/PowerShell/). This page covers only module-specific conventions.
+For general PowerShell coding standards (naming, style, function structure, documentation, readability, error handling), see [MSX PowerShell Standards](https://msx.no/docs/Coding-Standards/PowerShell/). This page covers only module-specific conventions.
 
 ## Supported PowerShell version
 

docs/content/Modules/Standards.md

@@ -2,7 +2,7 @@
 
 Process-PSModule is the framework for building, testing, versioning, documenting, and publishing PowerShell modules. These foundations define the repository, source, test, and release conventions that the framework supports and validates.
 
-Start with the [Process-PSModule overview](Process-PSModule/index.md) to understand the workflow. Use these pages when creating or maintaining a module that runs through it.
+Start with the [Process-PSModule overview](../index.md) to understand the workflow. Use these pages when creating or maintaining a module that runs through it.
 
 | Page | Use it for |
 | --- | --- |

docs/content/Modules/index.md

@@ -34,4 +34,4 @@ If the module needs several interdependent commands before it is usable at all,
 | [Your first release](your-first-release.md) | The pull request flow, version labels, and what happens on merge. |
 | [Module bootstrap](module-bootstrap.md) | Getting a brand-new module to its first release with an integration branch. |
 
-For framework-level practices, refer to [MSX Ways of Working](https://msxorg.github.io/docs/Ways-of-Working/).
+For framework-level practices, refer to [MSX Ways of Working](https://msx.no/docs/Ways-of-Working/).

…es/Process-PSModule/get-started/index.md docs/content/get-started/index.mddocs/content/Modules/Process-PSModule/get-started/index.md renamed to docs/content/get-started/index.md docs/content/Modules/Process-PSModule/get-started/index.md renamed to docs/content/get-started/index.md

@@ -9,7 +9,7 @@ A brand-new module usually has a small **load-bearing core**: the piece(s) every
 
 ## Identify the load-bearing core first
 
-What counts as "load-bearing" follows the module's archetype from [Module types](../../Module-Types.md):
+What counts as "load-bearing" follows the module's archetype from [Module types](../Modules/Module-Types.md):
 
 - **Data modules** — the conversion pivot: `ConvertFrom-<Format>` / `ConvertTo-<Format>` (and whatever parser/serializer they wrap). Every other function (`Import-`, `Export-`, `Format-`, `Merge-`, ...) is built on top of this pivot and is meaningless without it.
 - **Integration (API) modules** — a [`Context`](https://github.com/PSModule/Context)-backed credential/config store, the client setup that uses it, and at least one API function that consumes the context end-to-end. Every other API function needs the same context and client to do anything.
@@ -19,13 +19,13 @@ Scope the integration branch to exactly that core, not to everything planned for
 ## Pattern
 
 1. Cut one long-lived branch from the default branch for the initial release, named for the outcome, e.g. `build-thing-module`.
-2. Open one pull request per function (or small group of related functions) targeting that branch instead of `main`. These PRs can land in parallel — there is no strict order between them, unlike a [stacked pull request](https://msxorg.github.io/docs/Ways-of-Working/Branching-and-Merging/#stacked-pull-requests).
+2. Open one pull request per function (or small group of related functions) targeting that branch instead of `main`. These PRs can land in parallel — there is no strict order between them, unlike a [stacked pull request](https://msx.no/docs/Ways-of-Working/Branching-and-Merging/#stacked-pull-requests).
 3. Once the load-bearing core is coherent and complete, open the pull request that merges the integration branch into `main`. This becomes the module's first real release (`v1.0.0`).
 4. Smaller follow-up features (one more function, a formatter, an alias) can keep targeting the integration branch before it lands, the same way they targeted it during bootstrap.
 
 ## After the core lands
 
-Once the core has merged as `v1.0.0`, ordinary [SemVer](../../Versioning.md) applies: a new function built on the stable core is a **minor** bump, a fix is a **patch** bump, and only a change to the core's own contract (signature, exported class shape, behavior) is a **major** bump. No special versioning exception is needed once the core is in place — the bootstrap phase exists only to get that core to a first release quickly.
+Once the core has merged as `v1.0.0`, ordinary [SemVer](../Modules/Versioning.md) applies: a new function built on the stable core is a **minor** bump, a fix is a **patch** bump, and only a change to the core's own contract (signature, exported class shape, behavior) is a **major** bump. No special versioning exception is needed once the core is in place — the bootstrap phase exists only to get that core to a first release quickly.
 
 ```mermaid
 gitGraph
@@ -60,6 +60,6 @@ A module bootstrapped this way:
 ## When to use this
 
 - The module has no usable release yet, and the load-bearing core hasn't landed.
-- Use this only for the initial bootstrap. Once `main` has a first release, ongoing feature work targets `main` directly with ordinary topic branches, or a [stacked pull request](https://msxorg.github.io/docs/Ways-of-Working/Branching-and-Merging/#stacked-pull-requests) when changes genuinely depend on each other.
+- Use this only for the initial bootstrap. Once `main` has a first release, ongoing feature work targets `main` directly with ordinary topic branches, or a [stacked pull request](https://msx.no/docs/Ways-of-Working/Branching-and-Merging/#stacked-pull-requests) when changes genuinely depend on each other.
 
-For the general branching and merge model, see [MSX Branching and Merging](https://msxorg.github.io/docs/Ways-of-Working/Branching-and-Merging/).
+For the general branching and merge model, see [MSX Branching and Merging](https://msx.no/docs/Ways-of-Working/Branching-and-Merging/).