Address review feedback on RFC

- Fix Tier 1 package list in Phase 2 (was incorrectly listing logger/healthcheck)
- Change Tier 1 packages from "Stable (v1)" to "Beta" (v0.x = no stability guarantee)
- Add "no global state" graduation criterion
- Add permissions package scope to open questions
- Remove verbose Go code example from Stability Levels section

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

Author: JAORMX

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

@@ -101,6 +101,7 @@ A package must meet ALL of the following criteria to graduate to `toolhive-core`
 | **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 |
 
 #### 2. Quality Requirements
 
@@ -160,19 +161,11 @@ sequenceDiagram
 
 ### Stability Levels
 
-`toolhive-core` packages use explicit stability markers:
-
-```go
-// Package logger provides structured logging for ToolHive services.
-//
-// Stability: Stable (v1)
-// Since: v0.1.0
-package logger
-```
+Each package in `toolhive-core` is marked with a stability level in its godoc:
 
 | Level | Meaning | API Guarantees |
 |-------|---------|----------------|
-| **Stable (v1)** | Production-ready, fully supported | No breaking changes without major version bump |
+| **Stable** | Production-ready, fully supported | No breaking changes without major version bump |
 | **Beta** | Feature-complete, may have minor changes | Breaking changes possible with deprecation notice |
 | **Alpha** | Experimental, subject to significant changes | No stability guarantees |
 
@@ -199,12 +192,14 @@ These packages meet all graduation criteria (zero ToolHive-specific coupling, we
 
 | Package | Current Location | Stability | Rationale |
 |---------|------------------|-----------|-----------|
-| **errors** | `pkg/errors/` | Stable (v1) | HTTP-aware error handling, zero deps, 10mo stable |
-| **oauth** | `pkg/oauth/` | Stable (v1) | RFC-compliant OAuth/OIDC types, fosite dep only |
-| **env** | `pkg/env/` | Stable (v1) | Testable environment access, zero deps |
-| **permissions** | `pkg/permissions/` | Stable (v1) | Container permission profiles, stdlib-only, security validations |
-| **validation** | `pkg/validation/` | Stable (v1) | RFC 7230 HTTP header validation, security-focused |
-| **versions** | `pkg/versions/` | Stable (v1) | Build metadata, User-Agent generation |
+| **errors** | `pkg/errors/` | Beta | HTTP-aware error handling, zero deps, 10mo stable |
+| **oauth** | `pkg/oauth/` | Beta | RFC-compliant OAuth/OIDC types, fosite dep only |
+| **env** | `pkg/env/` | Beta | Testable environment access, zero deps |
+| **permissions** | `pkg/permissions/` | Beta | Container permission profiles, stdlib-only, security validations |
+| **validation** | `pkg/validation/` | Beta | RFC 7230 HTTP header validation, security-focused |
+| **versions** | `pkg/versions/` | Beta | Build metadata, User-Agent generation |
+
+> **Note**: All packages start as Beta in v0.x releases. Once the library reaches v1.0.0, packages meeting all graduation criteria will be promoted to Stable.
 
 **Proposed `toolhive-core` structure:**
 
@@ -405,7 +400,7 @@ import "github.com/stacklok/toolhive-core/logger"
 
 ### Phase 2: Initial Package Migration (Week 3-4)
 
-- Extract Tier 1 packages: logger, errors, validation, healthcheck, versions, env
+- Extract Tier 1 packages: errors, oauth, env, permissions, validation, versions
 - Ensure 100% test parity with original implementations
 - Write package documentation and examples
 - Tag v0.1.0 release
@@ -470,8 +465,9 @@ import "github.com/stacklok/toolhive-core/logger"
 ## Open Questions
 
 1. **Release cadence**: Monthly minor releases, or release when ready?
-2. **Tier 2 timeline**: When should we start refactoring logger/healthcheck/tokenexchange for graduation?
-3. **Logger refactoring approach**: When decoupling logger from Viper, should we use zap with config injection, switch to slog, or provide an interface that supports both?
+2. **Tier 2 timeline**: When should we start refactoring healthcheck/tokenexchange for graduation?
+3. **Logger approach**: When decoupling logger from Viper, should we use zap with config injection, switch to slog (stdlib), or provide an interface that supports both?
+4. **permissions package scope**: Is `pkg/permissions` (container security profiles) generic enough for a shared library, or is it too domain-specific to ToolHive?
 
 ## References