A project that versions its own .claude was refused adoption. It is now the second supported shape: the directory is left as it is, nothing is linked, and project-config/<name> goes unused, because that configuration already reaches both machines by the same pull that brings the code. A project with nothing tracked under .claude/ is adopted as before. Which shape applies is read from the checkout on every run rather than settled once. Whether git holds entries under .claude/ varies by branch and by machine, so a decision made at adoption time cannot describe a project whose branches differ. The defect this fixes is the ordering, not the refusal. Both scripts tested for an existing symlink first and reported "already satisfied", so a link created while .claude was untracked outlived the branch that tracks it: git reported every file under the link as deleted while Claude Code went on reading it, and nothing looked at the git state again. Both now read it before the symlink branch. That shadowing state is the one neither shape tolerates, so it is asserted on every side. server/lib/22-claude-config.sh defers with exact restore commands rather than checking paths back out into a project's working tree, laptop/adopt-project-config.sh refuses with the same commands, and verify.sh asserts no link shadows a project that versions its own config. The git pathspec carries a trailing slash so it matches entries under the directory. A bare .claude also matches an adopted symlink that was itself committed, which would read as a project versioning configuration it does not have; lib/common.test.sh covers that case along with the other three.