@projectplaceholders/setup

What a correctly configured project looks like, written down once. pkit init reads it to know what to write; pkit doctor reads it to know what to report.

Why one description and not two

A checker and a fixer that each decide for themselves what "set up" means will eventually disagree, and the shape that failure takes is the worst one available: doctor finds a problem, init says there is nothing to do, and the loop never closes. So there is one inspect(), and both commands are views of its result.

pkit init

Adds the Kit to a repository that already exists — which is nearly all of them.

• Detects the stack from the dependencies (next → react-library → node) and says what the guess was based on, so a wrong one can be argued with rather than merely overridden with --stack.
• Writes what is missing: tsconfig.json, an ESLint config, CONTEXT.md, and the agent rules via pkit context sync.
• Never replaces a file the project already decided on. A config that is already there is reported with the one line that would wire it to the Kit, and left untouched. Merging two configurations is a judgement no tool should make quietly. --force overrides.
• Adds dependencies without rewriting any. A version already pinned in package.json is somebody's decision. New entries are appended rather than sorted in, and the file's own indentation is kept — a reformat is a change nobody asked for.

Writing a tsconfig.json that extends a package the project does not depend on would ship a configuration that is broken the moment it is read, so the manifest is part of the job, and init ends by naming the project's own package manager rather than guessing npm.

pkit doctor

pkit check reports what it found. doctor reports what it is able to look at, which is the more dangerous half — a checker that never ran leaves no trace in a clean result. A project with no tsconfig.json passes every type check it has.

What `pkit check` covers here
  ✔ typescript    runs
  ✔ eslint        runs
  · context-docs  skipped — no src/features directory in this project
  ✔ agent-rules   runs

It also reports the three failures that look like something else:

• Configuration that is not wired to the Kit — the extends chain is followed, so a package that reaches the preset through a shared local config counts as configured. Reporting that as unconfigured would be wrong in every monorepo.
• Dependencies missing or not installed — until they are there the checkers that need them are skipped, and a skipped checker still reports clean.
• Version skew between the Kit packages — compiler options from one version and lint rules from another means the project is checked against a combination nobody tested, and every explanation for the resulting errors points at the wrong place.

Workspaces

A workspace root is not an application. Its packages own the compiler options and the lint rules; what belongs at the root is the CLI and the documents that describe the repository. doctor says so instead of diagnosing the root as a broken app, and the CLI counts as present when it can be run from here — walking up to the nearest node_modules/.bin rather than reading one package.json.