Remove Implementation Plan section

Arbitrary timelines and obvious phases don't add value to the RFC.
Implementation details will be figured out during implementation.

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

Author: JAORMX

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

@@ -368,43 +368,6 @@ import "github.com/stacklok/toolhive-core/logger"
 - **Optional features**: New features use functional options pattern
 - **Version constraints**: Consumers can pin to major versions for stability
 
-## Implementation Plan
-
-### Phase 1: Repository Setup (Week 1-2)
-
-- Create `stacklok/toolhive-core` repository
-- Set up CI/CD (linting, testing, release automation)
-- Establish CODEOWNERS and contribution guidelines
-- Document graduation criteria in STABILITY.md
-
-### Phase 2: Initial Package Migration (Week 3-4)
-
-- 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
-
-### Phase 3: Consumer Migration (Week 5-8)
-
-- Update `toolhive` to import from `toolhive-core`
-- Update `dockyard` to import from `toolhive-core` (currently imports `pkg/logger`, `pkg/container/images`, `pkg/runner`)
-- Update `toolhive-registry` to import from `toolhive-core` (currently imports `pkg/logger`, `pkg/permissions`, `pkg/registry/*`)
-- Offer `toolhive-registry-server` the option to adopt toolhive-core (may choose to continue with slog)
-- Deprecate original packages with forwarding imports
-- Monitor for issues and release patches as needed
-
-### Phase 4: Tier 2 Evaluation (Ongoing)
-
-- Evaluate secrets, auth/oauth, transport/types for graduation
-- Create graduation RFCs for approved packages
-- Release minor versions with new packages
-
-### Dependencies
-
-- Go 1.25+ (matching minimum version across toolhive ecosystem)
-- GitHub Actions for CI/CD
-- goreleaser for release automation
-
 ## Testing Strategy
 
 ### Unit Tests