You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 120554a
Browse filesBrowse the repository at this point in the historyBrowse files
📖 [Docs]: Process-PSModule owns the documentation root (#452)
Process-PSModule documentation now lives at the root of the site. Its
lifecycle overview, getting-started material, guides, reference,
specifications, and media no longer sit beneath a
`Modules/Process-PSModule` source hierarchy.
## Changed: The framework owns the root page
The root page now uses the Process-PSModule title, description, and
lifecycle content as its primary documentation. It retains the
non-duplicated PSModule and cross-organization context from the former
root page, so readers land directly in the framework without losing the
broader context.
## Changed: Clear top-level documentation sections
The navigation now presents Process-PSModule, Getting started, Guides,
Reference, Specification, and Modules at the top level. Reference
combines the framework's operational contracts with its
module-development standards. Modules is the standalone index for
discovering the PSModule organization’s modules. Dictionary pages remain
published for inline glossary links without occupying a visible
navigation tab.
## Fixed: The module index generator follows the new structure
The scheduled documentation update now fills the Modules page and
publishes each generated module detail page below it. Catalog icons and
module links resolve from their new root-level locations, so the next
automated refresh updates the visible module index instead of the
retired Catalog path.
---
<details>
<summary>Technical details</summary>
- Implementation plan progress: all steps in the scoped Task are
complete.
- Moved `get-started/`, `guides/`, `reference/`, `specification/`, and
`media/` with `git mv`, preserving file history.
- Merged the former inner landing page into `docs/content/index.md`; its
front matter, title, and framework content take precedence, while the
non-duplicated root content remains below it.
- Moved the module-development standards into `docs/content/reference/`
and added them to the top-level Reference navigation.
- Replaced the Catalog navigation entry with Modules, whose top-level
page is the module index.
- `Update-ModuleList` now writes generated pages to
`docs/content/Modules/Repositories/` and replaces the marker in
`docs/content/Modules/index.md`; the V2 catalog template references
assets at the correct depth.
- Added an isolated Pester regression test for the catalog generator and
installed its declared GitHub module dependency in the action test
workflow.
- Dictionary remains in Zensical's navigation graph because unlisted
pages are not built; a scoped stylesheet hides its tab and drawer
entries while preserving published glossary URLs.
- The strict clean Zensical build succeeds, the catalog Pester suite
passes, PSScriptAnalyzer reports no findings, and all in-repository
Markdown links resolve.
- Standards and framework alignment:
| Changed surface | Standards checked | Framework docs checked | Result
|
| --- | --- | --- | --- |
| `docs/content/**` | Documentation Model | Process-PSModule information
architecture | Aligned |
| `docs/zensical.toml` | Documentation navigation | Zensical navigation
indexes | Aligned |
| `.github/actions/update-index/**` | PowerShell testing and action
conventions | Generated module catalog contract | Aligned |
| `AGENTS.md` | Agentic Development | Canonical framework guidance |
Aligned |
- Issue convergence sweep: reviewed the parent PBI and its current
delivery leaves; this pull request implements only the scoped
documentation-navigation Task.
</details>
<details>
<summary>Relevant issues (or links)</summary>
- Fixes#451
- #423
</details>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Process-PSModule now hosts PSModule-org module documentation.
3
+
This page indexes modules maintained in the PSModule organization and what each module does.
4
4
5
-
This section is the local source of truth for:
5
+
Modules are 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.
6
6
7
-
- module catalog and module-level specs
8
-
- Process-PSModule structure and build flow
9
-
- repository anatomy and template onboarding
7
+
## Scope
10
8
11
-
## Sections
9
+
Each module page should capture:
12
10
13
-
-[Repository Standard](Repository-Standard.md)
14
-
-[Standards](Standards.md)
15
-
-[Module types](Module-Types.md)
16
-
-[Test Specification](Test-Specification.md)
17
-
-[Versioning](Versioning.md)
18
-
-[Catalog](Catalog/index.md) (auto-generated from PSModule repo metadata, release data, and README summaries)
19
-
-[Process-PSModule](Process-PSModule/index.md)
11
+
- purpose and problem statement
12
+
- install and import baseline
13
+
- key exported capabilities
14
+
- owner and maintenance notes
15
+
- lifecycle status
16
+
17
+
## Module index generation
18
+
19
+
The module list and linked module pages are generated from PSModule repository metadata and README content, then refreshed automatically.
Copy file name to clipboardExpand all lines: docs/content/get-started/module-bootstrap.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ A brand-new module usually has a small **load-bearing core**: the piece(s) every
9
9
10
10
## Identify the load-bearing core first
11
11
12
-
What counts as "load-bearing" follows the module's archetype from [Module types](../../Module-Types.md):
12
+
What counts as "load-bearing" follows the module's archetype from [Module types](../reference/module-types.md):
13
13
14
14
-**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.
15
15
-**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
19
19
## Pattern
20
20
21
21
1. Cut one long-lived branch from the default branch for the initial release, named for the outcome, e.g. `build-thing-module`.
22
-
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).
22
+
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).
23
23
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`).
24
24
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.
25
25
26
26
## After the core lands
27
27
28
-
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.
28
+
Once the core has merged as `v1.0.0`, ordinary [SemVer](../reference/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.
29
29
30
30
```mermaid
31
31
gitGraph
@@ -60,6 +60,6 @@ A module bootstrapped this way:
60
60
## When to use this
61
61
62
62
- The module has no usable release yet, and the load-bearing core hasn't landed.
63
-
- 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.
63
+
- 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.
64
64
65
-
For the general branching and merge model, see [MSX Branching and Merging](https://msxorg.github.io/docs/Ways-of-Working/Branching-and-Merging/).
65
+
For the general branching and merge model, see [MSX Branching and Merging](https://msx.no/docs/Ways-of-Working/Branching-and-Merging/).
0 commit comments