Correct the custom property values on PSModule/GitHub

[MariusStorhaug]

PSModule/GitHub carries custom property values that look like leftovers from testing the property schema. One of them, Archive: true, means "no longer maintained" per the Repository Standard — and the standard states that automation selects repositories by custom property, so any future filter on Archive will silently skip the organization's most-used module.

Observed behavior

gh api repos/PSModule/GitHub/properties/values --jq '.[] | "\(.property_name) = \(.value)"'
# Archive = true
# Description = This is a test
# SubscribeTo = ["Custom Instructions","License","Prompts"]
# Type = Module
# Upstream = https://github.com

Against what the repository actually is:

gh api repos/PSModule/GitHub --jq '"archived=\(.archived) pushed=\(.pushed_at) stars=\(.stargazers_count)"'
# archived=false pushed=2026-07-27T11:32:48Z stars=29

Three values disagree with the standard's definitions:

Property	Value	Definition	Reality
Archive	true	"Set to true only when the repository is no longer maintained."	Not archived on GitHub, pushed 2026-07-27, 29 stars, v0.43.1 released 2026-04-14
Description	This is a test	"Optional machine-readable description for automation that needs it independently of the GitHub repository description."	The real description is "A PowerShell module to interact with GitHub, both interactively and via automation."
Upstream	https://github.com	"Set when the module wraps, mirrors, or is generated from an upstream project."	Not a project URL; the module is not generated from an upstream source

Expected behavior

Custom property values describe the repository accurately, so automation that selects on them behaves as the standard says it will.

Reproduction

Read the property values and compare each against its definition in the Repository Standard's custom properties table.

Environment

PSModule organization custom properties; PSModule/GitHub.

Regression

Unknown. The values are consistent with the schema having been exercised on a live repository while it was being set up. PSModule/GitHub is also the only one of 58 module repositories with SubscribeTo set, which supports that reading.

Workaround

None needed today — see below; nothing currently reads these values. The exposure is latent.

Acceptance criteria

• Archive reflects whether the repository is actually unmaintained.
• Description either carries a real machine-readable description or is unset.
• Upstream either names a genuine upstream project or is unset.
• A decision is recorded on whether the remaining 57 module repositories carry similar leftovers.

References

• State the real status of managed file distribution on the Repository Standard #109 — SubscribeTo on this same repository is the organization's only instance, and is inert; found in the same audit.
• Reconcile the Repository Defaults required-files tables with what Template-PSModule ships #103 — reconciling documented repository facts with reality. Same class, different surface.

---

Technical decisions

Impact is latent, not live, and the issue should not overstate it. The catalog builder in this repository (.github/actions/update-index) reads the Type property and the repository's GitHub description, and does not filter on Archive — checked directly in src/Helper.psm1. So nothing is visibly broken today. The problem is that the standard tells automation authors to select on custom properties, so the first consumer that honours Archive will drop the flagship module without any error. Wrong data that nothing reads yet is a trap set for the next author, not an outage.

Why fix rather than leave. These are the values a maintainer would look at to learn what the properties mean. Description: "This is a test" on the organization's most-used module is also the example a newcomer meets first.

Archive is unambiguous; the other two need a decision. Clearing Archive follows directly from the definition and the repository's state. Whether Description and Upstream should be corrected or unset depends on whether the organization wants them populated at all, which is a convention question rather than a data-correctness one.

Scope, and the deliberate limit. Three property values on one repository, plus a decision about auditing the rest. This issue does not audit the other 57 — that is a separate sweep and is called out as an acceptance criterion so it is not silently dropped. There is no pull request to make here: custom property values are organization data, changed through gh api, which is why this is filed rather than fixed directly.

---

Implementation plan

• Confirm the values are unintentional rather than deliberate before changing anything.
• Clear Archive on PSModule/GitHub.
• Decide whether Description and Upstream should be corrected or unset, and apply the choice.
• Sweep the remaining 57 props.Type:Module repositories for values that disagree with their definitions, and record the result.
• Record on State the real status of managed file distribution on the Repository Standard #109 whether anything should validate property values against the standard, given three of them drifted unnoticed on one repository.