Expand repo taxonomy to 9 types and add public repository policy

[Ethan-Arrowood]

Summary

Iterates the repo taxonomy from the initial 5-type model into a 9-type model, and adds a companion public repository policy document.

Taxonomy (docs/repo-taxonomy.md)

• Replaces the catch-all core type with five sharper types: product, plugin, application, library, and meta — keeping template, example, guide, and snapshot.
• Splits by contract: plugin/application/library track Harper closely; product is independently versioned; meta is public-but-not-a-product; snapshot is frozen.
• Adds a classification decision tree (mermaid) and a per-type section for each, with upgrade & testing guidance.
• Links Plugin/Application to the Harper component reference docs so it's unambiguous these mean literal Harper components.

Policy (docs/repository-policy.md, new)

The human- and agent-readable reference for managing active, public repos. Baseline commitments:

• Clear ownership + a standing maintenance commitment
• Exactly one taxonomy type, declared as a GitHub topic
• Required meta docs (LICENSE, README)
• A declared Harper version via dependencies/peerDependencies or engines (semver)
• Testing/upgrades per the repo's taxonomy type

Plus a Public Archived section (archived ≠ deleted, when to archive, keep-public vs. move-internal, the required archive README note, and when deletion is warranted).

The two docs cross-link each other. Internal/private repos are explicitly out of scope (separate policy to come).

Marked as WIP in the doc itself — automated enforcement tooling is planned; this is the reference until then.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the Harper Public Repository Taxonomy and introduces a new Harper Public Repository Policy to establish clear maintenance contracts for public repositories. The review feedback identifies a minor grammatical omission, a logical gap in the classification decision tree for repositories that do not contain a config.yaml file, and a broken reference in the policy document pointing to a deleted section of the taxonomy.

[kriszyp]

This looks good to me. I think one of the more important aspects of this is that it should be a stronger gate to creating new templates, examples, plugins, etc.; if there isn't a commitment to maintenance, than it can't be defined as one of those.