Add two-track graduation system with relaxed criteria

- Fast Track: For simple packages (env, errors, validation)
  - 1 month production usage
  - 70% coverage
  - GitHub issue approval by one maintainer

- Standard Track: For complex packages
  - 2 months production usage
  - 70% coverage
  - RFC or detailed issue review

Reduces friction for obvious candidates while maintaining rigor
for complex packages.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Author: JAORMX

rfcs/THV-0032-toolhive-core-shared-library.md

@@ -91,73 +91,51 @@ flowchart TB
 
 ### Package Graduation Criteria
 
-A package must meet ALL of the following criteria to graduate to `toolhive-core`:
+Packages can graduate via two tracks depending on complexity:
 
-#### 1. Stability Requirements
+#### Fast Track (Simple Packages)
+
+For small, focused packages with minimal dependencies (e.g., `env`, `errors`, `validation`):
 
 | Criterion | Requirement |
 |-----------|-------------|
-| **Production usage** | Deployed in production for ≥3 months without breaking changes |
-| **API stability** | No breaking changes in the last 2 minor releases |
-| **Interface design** | Uses Go interfaces for dependency injection and testability |
-| **Error handling** | Returns typed errors; no panics except for programming bugs |
+| **Production usage** | Deployed in production for ≥1 month |
+| **No internal dependencies** | Cannot depend on non-graduated internal packages |
 | **No global state** | No singletons, global variables for state, or `init()` side effects |
+| **Test coverage** | ≥70% line coverage |
+| **Documentation** | Package-level godoc |
+| **Approval** | GitHub issue approved by one maintainer |
+
+#### Standard Track (Complex Packages)
 
-#### 2. Quality Requirements
+For packages with external dependencies, multiple types, or broader API surface:
 
 | Criterion | Requirement |
 |-----------|-------------|
-| **Test coverage** | ≥80% line coverage with meaningful assertions |
-| **Mock support** | Interfaces have mock implementations (mockgen or similar) |
+| **Production usage** | Deployed in production for ≥2 months without breaking changes |
+| **API stability** | No breaking changes in the last 2 minor releases |
+| **Interface design** | Uses Go interfaces for dependency injection and testability |
+| **Error handling** | Returns typed errors; no panics except for programming bugs |
+| **No global state** | No singletons, global variables for state, or `init()` side effects |
+| **Test coverage** | ≥70% line coverage with meaningful assertions |
 | **Documentation** | Package-level godoc with usage examples |
 | **Linting** | Passes `golangci-lint` with project configuration |
-
-#### 3. Dependency Requirements
-
-| Criterion | Requirement |
-|-----------|-------------|
 | **Minimal dependencies** | Only essential external dependencies |
 | **No circular imports** | Must not create import cycles when extracted |
 | **No internal dependencies** | Cannot depend on non-graduated internal packages |
 | **Stable external deps** | External dependencies must be v1.0+ or widely adopted |
-
-#### 4. Governance Requirements
-
-| Criterion | Requirement |
-|-----------|-------------|
 | **Sponsorship** | At least one maintainer sponsors the graduation |
-| **RFC approval** | Graduation proposal reviewed and approved |
-| **Migration plan** | Clear plan for consumers to adopt the graduated package |
+| **Approval** | RFC or detailed GitHub issue reviewed and approved |
 
 ### Graduation Process
 
-```mermaid
-sequenceDiagram
-    participant C as Contributor
-    participant M as Maintainers
-    participant RFC as RFC Process
-    participant Core as toolhive-core
-
-    C->>M: Propose package graduation
-    M->>M: Evaluate against criteria
-    alt Criteria not met
-        M->>C: Feedback: criteria gaps
-        C->>C: Address gaps
-    else Criteria met
-        M->>RFC: Create graduation RFC
-        RFC->>M: Review & approval
-        M->>Core: Extract package
-        M->>Core: Release new version
-        M->>C: Update consumer repos
-    end
-```
-
-1. **Proposal**: Contributor or maintainer identifies a graduation candidate
-2. **Evaluation**: Maintainers assess the package against all graduation criteria
-3. **RFC**: Create a lightweight RFC documenting the graduation (can be a GitHub issue for simple cases)
-4. **Extraction**: Move package to `toolhive-core` with necessary adaptations
-5. **Release**: Tag a new semver release of `toolhive-core`
-6. **Migration**: Update consuming projects to import from `toolhive-core`
+1. **Proposal**: Open a GitHub issue identifying the graduation candidate and proposed track (fast/standard)
+2. **Track determination**: Maintainers confirm which track applies based on package complexity
+3. **Evaluation**: Assess against the relevant track's criteria
+4. **Approval**: Fast track requires one maintainer approval; standard track requires RFC or detailed issue review
+5. **Extraction**: Move package to `toolhive-core` with necessary adaptations
+6. **Release**: Tag a new semver release of `toolhive-core`
+7. **Migration**: Update consuming projects to import from `toolhive-core`
 
 ### Stability Levels