Bring Json up to the PSModule module and repository standard

[MariusStorhaug]

Context and request

PSModule/Json is a published data module that has drifted from the standards it is supposed to demonstrate. It still carries the unmodified Template-PSModule README, is missing seven of the required baseline repository files, is pinned a full major version behind the shared pipeline with main failing on a nightly schedule, and exposes three of the commands its own archetype defines. This Epic is the repository-level aggregate that closes that gap.

Why. Module types names Json as one of the reference data modules alongside Hashtable, Base64, Lua, Hcl, Sodium, and Uri. A module cited as a reference implementation has to actually be one — otherwise the standard loses its evidence and every module generated by looking at Json inherits the same drift.

How. Work outward from the pipeline. Restore a green build first so every later change is verifiable, then bring the repository baseline and documentation surfaces up to the Repository Standard, then align the existing commands with the MSX PowerShell function standard, then correct behavioural defects, and only then extend the command surface. No rewrite: the module's existing behaviour stays compatible except where it is demonstrably wrong.

What. A module repository that passes the README validation checks in the Repository Standard, carries every required baseline and agent-onboarding file, builds green on the current Process-PSModule generation, exposes the data-module verb vocabulary, and whose commands declare their output contract.

Success measures

Measure	Current state	Target
Scheduled Process-PSModule runs on main	Failing daily on all three runners	Green
Required baseline files present	6 of 13	13 of 13
README validation checks passed	0 of 5	5 of 5
Public commands declaring [OutputType()]	0 of 3	All
Data-module verb vocabulary covered	3 verbs	Full set, or a documented decision to defer

Out of scope

• Migrating the repository to the Custo managed-file distribution runtime.
• Rewriting Format-Json's indentation engine, which is correct for ConvertTo-Json output.
• Retiring the Json module in favour of the built-in JSON cmdlets.

Aggregate acceptance criteria

• A fresh clone passes every check in README validation with no matches.
• An agent with no prior context can enter the repository through AGENTS.md and reach the canonical guidance.
• The scheduled workflow on main succeeds on Linux, macOS, and Windows.
• Get-Command -Module Json returns the command set this Epic's children agree on, and every command has [OutputType()] matching its .OUTPUTS.
• Importing a JSON file, modifying it, and exporting it reproduces the input structure without added properties or depth truncation.

Technical decisions

The decomposition follows dependency order rather than file type, so each child is independently mergeable and verifiable.

The pipeline PBI comes first because the current failure blocks verification of everything else — no other child can prove its acceptance criteria while main is red. Repository baseline and documentation are independent of each other and of the code work, so they can run in parallel once the pipeline is green. Function-standard alignment is separated from the behavioural bugs because the former is a contract change with no runtime effect and the latter changes observable output; mixing them would make the bug fixes unreviewable. The command-surface extension comes last because new commands should be written against the corrected patterns, not the current ones.

Reference implementations for the data-module shape are PSModule/Hashtable and PSModule/Uri. Both keep a flat src/functions/public/ layout, so Json does not need <Group> folders.

Three pull requests are already open against parts of this work and should be reconciled rather than duplicated: #22, #23, and #26.

Implementation plan

Delivery is tracked through the native sub-issues on this Epic.