package-maplisted

Two sources, and they answer different halves of the question. ``` pdkit packages --of packages/main/src/plugin/exec.ts # which package owns a path pdkit packages # every package, by layer ``` The generated map (`$PDKIT_HOME/package-map.json`, built by `pdkit init` from `pnpm-workspace.yaml`) knows what exists. `knowledge/package-map.md` holds what a generator cannot know: intent, boundaries, and why the layer order is what it is. Answer from the first, explain from the second. ## What a complete answer contains Not just the package — the **layer**, and what the layer implies: ``` extension-api → main → preload → renderer + ui → extensions/* → tests → website/docs ``` That order does two jobs at once. It is merge order, because upper layers depend on lower ones. And it is **reviewer selection**: the people who review a public API change are not the people who review a UI change, so a change spanning both waits for both. That is why layers decide slicing, and why "which layer" is usually the more useful half of the answer. ## The boundary that catches people Utilities get duplicated between `packages/main` and `packages/renderer`. Before concluding that a helper needs writing, look in both — reviewers do, and they push back on it. The other one: `packages/extension-api` is a public contract. A type that looks like an internal utility can be declared there too, which makes changing it a compatibility question rather than a ref