Distribute mandatory repo files (CONTRIBUTING, AGENTS, CLAUDE, copilot-instructions) via Distributor

[MariusStorhaug]

The standard now requires every module repo to stand on its own and not rely on the org .github fallback (PR PSModule/docs#61). Mandatory files: CONTRIBUTING.md (self-contained), AGENTS.md, CLAUDE.md (@AGENTS.md import), .github/copilot-instructions.md, plus existing SECURITY.md / SUPPORT.md / CODE_OF_CONDUCT.md.

Task: add these as mandatory file sets in PSModule/Distributor so they are pushed to all module repos instead of hand-editing each repo. The agent files must point to PSModule/docs (module why/how/what) and MSXOrg/docs (org principles). Depends on the Distributor mandatory-file-set capability.

[MariusStorhaug]

Evidence that distribution is needed, recorded from #487 as planned there.

One page rename produced broken links in four repositories inside a day, and a fifth within hours. PSModule/docs#96 renamed Modules/Repository-Defaults to Modules/Repository-Standard. The old URL kept serving only because the site had stopped publishing (#106), which hid the breakage until that was diagnosed. The referrer scan found 8 files across 3 repositories — Template-PSModule, PSSemVer, Lovdata — every one of them in the file set this issue is about. While the fixes were being opened, PSModule/CasingStyle#22 adopted the baseline files from a branch created before the correction existed, and would have shipped two more dead links. That is a fourth repository, and it appeared after the scan.

The same three files also carried a second dead link that nobody had noticed: msxorg.github.io/docs/Ways-of-Working/Issue-Format/ has been returning 404 independently, since that page moved to Ways-of-Working/Issues/Process/Format/.

Why this is a distribution problem, not a link problem. The referrer set is not a list that can be drained. It grows every time a repository adopts the baseline files, so a hand sweep is correct only for the instant it is performed. There are 58 repositories with Type: Module (gh search repos --owner PSModule 'props.Type:Module'), and this issue's target is all of them. Four hand-written pull requests were needed for four repositories; at 58, an upstream correction that does not propagate is indistinguishable from no correction. Fixed for now in PSModule/Template-PSModule#42, PSModule/PSSemVer#53, PSModule/Lovdata#22, with PSModule/CasingStyle#22 carrying the same wording — verified byte-identical to the template rather than reviewed by eye.

Two premises in the description above have since changed. Worth correcting before this is picked up, because both affect what gets built:

1. The runtime is MSXOrg/Custo, not PSModule/Distributor. Migrated in PSModule/docs#85; the Repository Standard now states that policy ownership and distribution runtime are separate concerns, that Custo is the runtime, and that repositories still aligned to Distributor should migrate. The opt-in is the SubscribeTo custom property.
2. .github/copilot-instructions.md is no longer a mandatory file. The Repository Standard now calls runtime adapter files optional, and Template-PSModule ships without one — it was removed in refactor: slim template scaffolding to minimum baseline Template-PSModule#33. Keeping it in the mandatory set here would distribute a file the template deliberately dropped, which is the drift Reconcile the Repository Defaults required-files tables with what Template-PSModule ships #484 exists to prevent. The mandatory agent entry points are AGENTS.md and CLAUDE.md.

[MariusStorhaug]

Correcting my earlier comment on this issue, and adding a blocker that is larger than the two stale premises.

I wrote above that distribution is "the durable answer" to the link-rot class of drift. That is still true as a design, but I checked whether it can deliver anything today, and it cannot. Four measurements against the live organization:

Check	Result
Module repositories with SubscribeTo set	1 of 58 — PSModule/GitHub, value Custom Instructions, License, Prompts
Module repositories subscribed to gitignore	0 of 58
References to SubscribeTo anywhere in MSXOrg code	none found
Contents of MSXOrg/Custo, the documented runtime	LICENSE and a two-line README.md

The opt-in is valid — gitignore is in the organization schema — and completely inert. The runtime it opts into is a stub.

This reorders the work. "A runtime exists" and "repositories are subscribed" are prerequisites of this campaign, not tasks inside it. Distributing the mandatory files cannot be implemented against a mechanism with no implementation and no subscribers, so this issue should not be picked up until those are true, or it will be planned against a capability that does not exist.

It has already cost something. PSModule/Template-PSModule#43 fixes a .gitignore gap in the template, and its description originally claimed the fix would reach all 58 module repositories via SubscribeTo. That claim was mine and it was wrong; it is retracted on the pull request, with this table in its place. The pull request still stands on its own — it stops the gap being reproduced in new repositories — but it reaches no existing repository. That is exactly the misplanning this issue is exposed to at a larger scale.

The root cause is that the Repository Standard describes the mechanism in the present tense, which is now filed as #488. This issue should depend on it.

Credit where due: the SubscribeTo measurement was first run by the agent working PSModule/CasingStyle#22, who spotted that PSModule/docs#43 could not propagate. I re-ran it independently and got the same numbers, then found the Custo stub while checking whether anything consumed the property.

[MariusStorhaug]

Correcting my previous comment on this issue. Its conclusion — that a running runtime and subscribed repositories are prerequisites of this campaign — stands unchanged. Its stated reason was wrong.

I wrote that SubscribeTo has no implementation and that the runtime is a stub. The stub part is true of MSXOrg/Custo; the "no implementation" part is not. I had scoped the code search to --owner MSXOrg because that is the runtime the Repository Standard names — searching where the documentation points, which is the failure this whole thread has been about. gh search code --owner PSModule 'SubscribeTo' finds PSModule/Distributor/scripts/Sync-Files.ps1, the predecessor engine.

What actually happened, verified: Sync Managed Files has run 76 times, succeeded 3 times — all on 2026-04-05 — then failed 63 consecutive times through 2026-06-05, at which point GitHub disabled the workflow for inactivity. MSXOrg/Custo was created seven weeks later, on 2026-07-25.

So distribution is not unbuilt. It ran, broke in April, failed loudly every day for two months while nobody read it, and was switched off. Full evidence and the reclassification are on #488.

Two things this changes for planning here.

Sync-Files.ps1 is the only encoding of what a SubscribeTo value means. Whatever delivers the mandatory files next should be reconciled against it rather than designed fresh, or the contract gets silently re-derived — including for PSModule/GitHub, the one repository that has the property set (#110).

And the prerequisite list gains an entry that is not technical: someone has to be expected to notice when distribution stops. An unowned scheduled job that fails is indistinguishable, after GitHub disables it, from one that was never built — I drew exactly that wrong conclusion from the evidence. Distributing files to 58 repositories without that ownership recreates the same silent stop.

Credit for finding the engine goes to the agent working PSModule/CasingStyle#22.