State the real status of managed file distribution on the Repository Standard

[MariusStorhaug]

The Repository Standard describes managed file distribution in the present tense: the SubscribeTo custom property is presented as the live opt-in, and the runtime is stated to be handled by MSXOrg/Custo. Neither is operating. A maintainer reading the page reasonably concludes that setting SubscribeTo causes files to be managed, and that a correction made in Template-PSModule reaches existing repositories. Neither happens, and nothing reports that.

Observed behavior

Four checks, each one against the live organization rather than the page:

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
Implementation that consumes SubscribeTo	one — PSModule/Distributor/scripts/Sync-Files.ps1, whose workflow is disabled_inactivity
Sync Managed Files runs, all time	76: 3 success, 73 failure. All three successes fell on 2026-04-05; 63 consecutive failures followed, then GitHub disabled the workflow for inactivity. Last run of any kind 2026-06-05
Contents of MSXOrg/Custo, the documented successor	LICENSE and a two-line README.md, created 2026-07-25 — seven weeks after the predecessor stopped running

gh search repos --owner PSModule 'props.Type:Module' --limit 100 --json fullName --jq '.[].fullName' |
    ForEach-Object { gh api "repos/$_/properties/values" --jq '.[] | select(.property_name=="SubscribeTo")' }
# one repository responds

gh api repos/MSXOrg/Custo/git/trees/HEAD?recursive=1 --jq '[.tree[] | select(.type=="blob")] | length'
# 2

The property itself is valid — gitignore is in the organization schema alongside gitattributes, CODEOWNERS, dependabot.yml, PSModule Settings, Linter Settings, License, Custom Instructions, Prompts, and Hooks. It is wired, implemented once, and not running.

Expected behavior

The page states the actual status of managed file distribution, so a reader can tell the difference between what is normative today and what is planned. Where a mechanism is not yet operating, the page says so and points at the work that will make it so.

Reproduction

1. Read the "Managed file distribution" section of the Repository Standard.
2. Query SubscribeTo across props.Type:Module repositories.
3. Inspect MSXOrg/Custo, and the run history and state of Sync Managed Files in PSModule/Distributor.
4. Observe that the described mechanism has almost no subscribers, that its only implementation has been switched off since 2026-06-05, and that its documented successor is a stub.

Environment

PSModule/docs, src/docs/Modules/Repository-Standard.md; PSModule organization custom property schema; MSXOrg/Custo at HEAD.

Regression

Not a regression in the page. The wording appears to have been written for the intended end state, and #85 migrated the named runtime from PSModule/Distributor to MSXOrg/Custo without the status changing.

Workaround

Managed files are corrected by hand, one pull request per repository. That is what happened in #108: a single page rename produced broken links in four repositories, and four hand-written pull requests were needed.

Acceptance criteria

• The Repository Standard distinguishes what is operating today from what is planned, for both SubscribeTo and the distribution runtime.
• A reader can tell whether setting SubscribeTo has any effect today.
• The prerequisites for Distribute mandatory repo files (CONTRIBUTING, AGENTS, CLAUDE, copilot-instructions) via Distributor #63 are recorded in order, so that campaign is not planned against a mechanism that cannot run.
• No claim on the page asserts an outcome that no code produces.
• The section names an owner expected to notice when distribution stops, not only a runtime expected to run.

References

• Distribute mandatory repo files (CONTRIBUTING, AGENTS, CLAUDE, copilot-instructions) via Distributor #63 — distributing the mandatory repository files. This issue is a prerequisite of it, not a step inside it.
• Keep links to the renamed Repository Standard page resolving #108 — the link rot that had to be corrected by hand across four repositories, which is what distribution would have prevented.
• Reconcile the Repository Defaults required-files tables with what Template-PSModule ships #103 — reconciling the page with what Template-PSModule ships. Same page, same class of drift.
• 🩹 [Patch]: Local test runs no longer leave a coverage report to commit by accident Template-PSModule#43 — a template fix whose description originally claimed it would propagate via SubscribeTo; that claim has been retracted on the pull request.

---

Technical decisions

This is a documentation defect, not a request to build Custo — and not a request to revive Distributor. Whether and when the runtime gets implemented is MSXOrg's call. What this repository owns is that its normative page describes the mechanism as though it were running. The correction is to state the status accurately; the page can keep describing the target design as long as it is labelled as such.

Why the status matters more than it looks. Three separate pieces of work in the last day were planned against the assumption that distribution works: #63's premise, PSModule/Template-PSModule#43's original propagation claim, and the decision in #108 to fix referrers at the template on the grounds that the correction would flow downstream. The first two were wrong in the same way. A page that overstates operational status does not merely misinform — it changes what people decide to build.

Ordering for #63, as evidence rather than opinion. Distribution cannot deliver the baseline files while the only implementation is switched off and nothing is subscribed. That makes "a runtime is running" and "repositories are subscribed" prerequisites of #63 rather than tasks within it. Recording that ordering is the part this issue owns; executing it is not.

Not the same failure shape as #106 — the inverse, and the more uncomfortable one. #106 and MSXOrg/docs#152 were silent: a workflow reporting success while deploying nothing, and a site declaring a canonical host it is not served from. Nothing failed, so the answer was to inspect the artifact instead of the status. This one is the opposite. It failed loudly, on a schedule, 63 times in a row over two months, and the signal still reached nobody — then GitHub switched the workflow off for inactivity and the noise stopped, and silence reads like health. "Check the artifact, not the check mark" does not catch this, because the check mark was red and simply was not being read.

The consequence for the page: whatever it ends up saying about distribution should name an owner expected to notice, not only a runtime expected to run. An unowned scheduled job that fails is indistinguishable from one that was never built, and it decays into the second state on its own.

Sync-Files.ps1 is a specification of intent, not a proven implementation. It is the sole consumer of SubscribeTo in either organization, so it is the only written definition of what each schema value means — including for PSModule/GitHub, the one repository that has the property set. It should be read before any successor is written, or that contract gets silently re-derived. But it should not be treated as working code to restore or port: it succeeded on one day out of 76 attempts, so there is almost no evidence it ever did the job. "Restore Distributor" and "port it to Custo" both assume a working implementation exists; the run history does not support that. Read it as the spec while writing something new.

Incidental, and worth an audit of its own. sync-files.yml already authenticates as secrets.CUSTO_BOT_CLIENT_ID / CUSTO_BOT_PRIVATE_KEY, so the Custo identity predates the Custo repository by months. Anyone auditing which GitHub App holds write access across the fleet should start there rather than from the Custo repository.

Open question. Whether the page should carry status labels generally — a normative page that mixes current requirements with intended design has no way to signal which is which today. Open: resolve before rewriting the section, because it decides whether this is a local edit or a page-wide convention.

---

Implementation plan

• Confirm with MSXOrg what Custo's actual status and intended timeline are, and whether PSModule/Distributor is intended to be revived, retired, or ported — so the page states a fact rather than an inference.
• Read PSModule/Distributor/scripts/Sync-Files.ps1 and record the semantics it gives each SubscribeTo value, before any successor is written — as a specification of intent, not as working code to restore or port.
• Resolve the open question about status labelling and record the choice here.
• Rewrite the managed file distribution section to separate what is normative today from the target design.
• State plainly whether setting SubscribeTo currently has any effect.
• Record the prerequisite ordering on Distribute mandatory repo files (CONTRIBUTING, AGENTS, CLAUDE, copilot-instructions) via Distributor #63.
• Decide who owns noticing that distribution has stopped, and record it on the page.
• Re-check the measurements above at the time of the rewrite rather than trusting this issue's table.

[MariusStorhaug]

Adding a fifth check to the table. The predecessor runtime — PSModule/Distributor, which the Repository Standard says repositories "should migrate to Custo" from — is not merely superseded. It broke, failed daily for two months, and was then switched off by GitHub.

Check	Result
SubscribeTo consumers in PSModule code	PSModule/Distributor/scripts/Sync-Files.ps1 — an implementation does exist, in the engine being migrated away from
Sync Managed Files run history (last 100)	73 failure, 8 success
Last successful run	2026-04-05
Last run of any kind	2026-06-05 — 61 consecutive failures before it stopped
Current workflow state	disabled_inactivity

gh api repos/PSModule/Distributor/actions/workflows --jq '.workflows[] | "\(.name) state=\(.state)"'
# Sync Managed Files state=disabled_inactivity

gh run list --repo PSModule/Distributor --limit 100 --json conclusion --jq 'group_by(.conclusion) | map("\(.[0].conclusion): \(length)")'
# ["failure: 73","success: 8"]

So the timeline is: distribution last worked on 2026-04-05, failed every day until 2026-06-05, was auto-disabled for repository inactivity, and MSXOrg/Custo was created as a stub on 2026-07-25. The gap has been open for roughly four months, not since the Custo migration was announced.

Two things follow for this issue.

The failure mode is the inverse of #106, and arguably worse. #106 was a job that skipped silently — there was nothing to see. This was a scheduled workflow posting a red run every morning for 61 days, and the signal still reached no one. Then it went quiet, and quiet reads like success. A rule that says "check the artifact, not the check mark" does not cover this one; the check mark was red and was not being read at all. Whatever this page ends up saying about distribution should name an owner who is expected to notice, not only a runtime.

Sync-Files.ps1 is worth reading before Custo is written. It is the only code in either organization that consumes SubscribeTo, so it encodes the intended semantics of every value in the schema. Treating Custo as greenfield risks re-deriving that contract differently and silently changing what a subscription means for the one repository that already has the property set.

Incidentally, sync-files.yml already authenticates with secrets.CUSTO_BOT_CLIENT_ID and secrets.CUSTO_BOT_PRIVATE_KEY, so the Custo identity predates the Custo repository. Anyone auditing which app has write access across the fleet should start there.

[MariusStorhaug]

Correcting a material error in this issue's original body. It claimed the mechanism had no implementation. That was wrong, and the conclusion it supported — "distribution is not operating" — happens to survive, but for a different and more interesting reason. Body updated; recording the change here rather than editing silently.

What I got wrong and why. I searched gh search code "SubscribeTo" --owner MSXOrg, because this page names MSXOrg/Custo as the runtime. Scoping the search to where the documentation said to look is precisely the failure this issue is about, and I walked into it while writing the issue. Searching --owner PSModule returns PSModule/Distributor/scripts/Sync-Files.ps1 — the predecessor engine, and the only consumer of SubscribeTo in either organization. Credit to the agent working PSModule/CasingStyle#22, who found it.

What is actually true, verified directly:

Check	Result
Sync Managed Files runs, all time	76 — 3 success, 73 failure, 0 cancelled
The three successes	all on 2026-04-05, within two hours
After that	63 consecutive failures, daily, through 2026-06-05
Workflow state now	disabled_inactivity — GitHub switched it off
MSXOrg/Custo created	2026-07-25, seven weeks after the last run

powershell gh api repos/PSModule/Distributor/actions/workflows --jq '.workflows[] | "\(.name) state=\(.state)"' gh api "repos/PSModule/Distributor/actions/workflows/sync-files.yml/runs?status=failure&per_page=1" --jq '.total_count'

So the gap is roughly four months old and has a specific shape: a runtime that succeeded on one day, failed every day after, was switched off for inactivity, and had a successor created as a stub seven weeks later. Not "never built".

This changes the classification, and that is the substantive part. The body previously grouped this with #106 and MSXOrg/docs#152 as a third instance of "configuration and reality disagree, nothing fails". It is the inverse. Those two were silent. This failed loudly 63 times and reached nobody, then went quiet — and quiet reads like health. The remedy for the silent cases is to inspect the artifact instead of the status; that does not help here, because the status was red and unread. The body now records the consequence: the page should name an owner expected to notice, not only a runtime expected to run.

Two additions to the plan follow from it: read Sync-Files.ps1 and capture the semantics it assigns each SubscribeTo value before any successor is written, since it is the only definition of what a subscription means; and note that sync-files.yml already authenticates as CUSTO_BOT_CLIENT_ID, so the Custo identity predates the Custo repository and is the right starting point for auditing fleet write access.

[MariusStorhaug]

Correcting my own comment above. Two of the numbers I contributed were wrong, and the corrected figures make the conclusion stronger rather than weaker.

Figure	What I posted	Actual
Successful runs	8	3
Window	"last 100"	all 76 runs, all time
First run	not stated	2026-03-27 — a failure
The successes	implied a working period ending 2026-04-05	all three on 2026-04-05, inside two hours

# wrong: filters by repository, so it counts every workflow in it
gh run list --repo PSModule/Distributor --limit 100 --json conclusion --jq 'group_by(.conclusion) | map("\(.[0].conclusion): \(length)")'
# ["failure: 73","success: 8"]

# right: filters by the workflow the claim is about
gh api 'repos/PSModule/Distributor/actions/workflows/sync-files.yml/runs?per_page=100' --jq '[.workflow_runs[].conclusion] | group_by(.) | map("\(.[0]): \(length)")'
# ["failure: 73","success: 3"]

PSModule/Distributor also hosts a Copilot coding agent workflow with five successful runs. My query grouped by conclusion across the whole repository, so those five landed in the distribution total. I scoped the query by repository when the claim was about a workflow.

What changes. I wrote that "a working runtime broke on 2026-04-05". That is not what the data says. Sync Managed Files has succeeded on exactly one day in its entire history — three runs between 09:13 and 11:15 UTC on 2026-04-05 — out of 76 attempts beginning 2026-03-27, which was itself a failure. So this was never a working mechanism that regressed; it worked once and otherwise did not.

That matters for the fix. "Restore Distributor, or port it to Custo" assumes there is a working implementation to restore or port. There is roughly one green day of evidence that Sync-Files.ps1 ever did the job. It remains valuable as the only written definition of what each SubscribeTo value means — the plan item above still stands — but it should be read as a specification of intent, not as a proven implementation.

The disabled_inactivity state and the 2026-07-25 Custo creation date are unchanged and were correct.