Support GitHub-based community lint rule discovery and lifecycle management #616

Goal

Let Wright users discover, install, update, and version community lint rule packages hosted in GitHub repositories. Reuse Magpie's GitHub discovery and Skill Library lifecycle-management approach, but apply it only to Wright lint rules.

Context

#309 / WRI-480 defines the declarative lint rule and project policy boundaries while explicitly deferring remote distribution. Community rule authors should be able to publish and maintain compatible rules independently of Wright releases.

Magpie provides working reference mechanisms:

• GitHub Topics discovery
• Source-aware unified installation and updates
• Remote revision/change checks
• Local modification protection

Magpie's Skill and agent functionality is not a Wright product requirement.

Scope

• Discover public lint-rule repositories by a Wright-specific GitHub Topic; also support installation by explicit repository URL without requiring the Topic.
• Identify and validate installable rules against Wright's approved declarative lint-rule contract; support multiple rules in one repository without inventing a second rule format.
• Manage installed packages in a Wright-owned local location. Retain source repository, package/path identity, and immutable installed Git revision.
• Expose user-facing install, list, check-updates, update (one/all), and remove operations. Update checks must report changes without applying them.
• Keep managed files separate from user-authored rules. Never silently overwrite locally changed files or unrelated content.
• Allow projects and CI to select reproducible rule-package revisions, so unrelated global updates cannot silently change effective lint behavior.
• Surface missing sources, incompatible rule schemas, namespace collisions, and remote check failures explicitly. Reuse existing rule IDs, policy levels, and structured findings.
• Use existing Wright update/configuration mechanisms where suitable; add only the minimum GitHub querying/caching necessary for practical use.

Proposed community repository format

Treat one GitHub repository as one lint package. A public community package uses the GitHub Topic wrightkit-lint (proposed naming); direct repository URLs work without the Topic.

example-lint-repo/
├── README.md         # community description and instructions
├── LICENSE           # terms for redistribution
├── rules/            # only required machine-readable entry point
│   ├── short-wait.yaml
│   └── repeated-effect.yml
└── tests/            # optional, conventional runnable tests

• rules/ contains one declarative rule per .yaml or .yml file, with files directly inside the directory. Follow Wright's existing lexically ordered, non-recursive --rule rules/ loader.
• Each file uses the existing SPEC-309 rule schema: id, optional document-level locale (default en-US), metadata, and matcher. Required metadata currently includes summary, rationale, documentation, known-limits, and tags.
• IDs retain the existing <namespace>/<rule-id> contract, with wright reserved. Recommend one consistent namespace per repository, without adding a new package-to-namespace mapping protocol; reject duplicate effective rule IDs.
• Rule files never specify project severity or enabled; those belong to the consuming project's existing lint policy. Installing a package must not automatically activate it in unrelated projects.
• Use the GitHub owner/repo as package identity and a resolved commit SHA as the installed version. Git tags may be user-facing selectors but must resolve to immutable commits. Do not require package.json, a new lint-package.yaml, dependency graph, or rule-level version fields.
• README.md and LICENSE are publication requirements for community discovery. Rule validation itself only needs rules/ and compatible YAML files. tests/ is optional and may use ordinary Wright CLI integration tests; do not invent another test description format.
• Repository content is data, not executable code. Ignore other repository files during rule loading. Refuse empty, malformed, incompatible, or conflicting packages with explicit diagnostics.
• The project pin/selection mechanism is part of this issue's distribution design; it may extend existing project lint configuration as needed, but must not silently redefine the already accepted YAML rule syntax. Avoid a second lock/manifest unless a concrete reproducibility requirement needs it.

Example rule

id: workshop-performance/short-wait
locale: en-US
metadata:
  summary: A while loop contains a 0.1-second Wait
  rationale: Short waits in loops can warrant inspection.
  documentation: Reports a static match; it does not measure runtime cost.
  known-limits: A matching wait is not necessarily a performance defect.
  tags: [performance]
matcher:
  scope: while
  actions:
    - kind: call
      name: Wait
      args:
        - number: 0.1
      count: { min: 1 }

This is a proposed distribution convention, not a claim that remote packages or project pinning already work. Validate it against the current rule loader and at least one realistic community repository before freezing the public package contract.

Non-goals

• Installing/managing community Agent Skills or syncing any content to coding agents.
• A general plugin host, JS/WASM/native rule execution, or arbitrary repository code execution.
• A new lint matcher DSL, independent semantic model, or changes to Workshop/OPY/DEL ownership.
• A hosted marketplace, new central registry, or automatic background upgrades.
• Copying Magpie's complete library data model, backup system, or multi-agent synchronization.

Acceptance criteria

• A compatible rule package is discoverable by Topic or installable via repository URL, with its source and installed revision inspectable.
• Wright can load installed declarative rules through the approved lint execution path, without bypassing its semantic ownership or policy contract.
• Users can check for and explicitly apply individual or bulk updates; unchanged, updated, and unavailable/error states are distinguished.
• Updates/removal preserve user-owned files, and locally edited managed content is not silently replaced.
• Project rule selection is reproducible in CI after other local/global packages change.
• Invalid/incompatible rules, duplicate identities, and network failures produce actionable results without unverified lint findings.
• Focused tests cover discovery, install/update/remove, revision pinning, collision/failure behavior, and project reproducibility.
• An independent design ablation verifies that additional manifests, global state, copy layers, or backup machinery are strictly necessary before retaining them.

Ownership / dependencies

• wright: community discovery, installation/update lifecycle, version resolution, rule selection, lint integration, and user-facing commands.
• workshop-rs / source-language owners: canonical/source semantics; community rules may consume only supported Wright-exposed semantic/query contracts.
• Dependency: Define an extensible analysis and lint rule contract #309's accepted rule format and execution contract. Do not assume historical Issue closure proves that the current loader/runtime is implemented. Inspect current code before implementation.