@projectpac/packages-checkouts

A registry name, answered from a working tree on this machine.

A dev node has to run the code beside it rather than the code npm last served. Saying so used to mean naming every path at setup -- --package-source, then --executor-package, then a --seed per plugin -- and installing each one again with plugins add --source, which fetches nothing and reads no manifest. The lane meant to prove a node works was the one lane that never ran the install path. What was missing was not another flag: it was a source that answers a name.

• It answers a name, not a path. plugins add --package @projectpac/skills is what a person on a released node types, and it is what a lane types too. The difference is which source served it.
• A name it has no checkout for is not an error. The host asks every enabled source in turn, so a node with this and the npm source runs local code where local code exists and fetches the rest -- which is what a machine with half the repositories cloned actually looks like.
• An exact version or none. A checkout is one version, so the only question worth asking is whether it is the one named. A range is left to a source with more than one to choose from, rather than answered by carrying a semver implementation to say yes either way.
• The bytes come in through the npm source's path fetch. That is where --ignore-scripts, the prefix bookkeeping and the store bound live, and none of them is less necessary because the bytes came from next door. What this package adds is the two things that are its own: which path a name resolves to, and what can honestly be said about a working tree.

What it says vouches for a checkout

vouched is missing, always. Nothing has vouched for uncommitted code -- there is no publisher, no signature and no attestation -- and a source that claimed verified because the operator wrote the code themselves would be putting a lie in the one field a policy reads. A node whose host accept asks checkouts for verified gets nothing from it, which is correct: that is an operator saying they run only what somebody stood behind, and such a node should not have this source enabled at all.

The evidence is the path, plus what git could say about that one directory:

{
  "path": "/Users/you/src/project-pac/pac-flow-skills",
  "commit": "801aa49…",
  "dirty": false
}

dirty is absent rather than true when the directory is not in a repository at all -- git was never asked, so there is nothing to report -- and a dirty tree gets no commit, because HEAD is where the edits started rather than what is on disk. A dev node can be asked afterwards what it actually ran and answer, right up until somebody edits a file, at which point there is no identifier for what is there and none is invented.

Config

{
  "roots": ["/Users/you/src/project-pac"],
  "maxDepth": 5
}

roots is required and absolute: a node's working directory is whatever started it, and a source that guessed where somebody keeps their repositories would answer names it should have declined. The walk skips node_modules, dist, .git, .vendor, tmp and dotted directories, does not follow symlinks, and takes the first tree to claim a name -- roots is ordered, so which one that is stays the operator's decision.

The index is built once, on the first spec asked about. A repository cloned while the node is running is found by restarting it, which is what a dev lane does between every change anyway.