[Smilewithoutfalling]

What

--incremental promises to re-extract only the files changed since the last import (docs/guide/knowledge.md:151). For a --dir checkout with no origin remote it never did: every run was a full extraction. Once the baseline does match, a second gap shows up — the re-import replaces the curated docs, because sameRepository (src/import-codebase.ts:74, added by #1417) decides that by repoUrl, which an origin-less checkout does not have.

This is gap 3 of #1422. Gap 4 is #1425, gap 1 is #1417. Gap 2 (two checkouts with the same basename sharing one evidence directory) is not fixed here: they still share evidence/code/<slug>/. What changes is that the second checkout no longer inherits the first one's curated docs.

Ordering with #1440. That PR, opened after this one, also rewrites sameRepository — as publishedSource — and it refuses an origin-less import over evidence published by a remote, where this PR replaces the docs. Whichever lands first, the other needs a rebase and one test changes: replaces the docs when the published manifest names a remote asserts today's replace, and refusing is the stricter reading, so I would drop my version of that case rather than theirs. The overlap is described on #1440.

Reproduction

main@97a762ce, the real extractCodebase (no mocks), two temp git repos that differ only by git remote add origin:

checkout	manifest keys after run 1	run 2, after editing one file
no origin	version,lastScan,project,files,sourceSubdir,headSha	no matching source baseline, running full extraction, 2 files scanned
with origin	the same plus repoUrl,repoIdentity	incremental: 1 files changed, 0 deleted, 1 file scanned

The two rows share every input except that one config line, so the difference is the remote and nothing else.

Why

• manifestMatchesSource required source.repoIdentity (src/codebase-extract.ts:609).
• sourceRepositoryMetadata returned only {sourceSubdir} when the checkout had no remote URL (:650).
• So incrementalBaselineMatches (:700) was false on every run, and the run printed the fallback notice.

Fix

For a checkout with no remote identity, record sha256(realpath(git root)) as localRootHash and compare it in manifestMatchesSource; compare it in sameRepository as well, so the docs carry over too.

It is a separate field rather than a value written into repoIdentity because manifestRepoIdentity in src/codebase-freshness.ts:64 feeds repoIdentity into remote-versus-remote matching — a filesystem path stored there would make freshness compare a path against URLs.

What changed since the reviews

Both review points were right, including the part of my rationale that was wrong.

[P1] localRoot is no longer written for a checkout that has a remote. sourceRepositoryMetadata now returns it only on the path where remoteUrl is empty, so repoIdentity identifies a remote checkout and nothing else is added to a manifest the team commits. The reason I gave for writing it everywhere — "dropping an origin afterwards does not throw away a usable baseline" — does not hold, and the measurement confirms your reading: manifestMatchesSource refuses a manifest that names a remote for an origin-less checkout (:638-639), so removing origin after a remote import is a full run either way.

[P2] The value is a hash, not the raw path. sha256(realpath(git root)) matches exactly the same pairs of runs, and source-manifest.json no longer carries /Users/<name>/….

sameRepository handles the origin-less case. Now that #1417 is in, comparing repoUrl alone leaves an origin-less checkout with no identity, so its curated docs were replaced on every re-import. Both sides blank now fall through to the same localRootHash and sourceSubdir comparison, and a manifest without the hash (written by an older CLI) is treated as "not the same source" rather than as a match.

[P1, bot review] Two subdirectories of one origin-less repo no longer share curated docs. service-a/svc and service-b/svc of one repository hash to the same git root, so the hash on its own called them the same source and handed the first one's docs to the second — the exact case in the review. sameRepository now requires the recorded sourceSubdir to be equal too, which is the condition manifestMatchesSource already applied to the baseline. Both values are in the manifest the review pointed at; the real-CLI run below is that scenario end to end.

Compatibility

• A manifest written before this change has no localRootHash, so each origin-less codebase pays one more full extraction and increments from then on.
• Moving or copying a checkout produces a different hash, so the new path counts as a new source: --incremental falls back to one full extraction, and a re-import through import --dir replaces the curated docs/ instead of carrying it over. That is the safe direction. The alternative — falling back to the slug — is the same-basename collision this PR refuses to reintroduce, and a moved checkout cannot be told apart from "another checkout with the same name"; only one of those two readings is ever safe, and the basename is the unsafe one. So a move costs one full run and the AI-written docs, and the trade-off is deliberate, not an oversight.
• Remote-backed checkouts behave exactly as before, and their manifests do not gain a new field.

Tests

src/__tests__/codebase-incremental-no-origin.test.ts, nine cases against real git repos:

1. reuses the baseline of the same checkout (the bug);
2. records no root hash when the checkout has an origin;
3. refuses a baseline that names a remote the checkout does not have;
4. refuses a baseline extracted from a different directory;
5. refuses a baseline written before localRootHash existed;
6. carries the curated docs across a re-import of the same checkout;
7. replaces the docs of a different checkout that shares the basename;
8. replaces the docs of another subdirectory of the same origin-less repo — the bot-review case: same hash, service-a/svc then service-b/svc, and the case first asserts that re-importing service-a/svc still keeps its docs, so it cannot pass by never carrying anything;
9. replaces the docs when the published manifest names a remote.

Three reverse arms, each reverting one part of the fix and leaving the tests intact:

reverted	fails	passes
sameRepository back to main's version	6, 8	1–5, 7, 9
the localRootHash write only	1, 6, 8	2–5, 7, 9
the sourceSubdir comparison only	8	1–7, 9

Case 8 fails in all three because it needs the whole chain: a hash that matches, the write that records it, and the directory check that tells two codebases apart. The others fail only where their own part is removed, and 3–5, 7, 9 are a guard rather than a restatement of the fix.

Real-CLI verification

npm run build (tsup), then the built CLI against a git repo with no remotes at all (git remote -v empty), inside a single-mode team repo:

$ node dist/index.js import --dir .../verify/a/svc3 --skip-enrich
[extract] svc3 complete
  Files: 3

$ node dist/index.js import --dir .../verify/a/svc3 --incremental --skip-enrich
[extract] incremental: 1 files changed, 0 deleted
[extract] svc3 complete
  Files: 1

The baseline published by run 1, read back from teamwiki/evidence/code/svc3/source-manifest.json:

localRootHash = bedb8b90b9596586a1f57626933fa33f2bd6162a8f9ad5994bd569730d34c6d3

No localRoot, no repoUrl, no repoIdentity, and no path anywhere in the file. sha256(realpath(.../verify/a/svc3)) computed independently from the shell gives the same digest, so the field is a hash of the checkout and not of something else.

Two subdirectories of one origin-less repo, which is the case the bot review raised — one repository with service-a/svc and service-b/svc, imported under the basename slug both of them derive:

=== RUN 1: import repo/service-a/svc ===
  manifest: sourceSubdir="service-a/svc" localRootHash=b1bd9738ef6de7d4… repoUrl=undefined
=== RUN 2: import repo/service-a/svc again ===
  manifest: sourceSubdir="service-a/svc" localRootHash=b1bd9738ef6de7d4… repoUrl=undefined
  curated doc KEPT
=== RUN 3: import repo/service-b/svc (same basename, same git root) ===
  manifest: sourceSubdir="service-b/svc" localRootHash=b1bd9738ef6de7d4… repoUrl=undefined
  curated doc GONE -> replaced with service-b's own evidence

Same hash in all three runs, so the hash genuinely identifies the repository and not the codebase; the subdirectory is what separates them.

Three more runs with the same binary:

checkout	result
origin-less, curated doc written by hand into docs/, then one source file edited	incremental: 1 files changed; docs/curated-by-ai.md is still there afterwards
has origin	manifest has repoUrl + repoIdentity and no localRootHash
had origin, then git remote remove origin, then --incremental	no matching source baseline, running full extraction, 2 files — dropping an origin does not reuse the old baseline
the same checkout copied to another path under the same basename, then --incremental	no matching source baseline, running full extraction, 3 files; localRootHash becomes 24cb91f7…, which is sha256(realpath(new path)) computed separately, and the curated docs/ is gone

The autoPush failed line in these runs comes from the stand-in git@github.com:acme/team.git origin on the sandbox team repo, not from the source checkout.

Verification

check	result
tsc --noEmit	0 errors
oxlint --type-aware --deny-warnings --report-unused-disable-directives	1336 files, 0 warnings, 0 errors
codebase-incremental-no-origin + import-codebase + codebase + codebase-freshness	49 passed, 1 skipped
new file alone	9 passed

codebase-reconcile.test.ts still fails one case on a Windows checkout; it fails identically with src/codebase-extract.ts reverted to main, so it predates this change. CI covers the rest.

[github-actions]

• [P1 blocking] Missing real-CLI verification record — PR description, “Verification”. This changes runtime behavior, but the documented checks are type checking, linting, and tests calling extractCodebase directly. The reproduction also calls the function rather than the CLI. The first trusted Code Review Rules item explicitly requires an end-to-end / real-CLI record. Document one representative post-build CLI run demonstrating baseline reuse for an origin-less --dir checkout.

No other confident findings in the specified diff. I did not run, build, or install PR code.

[Smilewithoutfalling]

Added the record to the body, under Real-CLI verification: npm run build (tsup, 8 s), then the built dist/index.js against a checkout whose git remote -v is empty.

$ node dist/index.js import --dir .../src-svc --skip-enrich
  Files: 3

$ node dist/index.js import --dir .../src-svc --incremental --skip-enrich
[extract] incremental: 1 files changed, 0 deleted
  Files: 1

Run 1's baseline reads back as version,lastScan,project,files,sourceSubdir,localRoot,headSha with localRoot = D:\Coding\git-pr-projects\_p1422\e2e\src-svc, and no repoUrl/repoIdentity — the exact origin-less shape that used to print no matching source baseline, running full extraction.

The autoPush failed lines in that transcript come from the stand-in git@github.com:acme/team.git origin on the sandbox team repo, not from the source checkout.

[SaulMoro]

This was generated by AI during triage.

@Smilewithoutfalling Thanks, the fix works. With the built CLI, import --dir <svc> --incremental gives these results on main and on this head:

Scenario	main	this head
Origin-less checkout, rerun after editing one file	full run, 3 files	incremental, 1 file
A different checkout with the same basename	full run	full run
The checkout moved	full run	full run
Manifest written by main	—	one full run, then incremental
Checkout with an origin	incremental, as before	incremental, as before

The new tests fail on main and pass here, also under a symlinked TMPDIR.

One change before approval:

[P1 blocking] localRoot is written for checkouts that have a remote, and nothing reads it there. sourceRepositoryMetadata sets localRoot for every checkout (src/codebase-extract.ts:656, :673, :684), so every import puts the member's absolute path (/Users/<name>/…, or D:\… as in the body's own record) into source-manifest.json, which the team repo commits. For a checkout with a remote, manifestMatchesSource compares repoIdentity and never looks at localRoot.

The stated reason, "dropping an origin afterwards does not throw away a usable baseline", does not hold. A manifest that names a remote is refused as a baseline for an origin-less checkout (:633-634). With the built CLI, removing origin after a remote import gives a full run on this head too.

Write localRoot only when there is no remote identity. Then adjust test case 2 and drop that line from the comment and the body.

[P2 non-blocking] For origin-less checkouts the raw path is still published to the team. Storing a hash of the real git root (for example sha256(realGitRoot)) would match exactly the same way without exposing the username.

Heads-up for whichever of this and #1417 lands second: #1417's sameRepository decides whether curated docs carry over by comparing repoUrl, separately from manifestMatchesSource. An origin-less checkout will still not carry its docs across re-imports there, even though this PR now gives it an incremental baseline. We found this by reading the source, not by building both together.

CI review: it reported a missing real-CLI record. We agree, and the body's built-CLI run now resolves it. It did not flag the point above.

Verified at 27b41bd:

• tsc and lint pass.
• The new test file passes 5/5.
• The six related unit files pass (65 tests), and so do the codebase-cli and source-freshness-recall e2e files (15 tests).
• git merge-tree is clean against #1417 and #1414.
• CI is green.

[github-actions]

• [P1 blocking] Different subdirectories of one origin-less repo share curated docs — src/import-codebase.ts:88. Importing /repo/service-a/svc, then /repo/service-b/svc, produces the same basename slug and localRootHash because both have /repo as their git root. sameRepository therefore preserves the first service’s curated artifacts for the second. Also compare sourceSubdir, as manifestMatchesSource does, before carrying artifacts over.

Resolved: The earlier missing real-CLI verification finding is resolved: the description now documents a post-build CLI run demonstrating origin-less incremental baseline reuse.

I only read the specified diff; I did not run, build, or install PR code.

[Smilewithoutfalling]

Pushed ee188f88 — the [P1] from the bot review is fixed, and it was a real defect.

What was wrong. sameRepository compared localRootHash alone. Two subdirectories of one origin-less repository hash to the same git root, so service-a/svc followed by service-b/svc was called the same source and inherited the first one's curated docs. manifestMatchesSource already required sourceSubdir equality for the baseline; the docs path now does too.

Evidence, real CLI. One repository containing service-a/svc and service-b/svc, imported under the basename slug both of them derive:

RUN 1  service-a/svc   sourceSubdir="service-a/svc"  localRootHash=b1bd9738…  repoUrl=undefined
RUN 2  service-a/svc   sourceSubdir="service-a/svc"  localRootHash=b1bd9738…  curated doc KEPT
RUN 3  service-b/svc   sourceSubdir="service-b/svc"  localRootHash=b1bd9738…  curated doc GONE

The hash is identical in all three runs, so it identifies the repository and not the codebase; sourceSubdir is what separates them.

Tests. Nine cases now. The new one asserts both halves — that re-importing service-a/svc still keeps its docs, and that service-b/svc replaces them — so it cannot pass by never carrying anything. Three reverse arms:

reverted	fails
sameRepository back to main's version	6, 8
the localRootHash write	1, 6, 8
the sourceSubdir comparison	8

Gate. tsc --noEmit 0 errors; oxlint --type-aware --deny-warnings 1336 files, 0 warnings 0 errors; the four codebase test files 49 passed, 1 skipped (the codebase-reconcile Windows-only failure is unchanged and fails the same way with main's codebase-extract.ts); 9/9 in the new file. The build and the CLI runs above are on ee188f88.

One thing for whoever merges. #1440, opened after this PR, replaces sameRepository with publishedSource and refuses an origin-less import over evidence published by a remote — the case this PR replaces the docs for. Whichever lands first, the other needs a rebase and one test changes. I have described it on #1440 and in the body, and I would drop my version of that case rather than theirs.

[github-actions]

No new confident findings in the specified diff.

Resolved

• Missing real-CLI verification: the description now documents post-build CLI runs demonstrating origin-less incremental baseline reuse and curated-doc handling.
• Shared curated docs across subdirectories: sameRepository now compares both localRootHash and sourceSubdir, with a regression test covering the reported scenario.

The documented testing satisfies the review criteria. I only read the specified diff; I did not run, build, or install PR code.

[Smilewithoutfalling]

@SaulMoro @jeff-r2026 — the review items and the sameRepository heads-up are in at ee188f88, and the bot reports no new findings on the current diff. The behaviour is recorded with real-CLI runs in the description.

One ordering question, because #1440 touches the same function. The only overlap between the two PRs is sameRepository: #1440 replaces it with publishedSource, while codebase-extract.ts is disjoint (it changes defaultProjectSlug, this one changes the manifest fields). Either order costs the same three-step rebase, so tell me which one goes first and I will follow it rather than leave both blocked on one decision.

If #1440 goes first I will rebase onto publishedSource and turn the "published names a remote, staged is origin-less" row into the refusal you and @Walternater described. Note for that port: CodebaseSourceSchema declares repoUrl as required and does not declare localRootHash, so an origin-less manifest parses to null today — part of the same port, not a separate fix.

[SaulMoro]

This was generated by AI during triage.

@Smilewithoutfalling Thanks, all three items are resolved. With the built CLI at ee188f8:

• A checkout with a remote no longer writes a local root: its manifest has only repoUrl and repoIdentity.
• An origin-less checkout publishes localRootHash, which matches the sha256 of the real path, and no path appears in the manifest.
• The same checkout with --incremental re-extracts 1 file and keeps the curated docs.
• A different checkout with the same basename, a sibling subdirectory, and a checkout whose origin was removed each get a full run that replaces the docs, so the sameRepository problem from #1417 is gone too.

[P3 nit] The hash is unsalted, so someone with read access to the team repo could confirm a guessed path such as /Users/<name>/src/<repo>. Not blocking.

On ordering: this goes first. It is approved and smaller, and #1440 can carry the port on its rebase. That port needs CodebaseSourceSchema to accept a manifest without repoUrl and to declare localRootHash and sourceSubdir. Otherwise an origin-less manifest parses to null and the curated-doc carry-over from this PR is silently lost.

Verified at ee188f8: build, tsc and lint pass; the 10 related unit files (158 tests) and 4 e2e files pass, the new file also under a symlinked TMPDIR; CI is green. We agree with the CI review that both earlier items are resolved.