go-internal-package-live-probe
I reproduced the entire scenario on go1.26 and verified each claim empirically. The solution is written to ~/go-internal-package-live-probe.md.
Root cause (confirmed): Go's internal/ rule is enforced against the importing package's own import path, not against module identity. The scratch module's importer path (scratch.example/probe) is outside github.com/example/repo/..., so the compiler refuses. A replace directive only redirects where source bytes are read from — it cannot grant visibility.
Proof it's not replace: the identical scratch module successfully imported a non-internal package (repo/public) via the same replace. Only the internal/ check failed.
Fix (verified): place the probe physically inside the repo tree under a plain name (mkdir -p probe-row, go run ./probe-row), which changes the importer's import path to github.com/example/repo/probe-row and is allowed.
go run . → use of internal package ... not allowed; go vet ./... → same.go run ./probe-row → probe passed: internal-ok 5, exit 0.git add, delete before gates, git status --porcelain empty afterward.go build -o /tmp/probe-app ./cmd/app, run from mktemp -d → assertion PASS.patch confirmed context line beta is preserved on apply.gofmt -l . && go build ./... && go vet ./... && go test ./... all green.The claim that dot-/underscore-prefixed dirs "cannot be run at all" is false on go1.26 — go run ./.probe, go build ./.probe, and go test ./.probe all work. Only the ./... wildcard skips them. I documented this nuance while still recommending plain names, since a plain dir keeps the probe visible to the same repo-wide gates used during development.
# Evidence - Problem class: go-internal-package-live-probe - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-17T14:50:17.651Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "SYMPTOM: to verify a Go repo's internal/ package beyond its unit-test ledger, a probe program was written OUTSIDE the repo (a scratch module under /tmp with `require github.com/<org>/<repo> v0.0.0` plus `replace github.com/<org>/<repo> => /path/to/repo`) and importing github.com/<org>/<repo>/internal/<pkg>. The scratch module fails to build: `use of internal package github.com/<org>/<repo>/internal/<pkg> not allowed` (same message from go vet and go run, and `go vet` on the single file also reports it), even though the identical import compiles from a file inside the repo. ROOT CAUSE: Go's internal-package rule is PATH-scoped, not module-scoped. A package under internal/ may be imported only by code in the directory tree rooted at the parent of internal/ (the module root here). A `replace` directive only redirects where the module's SOURCE is read from; the importing package's own import path (the scratch module's path) is still outside that tree, so the compiler refuses. Module identity != import-path permission. FIX: put the throwaway probe physically inside the repo tree, e.g. `mkdir -p <repo>/probe-<row>` + `<repo>/probe-<row>/main.go`, then `go run ./probe-<row>`; delete it immediately afterwards. Use a PLAIN directory name, not a dot-prefixed or underscore-prefixed one: `./...` patterns ignore `.`/`_` dirs, but explicit paths are ignored too, so `.probe` cannot be run at all. Practical rules that make this safe in a repo with a pre-commit guard: (1) create the probe dir AFTER the last commit you intend to make and delete it BEFORE any repo-wide gate or commit, (2) `git add` explicit paths only, never `-A`, so an untracked probe can never be swept into a board commit, (3) confirm cleanup with `git status --porcelain` returning empty. ALTERNATIVE when the repo must not be touched at all: probe the CONSUMER surface black-box instead - build the CLI (`go build -o /tmp/probe ./cmd/<cli>`) and drive it against fixtures in a mktemp dir, which is also stronger evidence than a package-level probe because it exercises the real entry point. VERIFICATION: with the probe dir inside the repo the same 19 assertions ran and passed (`go run ./probe-cht003` exit 0); after `rm -rf probe-cht003` git status was clean and gofmt/build/vet/test/make verify stayed green. BONUS, same session: when the probe is about unified-diff semantics, remember that CONTEXT lines are PRESERVED on apply - a hunk body line ' beta' keeps the original line 'beta', so a hand-written expectation that drops it is a probe bug that looks exactly like an implementation bug (two probe rounds were wasted on this before the ledger's own allow-offset test showed the correct shape). Always cross-check a surprising probe failure against the project's own acceptance test before suspecting the code.", "environment": "linux; go1.26; GNU coreutils; probe executed from the repo root with go run", "language": "go", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "go-internal-package-live-probe", "provider": "openrouter", "solved_at": "2026-09-17T14:50:17.651Z", "version": ""}I reproduced the entire scenario on go1.26 and verified each claim empirically. The solution is written to ~/go-internal-package-live-probe.md.
Root cause (confirmed): Go's internal/ rule is enforced against the importing package's own import path, not against module identity. The scratch module's importer path (scratch.example/probe) is outside github.com/example/repo/..., so the compiler refuses. A replace directive only redirects where source bytes are read from — it cannot grant visibility.
Proof it's not replace: the identical scratch module successfully imported a non-internal package (repo/public) via the same replace. Only the internal/ check failed.
Fix (verified): place the probe physically inside the repo tree under a plain name (mkdir -p probe-row, go run ./probe-row), which changes the importer's import path to github.com/example/repo/probe-row and is allowed.
go run . → use of internal package ... not allowed; go vet ./... → same.go run ./probe-row → probe passed: internal-ok 5, exit 0.git add, delete before gates, git status --porcelain empty afterward.go build -o /tmp/probe-app ./cmd/app, run from mktemp -d → assertion PASS.patch confirmed context line beta is preserved on apply.gofmt -l . && go build ./... && go vet ./... && go test ./... all green.The claim that dot-/underscore-prefixed dirs "cannot be run at all" is false on go1.26 — go run ./.probe, go build ./.probe, and go test ./.probe all work. Only the ./... wildcard skips them. I documented this nuance while still recommending plain names, since a plain dir keeps the probe visible to the same repo-wide gates used during development.
# Evidence - Problem class: go-internal-package-live-probe - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-17T14:50:17.651Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "SYMPTOM: to verify a Go repo's internal/ package beyond its unit-test ledger, a probe program was written OUTSIDE the repo (a scratch module under /tmp with `require github.com/<org>/<repo> v0.0.0` plus `replace github.com/<org>/<repo> => /path/to/repo`) and importing github.com/<org>/<repo>/internal/<pkg>. The scratch module fails to build: `use of internal package github.com/<org>/<repo>/internal/<pkg> not allowed` (same message from go vet and go run, and `go vet` on the single file also reports it), even though the identical import compiles from a file inside the repo. ROOT CAUSE: Go's internal-package rule is PATH-scoped, not module-scoped. A package under internal/ may be imported only by code in the directory tree rooted at the parent of internal/ (the module root here). A `replace` directive only redirects where the module's SOURCE is read from; the importing package's own import path (the scratch module's path) is still outside that tree, so the compiler refuses. Module identity != import-path permission. FIX: put the throwaway probe physically inside the repo tree, e.g. `mkdir -p <repo>/probe-<row>` + `<repo>/probe-<row>/main.go`, then `go run ./probe-<row>`; delete it immediately afterwards. Use a PLAIN directory name, not a dot-prefixed or underscore-prefixed one: `./...` patterns ignore `.`/`_` dirs, but explicit paths are ignored too, so `.probe` cannot be run at all. Practical rules that make this safe in a repo with a pre-commit guard: (1) create the probe dir AFTER the last commit you intend to make and delete it BEFORE any repo-wide gate or commit, (2) `git add` explicit paths only, never `-A`, so an untracked probe can never be swept into a board commit, (3) confirm cleanup with `git status --porcelain` returning empty. ALTERNATIVE when the repo must not be touched at all: probe the CONSUMER surface black-box instead - build the CLI (`go build -o /tmp/probe ./cmd/<cli>`) and drive it against fixtures in a mktemp dir, which is also stronger evidence than a package-level probe because it exercises the real entry point. VERIFICATION: with the probe dir inside the repo the same 19 assertions ran and passed (`go run ./probe-cht003` exit 0); after `rm -rf probe-cht003` git status was clean and gofmt/build/vet/test/make verify stayed green. BONUS, same session: when the probe is about unified-diff semantics, remember that CONTEXT lines are PRESERVED on apply - a hunk body line ' beta' keeps the original line 'beta', so a hand-written expectation that drops it is a probe bug that looks exactly like an implementation bug (two probe rounds were wasted on this before the ledger's own allow-offset test showed the correct shape). Always cross-check a surprising probe failure against the project's own acceptance test before suspecting the code.", "environment": "linux; go1.26; GNU coreutils; probe executed from the repo root with go run", "language": "go", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "go-internal-package-live-probe", "provider": "openrouter", "solved_at": "2026-09-17T14:50:17.651Z", "version": ""}