> Part of the **Plugin & Package System** epic #20. Phase 3 (foundation/MVP). ## Goal Implement **package discovery** and the in-memory **package graph**: find installed packages, parse + validate their `turian-package.json` manifests, and expose a resolved list (with metadata and dependency edges) to the build pipeline (#D/#E/#F), the CLI (#G), and the editor (#H). Dependency *resolution* (versions/conflicts/cycles) is delegated to Zig's package manager per the #A ADR — this issue builds the Turian-side view on top. ## Context / integration points - Projects gain a `build.zig.zon` in #B; third-party deps (incl. packages) are fetched by `zig fetch` into the Zig global cache and referenced by hash. Turian needs to map those resolved dependencies back to their `turian-package.json` manifests to know *what kind* of package each is and *how* to integrate it. - Asset-only packages may have **no** `build.zig.zon` (no code) — discovery must also handle locally-vendored / path packages that are pure assets. - New module lives in `editor/` (pure logic, no GUI), e.g. `editor/PackageManager.zig` + `editor/types/PackageManifest.zig`. Mirror the existing `AssetDatabase`/`Scanner` patterns (allocator-based, testable, `serde`/`std.json` for parsing). ## Design - `PackageManifest` type (parses `turian-package.json`; matches the #A schema). Use the project's JSON convention. - `PackageManager`: - `discover(io, project_path)` — enumerate installed packages from (a) the project's resolved Zig deps that carry a `turian-package.json`, and (b) a project-local vendored packages dir for asset-only packages. Decide the canonical install location in the issue. - Build a `PackageGraph` (nodes = packages, edges = declared deps) for the editor graph view (#H) and validation. - Validate: manifest schema, `engine_compat` against the running engine version, GUID/virtual-path collisions across packages (policy from #A). - Expose typed queries: `assetRoots()`, `sourceModules()`, `nativeLibs()`, `plugins()` for the build seam (#B) to consume. - Surface errors as structured diagnostics (not panics) so CLI/editor can present them. ## Tasks - [ ] `editor/types/PackageManifest.zig` — parse + validate `turian-package.json` per #A schema; unit tests with fixtures - [ ] `editor/PackageManager.zig` — discovery across resolved Zig deps + asset-only vendored packages - [ ] Build the `PackageGraph` (nodes/edges) and detect collisions (GUID, virtual path, duplicate package name) - [ ] `engine_compat` validation against the engine version - [ ] Typed accessors (`assetRoots`/`sourceModules`/`nativeLibs`/`plugins`) feeding the #B build seam - [ ] Structured diagnostics type for CLI/editor consumption - [ ] Export from `editor/root.zig`; unit tests (fixtures from the #A example layout) ## Acceptance criteria - Given a project with N installed packages (asset + source + native + asset-only), `discover()` returns all N with correct types and metadata. - Invalid/incompatible manifests produce structured diagnostics, not crashes. - Cross-package GUID and duplicate-name collisions are detected and reported. - The build seam from #B can pull asset roots / modules / native libs / plugins out of the resolved graph. - Unit tests cover parse, validation, collision, and engine-compat paths. ## Dependencies Depends on #A (manifest schema) and #B (project `build.zig.zon` + resolution model). Blocks #D, #E, #F, #G, #H. ## Out of scope Build/asset/codegen wiring (#D/#E/#F), CLI commands (#G), UI (#H). Remote fetching beyond what Zig's PM already does.