Skip to main content
The AI•Pkg server is built by forking NuGetGallery, stripping everything that doesn’t translate to the AI plugin registry use case, and building the AI•Pkg-specific surface on top. The migration is structured into four phases so that core infrastructure (Phases 0–1) can be verified independently before UI (Phase 3) and CLI (Phase 4) work begins.
The existing NuGetGallery.sln (139 projects) is not converted. A new AI•Pkg.slnx is created from scratch, pulling in only the source files and projects that are being retained.

Pre-Migration: Fork Setup

1

Fork the repo

Fork NuGet/NuGetGalleryAI•Pkg/AIpkgGallery on GitHub.
2

Create dev branch

Create a dev branch from main for migration work.
3

Protect main

Do not push breaking changes to main until Phase 1 is complete and tested.
4

Add specs

Add the src/AI•Pkg.Docs/ directory to the fork (already done).

Phase 0: Clean Solution Foundation

Goal: A buildable ASP.NET Core 10 SLNX solution with SQL Server DB Project and EasyAF scaffolding, no legacy code.

Step 0.1: Create AI•Pkg.slnx

Create a new Visual Studio SLNX solution file at the repo root. Add projects incrementally as they are created.

Step 0.2: Create Core Projects

Step 0.3: Set Up SQL Server Database Project

Step 0.4: EasyAF Code Generation

Run EasyAF CLI against AI•Pkg.Server.Db/ to generate:
  • EF Core 10 entity classes → AI•Pkg.Server.Data/Entities/
  • Repository classes → AI•Pkg.Server.Data/Repositories/
  • AIpkgDbContext.csAI•Pkg.Server.Data/
Generated files are committed to the repo and regenerated whenever the DB project changes.

Phase 0 Verification

  • dotnet build AI•Pkg.slnx succeeds with zero errors
  • dotnet test on AI•Pkg.Core.Tests and AI•Pkg.Server.Tests passes
  • DB project publishes successfully to a local SQL Server instance
  • EasyAF-generated entities compile against the DB project schema

Phase 1: Core Registry API + Auth + AI•Pkg.Core

Goal: Working push, download, registration, and authentication. Package round-trip: aipkg packaipkg pushaipkg install.

Source Files to Port

Step 1.1: AI•Pkg.Core Implementation Order

1

AipkgManifest model

Implement AipkgManifest model with System.Text.Json source-gen serialization.
2

AipkgReader

ZIP reading and manifest extraction.
3

AipkgWriter

ZIP creation.
4

PlatformCompatibilityService

APM fallback graph (hardcoded table for now).
5

AipkgValidator

Manifest validation + archive validation.
6

AipkgVersion

SemVer parsing and range checking.
Write unit tests for each in AI•Pkg.Core.Tests.

Step 1.2: Registry API Endpoints

Implement Minimal API endpoints in AI•Pkg.Server/Api/V3/:
Search and autocomplete endpoints are added in Phase 2 (they depend on Azure AI Search).

Phase 1 Verification

  • aipkg pack {id}.aispec produces a valid {id}.{version}.aipkg
  • aipkg push {package}.aipkg succeeds against a local server instance
  • GET /v3/flatcontainer/{id}/{version}/{id}.{version}.aipkg returns the uploaded package
  • GET /v3/registration/{id}/index.json returns valid registration data
  • aipkg verify {package}.aipkg exits 0 for a valid package, 1 for invalid
  • API key auth blocks unauthorized pushes with 401

Phase 2: Search + Catalog Pipeline

Goal: Functional search and autocomplete. Packages appear in search results after push.

Source Files to Port

Phase 2 Verification

  • Pushing a package makes it appear in GET /v3/search?q={id} within 60 seconds
  • GET /v3/search?apm=claude-code returns only claude-compatible packages
  • GET /v3/search?capability=mcp-server filters correctly
  • GET /v3/autocomplete?q={prefix} returns matching package IDs
  • Download count increments after each package download (within stats job cycle)

Phase 3: Blazor Web UI

Goal: Full public-facing web UI. Users can browse, search, view packages, upload, and manage accounts via browser. Build all Blazor components as defined in Registry UI spec. No porting of Razor views — build fresh. Implementation order:
  1. Layout components (NavBar, Footer, MainLayout)
  2. Package detail page (most important for discoverability)
  3. Search / browse pages
  4. Home page
  5. Upload wizard
  6. Account / API key management
  7. Admin panel

Phase 3 Verification

  • Home page loads and shows featured/new packages
  • Search returns results with correct filtering by APM and capability
  • Package detail page shows README, manifest, version history
  • Version selector switches versions without full page reload
  • Upload wizard accepts a valid .aipkg and publishes successfully
  • API key management allows create/revoke
  • All public SSR pages score ≥90 on Lighthouse SEO and Performance
  • WCAG 2.1 AA automated checks pass

Phase 4: aipkg CLI MVP

Goal: Functional install, restore, remove, list, search commands. Single-binary Native AOT release. Add remaining CLI commands (see SDK Interface spec): install, restore, remove, list, search, info, sources, new, login, logout Configure Native AOT publishing pipeline in GitHub Actions. Publish to GitHub Releases.

Phase 4 Verification

  • aipkg install git-helpers downloads, extracts, and installs to .claude/ (on claude-code)
  • aipkg restore installs all packages from aipkg.config.json
  • aipkg.lock.json is written with correct hashes and resolved versions
  • aipkg remove git-helpers cleans up installed files
  • aipkg search mcp returns results from aipkg.org
  • Native AOT binary runs on Windows, macOS, Linux without .NET runtime installed
  • Binary size < 30 MB per platform

What to Delete from NuGetGallery

Entire Projects / Directories

Files Within Retained Projects


Project Rename Reference


Critical Source Files to Reference

Read these NuGetGallery files before implementing the corresponding AI•Pkg components:

Open Items / Lower Priority