GitNexus/gitnexus/test/unit/group/sync-unreadable-repos.test.ts
DuduPhudu 2c0fb7753c
fix(group): stop reporting what could not be measured as a measurement of zero (#3012)
* fix: surface unreadable group indexes and escape raw NUL bytes in source

Two independent diagnostics failures, both of which turn a real error into a
confident, benign-looking answer.

**Unreadable member repos (#3011).** `syncGroup` wrapped `initLbug` plus all
contract extraction for each member in a bare `catch {}` that pushed the repo
onto `missingRepos` and discarded the error. A LadybugDB storage-version
mismatch therefore surfaced as "repo not found", `group sync` printed
`0 contracts, 0 cross-links` and exited 0, and the existing contracts.json was
overwritten with an empty registry. The two states need different answers from
the operator — a missing repo must be indexed, an unreadable one is usually
version skew or a lock — so they are now separate:

- the caught error is logged with the repo, group path and lbug path
- `unreadableRepos` is tracked alongside `missingRepos` on `SyncResult`,
  persisted (optionally, so older registries still parse) on `ContractRegistry`,
  and threaded through `GroupService` sync/status
- `group sync` reports both before the cascade counts, since an unread repo is
  the likely explanation for a small or empty count
- `group status` reports unreadable repos separately; calling them "missing"
  actively misdescribed them
- when EVERY configured repo fails to open, the write is skipped: an extraction
  that read nothing is not evidence the group has no contracts, and replacing a
  good registry with an empty one loses data while reporting success

**Raw NUL bytes (#3010).** `sync.ts` and `free-call-fallback.ts` each used a NUL
as a join delimiter, written as a literal 0x00 instead of `\0`. Identical at
runtime, but it makes the file test as binary: `file(1)` reports `data`, ugrep
returns empty with exit 1 — indistinguishable from "no match", with no message —
and BSD grep replaces matching lines with "Binary file ... matches". A search
that should hit comes back as a confident "not present". Both now use the escape,
and a unit test fails on any raw control byte in src/ so it cannot silently
return.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test(hygiene): guard every tracked source file against a raw NUL, not just src/

The guard added with the NUL escapes only scanned gitnexus/src for .ts/.tsx.
Neither prior recurrence of this defect in this repo was in that scope:
b620773b1 was gitnexus/bench/cpp-qualified-ns/measure.mjs and 38d737bb5 was a
fixture under gitnexus/test. A guard that cannot see where the bug has actually
landed twice is not a guard.

Drive the file list from `git ls-files` at the repository root over
.ts/.tsx/.js/.jsx/.mjs/.cjs/.mts/.cts — 2483 files instead of 828 — and split
the byte class, which is the part that matters:

  - 0x00 is a hard failure repo-wide. It is the byte git's binary heuristic
    keys on, so it is the one that costs a file its diff (and, on the base side
    of a PR, its inline-comment anchors and its three-way merge).
  - The wider C0 class stays scoped to gitnexus/src. A repo-wide scan finds
    exactly one hit, test/unit/logger.test.ts:146, and that 0x1b is a
    legitimate ANSI-escape fixture that is the subject of the test. Widening
    this half would go red on day one.

Read Buffers and scan bytes instead of decoding each file to latin1, through a
bounded read pool: 1.5 s for 2483 files, against 8-21 s previously for 828.

Add a negative fixture — a planted 0x00 and 0x1b run through the same scanning
helper — so a future refactor of the collector cannot leave a permanently green
guard, plus an assertion that the collected set still reaches bench/, test/ and
.mjs, which goes red if the scope is ever narrowed back.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014g48u4WcRZy543Wqp5NhpV

* fix(group): report a cross-repo impact built from an incomplete bridge as truncated

When a sync cannot read a member repo, that repo's contracts and every
cross-link touching them are simply absent from bridge.lbug. Nothing in the
impact walk could notice: the only incompleteness channel on a
GroupImpactResult is truncationFields(), which is driven by fan-out state
(truncatedRepos / localPartial / fanoutTimedOut), and a repo missing from the
bridge sets none of them.

So `group impact` on a symbol whose one downstream consumer lives in an
unreadable repo returned `{ cross: [], truncated: false }` — "complete: nothing
in another repo depends on this". That is a wrong answer, not an empty one, for
a tool an agent uses to license a delete or a rename.

BridgeMeta now records unreadableRepos alongside missingRepos, writeBridge
persists it when non-empty, and runGroupImpact folds a non-empty
unreadableRepos ∪ missingRepos into truncated / riskEpistemic: 'lower-bound',
naming the repos in truncatedRepos.

The reason is a new 'incomplete-sync' rather than the existing 'partial'
because the remedy differs: 'timeout' and 'partial' are runtime limits the same
query can clear on a retry, while this one clears only when `gitnexus group
sync` succeeds. Runtime limits still take precedence when both apply, since
those are what the caller can act on immediately.

The risk VALUE is never clamped down — mergeRisk is monotone in the traversed
crossing count, so an incomplete bridge can only under-report. Marking the floor
is what makes that legible.

Both shape changes are additive and optional, so a bridge written before this
still reads.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014g48u4WcRZy543Wqp5NhpV

* fix(group): say truthfully what a sync did to contracts.json

Review follow-ups to the unreadable-repo diagnostics. Every item below is a
place where the code still answered a question it could not answer.

1. The CLI announced a write it did not perform. `group sync` printed "Wrote
   contracts.json (0 contracts, 0 cross-links)" unconditionally, including on
   the path that deliberately left the file alone. SyncResult now carries
   registryOutcome ('written' | 'preserved' | 'not-attempted'), the CLI prints
   from it, and group_sync returns it so an agent that calls group_sync then
   group_contracts can tell why the counts disagree.

2. Refusing to write anything on total failure threw away the diagnostic
   describing the run that just happened. `group status` reads contracts.json
   from disk, so the operator who saw the sync fail and ran status to find out
   why read the PREVIOUS sync's file: no unreadable list, an old lastSync, a
   healthy-looking group — or worse, the previous run's unreadable list
   presented as this one's. The skip is now targeted: contracts, crossLinks,
   repoSnapshots and generatedAt carry forward verbatim, only missingRepos and
   unreadableRepos are refreshed. generatedAt stays put because it dates the
   contracts, which are still the previous run's. With no prior file, or an
   unparseable one, nothing is written at all.

3. Per-repo extraction is now all-or-nothing. Extractors run in sequence and
   any one can throw; appending each one's results straight to autoContracts
   meant a repo whose HTTP extractor succeeded and whose gRPC extractor then
   failed contributed a partial set to the registry, while the same run told
   the operator that repo's "contracts are omitted from this sync".

4. readRegistry gains an opt-in strict mode, and syncGroup uses it. The lenient
   `catch { return []; }` converted "I could not read the registry" into "no
   repo is registered": every configured repo then resolved to MISSING, the
   total-failure guard stayed off (it needs a load error), and a good
   contracts.json was replaced by an empty one at exit 0. That is an unreadable
   condition reported as missing, one frame above the code this branch fixes.
   The default stays lenient for the other nine callers; ENOENT stays lenient
   in both modes.

5. Absence of unreadableRepos keeps meaning "not recorded". The loader spreads
   the key in only when present instead of defaulting to [], and getStatus
   passes undefined through, so a legacy registry no longer reads as "the last
   sync found none unreadable". getStatus also gates both list fields on
   Array.isArray: it reads through readContractRegistry, which is a bare
   JSON.parse cast, so a corrupt string in either slot used to reach
   cli/group.ts and die in .join(', ') — the command whose job is explaining an
   unreadable thing, crashing on one.

6. Smaller, same theme: the per-repo warning passes the Error itself rather
   than err.message, so pino keeps the stack; the total-failure warning no
   longer fires on a dry run, where it described a file the call was never
   going to touch and which need not exist; the status table's MISSING legend
   stops re-conflating the two states; the sync warning drops its
   GITNEXUS_LOG_LEVEL=warn hint, which would only have suppressed output (pino
   emits warn at the default info level, so the reason was already printed);
   and the group_sync tool description and its idempotency comment now describe
   what the tool actually does.

Testing. The original four cases could not see the change they were named
after. Mutation testing showed two survivors: dropping the ===
configuredRepoCount conjunct, which turns "every repo failed" into "any repo
failed" and would silently freeze contracts.json for a group where one of five
repos is skewed; and deleting both logger.warn calls, the stated purpose of the
change. Both survived because every case configured exactly one repo and
nothing read the log. There is now a two-repo case running the real per-repo
loop, an all-missing case, a _captureLogger assertion on the level 40 record,
partial-extraction cases, and strict-read cases. All five mutants are killed,
each by exactly one test.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014g48u4WcRZy543Wqp5NhpV

* fix(group): tighten the registry list gates and stop naming a truncation reason on complete results

Three follow-ups from the check bot's pass over the previous commits.

1. `detect.includes` was missing from both group-sync test fixtures, so they did
   not satisfy the `GroupConfig` they claim to construct. It went unnoticed
   because `tsconfig.json` is src-only; `tsconfig.test.json` reports it. The
   older of the two fixtures carried the gap in from the original commit.

2. `runGroupImpact` named its truncation reason in a variable computed before
   the truncated check, so on a fully complete result the variable read
   'incomplete-sync'. `truncationFields` discards the reason when `truncated` is
   false, so nothing surfaced — but a value that is wrong whenever it is unused
   is a trap for the next reader. Computed inline at the one call site that can
   consult it, which is also how the neighbouring call sites are written.

3. `Array.isArray` alone let a corrupt registry through. `['app/backend']` and
   `[{repo:'x'}]` are both arrays, and only the second reaches `cli/group.ts`'s
   `.join(', ')` — as `[object Object]`, a measurement the operator can read but
   cannot act on. Both readers now go through one `recordedRepoList` helper that
   requires an array of strings; anything else is "not recorded", the same as
   absent. Two more rows in the corrupt-value table cover it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014g48u4WcRZy543Wqp5NhpV

* fix(group): keep readRegistry's signature, and stop describing unreadableRepos as index-only

Two items from the check bot's blocking pass.

1. `readRegistry` gained an optional `opts` parameter last commit. That is
   source-compatible — every zero-argument call still compiles and behaves
   identically — but the contract check treats any parameter-list change on a
   symbol with outside callers as a break, and it is right that the safest
   version of this change touches that signature not at all. The strict read is
   now its own export, `readRegistryStrict()`, over a shared private body.
   `readRegistry()` is byte-identical to what it was; `syncGroup` is the only
   caller of the strict one, and the mode is legible at the call site instead of
   hiding in an options bag.

2. `unreadableRepos` is described everywhere as "the index could not be opened".
   That was accurate before this branch and is not now: making per-repo
   extraction all-or-nothing means a repo also lands there when an extractor
   throws partway with the index open fine. The two belong in one bucket
   because the consequence is one thing — none of that repo's contracts are in
   this sync — but the docs have to say so, or an operator reads `unreadableRepos`
   as a storage diagnosis and goes looking at LadybugDB for an extractor bug.
   Corrected on `ContractRegistry`, `BridgeMeta`, `SyncResult`, the `group_sync`
   tool description, and the `group sync` console output, which now says
   "Could not extract contracts from" rather than "Could not read the index for".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014g48u4WcRZy543Wqp5NhpV

* fix(cli): stop calling an unreadable registry an old one in group status

`getStatus` reports `unreadableRepos` as `undefined` for two different reasons:
the field is genuinely absent, or it held something that was not a list of repo
paths and the shape gate declined to guess. The status line named only the
first — "registry predates this field" — so a corrupt value read as a merely
old registry.

That is the same shape of wrong answer this command exists to stop giving: a
condition we could not read, presented as a benign one we understand. The line
now names both, and asks for a sync either way, which is the fix in both cases.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014g48u4WcRZy543Wqp5NhpV

* fix(group): close the three fail-open paths left on the safety boundaries

Follow-ups from the re-review of 31c2b6e81. All three of its blocking findings
reproduce; each is a place where unknown state still resolved to a confident
benign answer, which is the one thing this branch exists to stop.

1. Strict registry reading accepted malformed rows. `[{}]` is a JSON array, so
   it passed the shape check: every configured repo then failed to resolve into
   `missingRepos`, none produced a load ERROR, the total-failure guard stayed
   off, and a good contracts.json was replaced with an empty one at exit 0 —
   the same fail-open the strict mode was added to close, one level down from
   the file to the rows inside it. Strict mode now requires `name`, `path` and
   `storagePath` on every row and rejects the WHOLE registry if any row fails.
   Rejecting rather than filtering is the point: dropping bad rows would report
   the repos they name as unregistered, which is the same wrong answer again.
   `indexedAt` / `lastCommit` are deliberately not required — callers already
   default them, so demanding them would trade a fail-open for a fail-shut on a
   legitimate legacy registry.

2. A failed bridge publication could make impact look complete. `writeBridge`
   swaps `bridge.lbug` and writes `meta.json` as two operations, and this branch
   made that meta load-bearing: `runGroupImpact` derives its truncation fields
   from it. A sync interrupted between the two steps therefore left a NEW bridge
   beside the PREVIOUS sync's metadata, and an impact query read that as
   "complete". Fixed from both ends. The write path removes the old meta before
   the swap, so the window leaves metadata ABSENT rather than stale. The read
   path treats absent-or-unparseable meta (`version: 0`) as unknown provenance
   and reports a floor, which also covers the caught `writeBridge` failure in
   `syncGroup`. Over-reporting truncation on a bridge that is actually fine is
   the safe direction, and the next successful sync clears it.

3. `preserved` was returned when there was nothing to preserve. On a group's
   first all-unreadable sync the outcome was set before the prior registry was
   read, so the CLI told an operator "the contracts from the previous sync are
   preserved" about a file that had never existed. Split out as
   `no-prior-registry`, with its own console message.

Also widened the NUL guard to the source languages it claimed to cover. The
commit that added it said "every tracked source file" while the collector
stopped at the JS/TS family, so a raw NUL in tracked Python, Java, Go, Rust,
C/C++, Ruby, PHP, Kotlin, Swift, C# or shell would still have turned those files
binary unnoticed. Measured before widening: 2315 non-JS tracked source files,
zero hits, so this was an unforced gap rather than a tradeoff. A planted `.py`
fixture and a collector-coverage assertion keep it honest.

Every fix is mutation-verified: reverting each one individually turns its own
tests red (3, 2, 2, 1 and 1 failures respectively), and all pass together.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014g48u4WcRZy543Wqp5NhpV

* fix(group): record the empty unreadable measurement instead of dropping it

Both writers omitted `unreadableRepos` when it was empty, which made the
tri-state this branch introduced unreachable in its most common case.

`ContractRegistry.unreadableRepos` is optional on the TYPE so a registry written
before the field existed still parses, and absence there means "not recorded".
But a sync that read every repo successfully HAS measured it, and `[]` is that
measurement. Dropping it collapsed "measured, none" into "never recorded", so
after every clean sync `gitnexus group status` printed

    Last sync unreadable repos: not recorded
    (the registry predates this field, or its value could not be read)
    Re-run `gitnexus group sync` to record it.

about the sync that had just succeeded. The distinction is only worth having if
the writer commits to it, so both `contracts.json` and the bridge's `meta.json`
now record the field whenever the sync supplied it, `[]` included.

The check bot found this on the bridge writer and attributed the consequence to
`group status`. The consequence is real but it is not the bridge's: `getStatus`
reads `contracts.json` and never touches `BridgeMeta`, whose only consumer is
`runGroupImpact` — where absent and empty are already equivalent. So the
user-visible half was in the registry writer, one file over from where it was
reported, and both are fixed.

Also fills in `DetectConfig.includes` (and `workspace_deps`) across the group
test fixtures that predate those fields. These are pre-existing on main and are
a no-op at runtime — `undefined` and `false` are both falsy at the gate — but
they are the same defect the bot flagged as an error in the new fixtures, and
`tsconfig.test.json` reported eleven of them. That file is not in CI, which is
why they survived; the group tree is now clean of them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014g48u4WcRZy543Wqp5NhpV

* test(group): stop two bridge-metadata tests claiming coverage they do not have

Both were named for the swap window and neither injects a swap failure.

"drops the previous meta.json before swapping the database file" runs two
successful writeBridge calls. Its assertions hold with the removal in either
position, because writeBridge overwrites meta.json at the end regardless — so
it cannot pin the ordering it is named for. Renamed to what it does cover, the
successful-rebuild replacement, with the limit stated in the body rather than
left for the next reader to discover.

"leaves NO meta.json when the swap fails partway" removes the file by hand
after a successful write, so it exercises readBridgeMeta's missing-file
contract, not writeBridge. That contract is worth pinning on its own — version 0
is the signal runGroupImpact fails closed on — so the test stays, under a name
that says so.

The ordering itself is pinned in bridge-meta-swap-window.test.ts, which mocks
retryRename to throw on the bridge.lbug swap and asserts the previous sync's
metadata cannot survive it. Both renamed tests now point there, so the coverage
is findable from the place someone would look for it.

No production code changes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014g48u4WcRZy543Wqp5NhpV

* fix(group): pair bridge metadata to its database instead of deleting it

The previous commit closed the swap/metadata window by removing meta.json before
the database swap, so the window would fail to "absent" rather than "stale". That
was the wrong trade, and it destroyed recoverable state.

The old database's move to `.bak` sits inside a catch that swallows failures, not
just "no existing db". When that rename fails — a held read-only handle does this
on Windows, and a long-lived MCP server holds one — the failure is swallowed, the
following `tmp -> bridge.lbug` throws, and writeBridge exits with the OLD database
still in place and perfectly valid. Its metadata was already deleted. Cross-repo
impact then answers "we cannot say" for that group until some future sync
succeeds, and if the cause is a held handle or permissions there is no such sync.
A working feature, destroyed permanently to close a narrow window.

Deleting also only chose which way the window failed; it never closed it.

So destroy nothing, and make the pair self-describing instead: writeBridge stamps
the database's size and mtime into the metadata it writes, and
`bridgeMetaMatchesFile` lets a reader ask whether the two still belong together.
`runGroupImpact` treats a mismatch the same as absent metadata — provenance
unknown, report a floor. A metadata file left over from an earlier sync cannot
match a freshly renamed database, and a sync that fails before the swap leaves a
matching pair untouched. Metadata written before the stamp existed is
unverifiable rather than stale, and is accepted: failing those closed would mark
every pre-existing bridge incomplete, trading a narrow window for a repo-wide
regression.

The swap-window test now distinguishes the two failure shapes, because they want
different answers. When every rename fails the old database never moves, so the
surviving metadata still matches it and impact keeps answering from it. When only
the final rename fails the old database has already reached `.bak` and no
database is in place, so the metadata correctly matches nothing — and
`ensureBridgeReady` fails loudly on the absent file, which beats a silent floor.

Mutation-verified: reinstating the delete, neutering the pairing check, and
dropping the stamp each turn 2, 3 and 3 tests red respectively.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014g48u4WcRZy543Wqp5NhpV

* chore: keep TypeScript diffs readable after a NUL leaves the tree

Git decides a pair is binary when EITHER blob carries a NUL, and it only
sniffs the first 8000 bytes. `gitnexus/src/core/group/sync.ts` carried one
at byte 5132 on main. This branch removes it, but the base side still has
it, so the file renders as "Binary files differ" in the pull request: no
hunks, no inline comments, and no three-way merge — however clean the head
side is. A head-side byte guard cannot detect that, by construction, since
it only ever sees the working tree.

Setting the `diff` attribute stops the heuristic from hiding the change.
It does not mark the files binary, does not imply `text`, and does not
change how blobs are stored, normalized, or checked out — the root
`* text=auto eol=lf` still governs all of that. It affects diff generation
and rendering only.

Locally this turns the branch's own sync.ts diff from `Bin 17612 -> 25346
bytes` into 154 insertions and 16 deletions.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): answer "provenance unknown" for malformed bridge metadata

`readBridgeMeta` guarded the read and the parse but not the SHAPE of what it
parsed, then cast the result. `runGroupImpact` spread both repo lists straight
into a Set, so a `meta.json` whose `missingRepos` held an object threw a
TypeError out of the entire cross-repo query — and threw it from a point after
`ensureBridgeReady` had taken the bridge lease and before the `try` whose
`finally` releases it, so every such query also leaked a refcount the cached
handle could never get back. A malformed file is a reason to answer "we cannot
say", never a reason to crash the question.

The shape gate now lives where the metadata is read, mirroring the one
`service.ts` already applies to the registry's copies of these same two lists.
Each list is judged independently: a garbage `unreadableRepos` no longer
discards a `missingRepos` that was genuinely measured. A list that was present
but unusable is dropped rather than normalized to `[]`, because an unreadable
value is not a measurement of zero — the new reader-side `repoListsUnreadable`
carries that distinction, and `runGroupImpact` folds it into the same
provenance-unknown verdict it already reaches for `version: 0` and for
metadata that does not pair with the database beside it.

A root that is not an object is closed too. `JSON.parse` succeeds on `null`,
`7` and `[]`; the first threw on `.version`, and the other two read `undefined`
and sailed through the version gate as if the bridge had been vouched for.

Both provenance values moved inside the protected region and are initialized
fail-closed, so a future throw between the lease and the walk releases rather
than wedges.

`repoListsUnreadable` is reader-side only: the sole `writeBridgeMeta` call site
builds a fresh literal, so nothing persists it and no schema version moves.

Mutation-verified: reverting the shape gate alone turns 4 tests red — the three
malformed-list scenarios plus the handle-release regression.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(storage): reject registry rows that cannot identify a repo

The strict read's row gate gave `typeof v === 'string'`, and `typeof '' ===
'string'`. A row whose `name` was blank therefore passed as resolvable, then
matched nothing in `defaultResolveHandle` — putting every configured repo in
`missingRepos` and presenting an unusable registry as a clean answer about an
empty one. That is the same unreadable-as-missing fail-open the strict mode
exists to close, one level further in. A blank `storagePath` is worse than
useless: it joins to a relative `lbug` under the current directory, so the sync
opens an index that is not the repo's.

Both now have to be non-blank after trimming. `path` stays at the bare string
check, on the same reasoning that already exempts `indexedAt`/`lastCommit`:
require only what resolution depends on to IDENTIFY the repo. This gate rejects
the whole registry and the registry is machine-wide, so a field tightened past
what identification needs would let one blank value in one row break every
group sync on the machine — including groups whose repos all resolve. A blank
`path` still yields a working handle; `defaultResolveHandle` does read it, but
only for the pool id and `repoPath`, neither of which decides whether the row
names a repo.

The error now says what is actually wrong instead of naming three fields that
are all present.

Mutation-verified in both directions: dropping the trim turns the three
rejection tests red, and applying the wider fix that was considered and
declined — tightening `path` too — turns exactly the counter-case red, so that
test genuinely pins the narrow reading rather than passing either way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): bound the per-repo contract staging append

`autoContracts.push(...repoContracts)` passes every staged contract as a
separate argument, and the engine caps how many arguments one call may take.
That cap is a function of the host's available stack, so it is a different
number on every machine — this one accepts a 125k-element spread and dies at
150k.

The spread itself is not new; what it carries is. Before staging, this line
appended a single extractor's output as it came back. Staging made it carry the
whole repo's, which is enough for a large repo to raise `RangeError: Maximum
call stack size exceeded` on the one line whose job is to commit work that just
succeeded. The throw lands in the catch below, so the sync reports a repo whose
extractors all ran cleanly as one whose index could not be read — a crash
wearing the costume of a diagnostic.

A bounded loop replaces it: the count a repo can stage is now bounded by memory
rather than by how much stack the process happened to get.

The guard is structural, not size-based, and deliberately so. A "make the
fixture big enough to crash" test passes against unfixed code on any host with
a larger stack, which is exactly the guarantee a regression gate cannot give
up. It walks the AST and locates the region by role — the `const` staging
buffer typed `StoredContract[]`, then the extractor `try` that is a direct
statement of the block declaring it — so renaming either identifier keeps it
pointed at the same code. `.apply()` is rejected alongside spread, being the
same hazard in different syntax.

Direct statements only, because `syncGroup` wraps this whole section in its own
try/finally for the lease sweep, and that ancestor reads the buffer too.
Matching any enclosing `try` pulls in the entire function body — including the
two windowed-manifest spreads, which are bounded by the window size and are not
what this fixes.

Mutation-verified in both directions: restoring the spread turns the gate red
naming that line alone; deleting a manifest-window spread, and separately
adding a third one, both leave it green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): keep unreadable repos out of manifest contracts too

Per-repo staging closed one door: a repo whose extractor threw contributes
nothing through the direct path. Deferred manifest resolution was a second
door, still open. It derives its known-repo set from the resolved-handle map,
which kept an entry for a repo the same run had already declared unreadable —
so the sync re-opened that index and resolved symbols against a database it had
just told the operator it could not read.

Deleting the handle in the catch stops the re-open, but it does not satisfy
R2 on its own: `ManifestExtractor` resolves both endpoints of a link and emits
a contract for each, and for an endpoint with no executor that contract is
still emitted with a synthetic UID. The registry ended up naming a repo the
same run reported unreadable.

So the emitted output is filtered by ENDPOINT, not by link. Dropping the whole
link would delete the healthy partner's contract as well — a repo losing its
own output because a neighbour's index would not open, which is wider than the
requirement and destroys good data to suppress bad. A cross-link is different:
it asserts something about a pair, so if either end is unreadable there is
nothing left to anchor it to, and a half-anchored link is exactly the
confident-about-what-it-could-not-read answer the registry must not give.

Deleting the handle also changed what the operator gets told, so the warning is
split. An unreadable repo IS configured; letting it fall into the "references
repos not in config.repos" branch states something false and sends the reader
to edit group.yaml for a problem only re-indexing fixes. It now gets its own
message naming what was actually omitted.

Mutation-verified four ways: reverting the endpoint filter turns three
scenarios red; the over-broad whole-link variant turns the healthy-partner
scenario red and nothing else; removing the handle delete turns the
no-re-open scenario red; and reverting the warning split turns the operator-
message scenario red. Every assertion reads the written contracts.json rather
than the in-memory result.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* refactor(group): keep readBridgeMeta's signature stable across the shape gate

The shape gate landed by widening the return type to a reader-only
`ReadBridgeMeta extends BridgeMeta`. That is source-compatible — a covariant
return, one added optional field, every existing caller unaffected, typecheck
and suite clean — but the contract check reads it as a changed signature with a
caller left behind, and blocks the merge on it. This branch already hit the
same wall on `readRegistry` and settled it the same way: leave the signature
alone and make the difference legible some other way.

So the flag moves onto `BridgeMeta` itself as an optional, documented,
never-persisted field, and `readBridgeMeta` goes back to the exact signature
its callers already compile against.

That is the better shape here anyway. The reader-only subtype would have split
the validation two ways: `openBridgeDbReadOnly` and `bridgeExists` both gate on
`meta.version`, and the normalization that comes with the gate is what stops a
`version: null` in a hand-edited meta.json from reading as `undefined` and
sailing through `version > 0` as though the bridge had been vouched for. One
type keeps all three callers behind the same guard.

Nothing persists the flag: `writeBridgeMeta`'s only caller builds a fresh
literal, so it cannot round-trip to disk.

No behavior change — pure type restructuring. 927 tests pass, typecheck clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): stop treating a half-written bridge stamp as a verified match

`bridgeMetaMatchesFile` joined its two `undefined` checks with `||`, so
metadata carrying a size and no mtime — or the reverse — returned `true`, the
same answer it gives a fully verified pair.

A stamp is a PAIR. Both halves absent is the legacy shape: metadata written
before stamping existed, which cannot be verified either way and is accepted
deliberately, because failing it closed would mark every pre-existing bridge
incomplete until re-synced. Exactly one half present is not that. Something
wrote a stamp and did not finish, which is precisely the condition stamping was
added to detect — so the check handed back "verified" for the one shape that
most deserves suspicion, and a cross-repo impact query built on it would report
a confident answer about a database its metadata cannot vouch for.

The two states are now separated: neither half present accepts, exactly one
rejects as provenance-unknown, both compare against the file as before.

Found by the repository's own contract check, not by the plan.

Mutation-verified: restoring the `||` form turns both half-stamp cases red
while the legacy and fully-stamped controls stay green, so the pair genuinely
pins the distinction rather than passing either way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): pair unstamped bridge metadata by write order, before any open

Unstamped metadata was waved through: `bridgeMetaMatchesFile` returned "matches"
for any pair with no stamp to check, so the stale-meta-beside-a-new-database
window stayed open for every bridge written before stamping existed, and
`runGroupImpact` spent that metadata's completeness as fact.

`writeBridge` renames the database into place and writes the metadata after, so
`meta.mtime >= db.mtime` holds for any pair written together — including by
builds that predate the stamp. A database strictly newer than the metadata
beside it can only come from a swap whose metadata write did not land. That is
the fallback now. It is a heuristic on write order, not proof of provenance, and
it is wrong in two directions: a stale metadata file touched after the swap
still reads as paired, and a pair whose clock stepped backwards between the two
writes reads as unpaired. Both are recorded at the code; the second is the safe
direction. Equality counts as paired, or a coarse-granularity filesystem would
reject every legacy bridge for a reason that is about the filesystem.

The verdict is now taken in `ensureBridgeReady` BEFORE the database is opened,
and carried on the metadata rather than recomputed afterwards.

That ordering is load-bearing, not tidiness. Impact and trace both open the
bridge and only then ask about provenance, so on any platform or LadybugDB
build where a read-only open advances the file's mtime, every pre-stamp bridge
would report provenance-unknown from its first query onward — the exact
repo-wide regression this rule was chosen to avoid, arriving as a silent
downgrade rather than an error. It does not happen on Linux, which was measured.
It cannot be measured on Windows: pinning it by really opening the database
needs an in-process write→read reopen of the same bridge.lbug, which is a
documented limitation there. Rather than ship a Windows-skipped test and leave
the assumption unverified on the platform whose file semantics are most likely
to differ, the check moved ahead of the open so no platform has to be trusted.

The new guard forces the hostile case on every platform: the open is stubbed to
advance the database's mtime, and the verdict must still be "paired". It is
registered in the cross-platform list so the Windows and macOS shards run it,
and it has a control so it cannot pass vacuously.

Two existing fixtures mocked `readBridgeMeta` to return a stamped-era version
while never writing a meta.json — a state production cannot reach, since a
non-zero version can only come from a file that exists. They now write the
metadata their own mock claims to have read, rather than the helper being
loosened to accept metadata it cannot stat.

Mutation-verified twice: reverting the write-order branch turns both rejection
cases red while all four legacy-accept cases stay green, and moving the pairing
call back after the open turns the ordering guard red on its own.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* refactor(group): compute cross-repo completeness in one place

Three surfaces can return a partial cross-repo answer — impact, trace, and the
contract listing — and each decided for itself whether it was complete. Impact
carried the structured triple; trace said it in prose, if at all. An agent
reading a not-found trace had no machine-readable way to tell "there is no
path" from "there may be a path in a repo this sync could not read", which is
the difference between an answer and a floor.

`crossRepoCompleteness` is now the one computation, and its input deliberately
does not name where any of it came from. `BridgeMeta` is not in the signature
and must not be: `groupContracts` answers the same question from contracts.json
and never opens a bridge, so `version`, `repoListsUnreadable` and
`pairedWithDatabase` do not exist on that path. Each caller derives its own
`provenanceUnknown` — the bridge callers through `bridgeProvenanceUnknown`,
which stays separate for exactly that reason — and passes the boolean in.

Scope arrives as a predicate rather than a repo list or a subgroup, so
narrowing a query's scope stays a change to one argument at the call site.

The trace results now carry `truncated` / `truncationReason` / `riskEpistemic`
like impact does. `notes` is untouched; it remains an addition to the machine
channel, never the channel.

One correction to the approach as written: it said to pass the trace's two
endpoint repos as the predicate, but a destination trace declares no `to`. It
asks where a call lands, so any member may hold the answer — and an unreadable
provider repo is precisely how "no outgoing ContractLink leaves this repo"
becomes a wrong answer rather than an empty one. Filtering that path to the
`from` repo would have reintroduced the bug this unit exists to close, so it
passes every repo and a test pins it.

Two pre-existing paths become consistent with the vocabulary as a result: a
crossing-capped result now reports `truncationReason: 'partial'` alongside the
`truncated` flag it already set, and the destination path's `ambiguous` returns
now report the cap its `ok` and `not_found` siblings already reported. Both are
additive — no field is removed, and no `truncated` flips from true to false.

`truncationFields` returns a discriminated union now, so `truncationReason`
reads without a fallback on the branch where it cannot be absent.

Mutation-verified: reverting the provenance fold alone — one line in the shared
helper — turns 8 tests red across both surfaces, 2 new trace scenarios and 6
existing impact ones, which is the point of there being one helper.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): narrow the incomplete-repo set to the query's declared scope

A subgroup-scoped impact query was marked a lower bound by repos it had
explicitly excluded. The fan-out already drops every neighbour outside the
subgroup, so those repos could not have contributed a crossing to the answer —
and a completeness marker that fires on results it does not describe is how a
caller learns to ignore the marker.

The scope is the query's DECLARED one, not the one the walk reached. An
incomplete repo's contracts are absent from the bridge by definition, so it is
never in the traversed set; filtering on what was traversed would empty the
intersection on every query and silently restore the fail-open this channel
exists to close.

Declared scope here is the subgroup PLUS the query's own repo, which the
approach did not account for. The walk starts from that repo's contracts in the
bridge, so when it is the repo the sync could not read there are no crossings
to find under any scope — and a subgroup excluding it would have turned that
vacuum into a confident "nothing depends on this", for a tool an agent uses to
license a delete. That case reported a floor before this change, so narrowing to
the subgroup alone would have been a regression. The union only ever widens the
in-scope set, so it cannot re-mark a repo the query excluded.

Membership goes through the existing `repoInSubgroup` in both clauses, `exact`
for the origin equality, rather than growing a second notion of what it means
for a repo path to be in scope.

Sound only while `MAX_SUPPORTED_CROSS_DEPTH` is 1 — at depth 2 an out-of-scope
repo can sit between two in-scope ones — and that constraint is recorded at the
intersection.

Unscoped queries are byte-for-byte unchanged: `repoInSubgroup` answers true for
an absent subgroup, so the intersection is the whole set.

Mutation-verified: restoring the unfiltered predicate turns exactly the two
scoped cases red while the unscoped control and both in-scope guards stay green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): keep the preserved registry and the bridge from disagreeing

A total-failure sync refreshed contracts.json's diagnostic lists and left
meta.json alone. But meta.json, not contracts.json, is where runGroupImpact
reads completeness from — so the registry said "this sync could not read
app/backend" while a cross-repo query answered `{ cross: [], truncated: false }`.
Two surfaces describing the same run, one of them wrong, and the wrong one is
the machine-readable one an agent uses to license a delete.

The preserve path now refreshes the same two fields in the metadata. The
database stays untouched: it still holds the contracts being preserved, and
rebuilding it here would be the one write that could lose them.

Refreshing metadata is not free, though, and the obvious version of it is a
fail-open. The rewrite moves meta.json's mtime to now while bridge.lbug's stays
old, so an unstamped pair whose database is NEWER than its metadata — the shape
the write-order rule exists to reject — would come out of a preserve sync
passing the check. Writing "no stamp" does not help; the write-order comparison
is exactly what the moved mtime defeats. The verdict has to be recorded in the
metadata, because the refresh cannot avoid moving the mtime.

So `provenanceUnknown` is persisted whenever the existing pair does not already
check out, the existing stamp fields are carried through verbatim rather than
dropped, and `bridgeMetaMatchesFile` rejects the marker ahead of both the stamp
and the write-order heuristic. A pair that already matched is re-stamped
instead, which also upgrades a legacy unstamped-but-paired bridge to an exact
stamp. No preserve run can increase the number of pairs that pass the check.
The marker self-clears: `writeBridge` builds fresh metadata and never sets it.

`BridgeMeta` carries two reader-side fields documented as never persisted, and
this is the first code in the repo that reads metadata and writes it back. Both
are stripped explicitly before every write. `pairedWithDatabase` is the
dangerous one — persisted, it would tell every future reader the pair had been
verified — and a test seeds both on disk to pin that neither survives.

The write is not wrapped in a catch, unlike writeBridge on the success path.
There contracts.json is canonical and already written, so a stale bridge is a
recoverable degradation; here the write IS the guard against a confident wrong
answer, and swallowing its failure would reinstate the fail-open it closes.
`writeContractRegistry` above is unguarded into the same directory for the same
reason.

A group with neither file writes nothing: `readBridgeMeta` already answers
`version: 0` for an absent file, so a written one would say what the absence
already says while inventing state for a bridge that has never existed.

Mutation-verified three ways: dropping the marker write turns 6 red including
both laundering scenarios; moving the marker check below the stamp branches
turns the unstamped-laundering case red; removing the field stripping turns the
never-persisted test red. Each restored byte-exactly and re-verified.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): report group_contracts' completeness in the shared vocabulary

`group_contracts` returned contracts and cross-links and said nothing about
whether that listing was the whole story. An agent reading it after a sync that
could not open half the group got a confident-looking list with no way to tell
it was a floor — the same fail-open the impact path already closed, on a surface
that had no channel for the answer at all.

It now returns the registry's two diagnostic lists and the structured triple,
folded through the same helper the impact and trace surfaces use, so the three
cannot drift. The helper takes no `BridgeMeta` precisely so this path — which
reads contracts.json and never opens a bridge — can share it.

The three registry states stay distinguishable, which is the point:
  - key absent: the registry predates the field and has no opinion about which
    indexes opened, so the key is omitted rather than invented as `[]`, and the
    listing reports a floor. It cannot say which repos the sync failed to read,
    so it cannot claim to be complete.
  - key present and empty: measured, clean, not truncated.
  - key present and populated: the repos, and a floor.

`incompleteRepos` is dropped on this surface alone: both lists it derives from
are returned verbatim beside it, and a third name for the same repos is drift
waiting to happen.

The import is lazy, matching `groupImpact` and `groupTrace` in this same class.
`cross-impact.js` statically pulls the native LadybugDB binding through
`bridge-db.js`, and `service.ts` is loaded by every `gitnexus group` subcommand
including ones that touch no database.

One fix inside the same file that this unit forced: the registry loader gated
`missingRepos` with a bare `Array.isArray`, which admits `[{repo:'x'}]`. That
was inert while nothing read the list, but this change both returns it and folds
it into the completeness answer — so an unreadable value would have been printed
as a repo name and would have flipped `truncated` on garbage. It now uses the
same `recordedRepoList` gate `group status` already applies to the same field.
`missingRepos` has always been required, so unlike `unreadableRepos` it has no
"not recorded" state to preserve and an unreadable value degrades to empty.

Mutation-verified: reverting the fold alone turns 14 tests red and leaves the
control — the contract and cross-link payload this tool has always returned —
green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(cli): stop dropping group contracts' completeness fields on the way out

`group contracts --json` destructured `{ contracts, crossLinks }` from the
service payload and rebuilt an object from just those two. Everything else the
service returned was discarded on the way to stdout — so the completeness
fields the MCP tool now carries were invisible at the CLI, and the two surfaces
disagreed about the same registry.

It prints the payload whole now. A field added to the service reaches `--json`
without a matching edit here, which is the point: the re-serialized subset was
a second place that had to be remembered, and it was not.

The human-readable path gains the same signal in words. A listing built from a
sync that could not read part of the group shows counts that are a floor, not a
census, and it named neither fact. It now says so and names the repos when the
registry recorded them — and says the sync did not record which repos it could
read when it did not, because a listing that cannot say what it is missing is
still incomplete.

Mutation-verified: restoring the re-serialized subset turns the `--json` case
and the control red.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): tell a missing registry entry apart from an unreadable one

`group status` printed MISSING for both "this repo has no row in the registry"
and "the registry itself could not be read", so an operator whose registry.json
was corrupt was told every repo was unregistered — and sent to re-register them
instead of to the one file that was actually broken.

The two are now separate. `missing` keeps its old meaning and still flags every
unusable repo, so an older consumer is unaffected; `unresolvable` is additive,
always present, and carries the reason that produced it.

This is the one caller that has to make that distinction, so it takes the
strict global-registry read. `readRegistry`'s `catch { return [] }` collapses a
malformed registry into an empty one, which is indistinguishable from a genuine
absence and is exactly what produced the wrong label. The cost is accepted
knowingly and recorded at the call site: the strict read rejects the whole
registry when any row fails to identify a repo, so one malformed row renders
every member unresolvable — including members whose own rows are fine. That is
the honest verdict, and it is reported as an unresolved state rather than a
clean one.

Choosing between the two labels needs to know whether a row exists at all,
which `registryIdentifies` answers by mirroring the two tiers the resolver
matches a bare group-config value on — registry name, case-insensitively, and
repo path. It deliberately stops short of the hashed-id and partial-name tiers:
those exist to be generous about what an operator typed, while this only picks
a label, and a looser match would relabel a genuine registry miss as an
unresolvable row — the same conflation this change removes, pointed the other
way.

The plan's third failure mode — a row that resolves but whose storage path
cannot be opened — turns out to be unreachable: `loadMeta` returns null on
every error and `checkStaleness` catches everything, so nothing after
`resolveRepo` inside the try can throw. The reachable per-repo case is
`resolveRepo` itself throwing, as it does for two registered clones sharing a
name, and that is what the tests drive end to end through the real CLI. The
code still handles the plan's case correctly if those helpers ever start
throwing.

Mutation-verified: reverting the split turns 6 unit and 2 CLI cases red while
both controls — a genuine miss, and a healthy group — stay green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(cli): say what the preserve path actually does to contracts.json

The sync summary announced "Did NOT write contracts.json" on the branch that
writes it. The preserve path rewrites the file — keeping the previous sync's
contracts and cross-links, replacing only the two diagnostic lists — so an
operator who checked the mtime and found it moved was told the opposite of what
had happened, on the command this PR exists to make legible.

It now says the previous contracts were kept and names what changed.

The no-prior-registry branch is narrowed for the same reason. It claimed
nothing at all was written, and that is no longer true either: this path still
records the run against an existing bridge's metadata. The claim is now scoped
to contracts.json, which is the file it can actually speak for.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): stop the total-failure log promising a preservation that did not happen

The warning fired before the prior registry was read, so it could only ever
promise one of the two things that might be true — and it promised the wrong
one to every group that has never synced: "keeping the contracts from the
previous sync" about a file that does not exist. The console line for that same
run, driven by `registryOutcome`, said the opposite.

It now lives inside the branch, after the read, with one message per outcome
chosen at the point the outcome is decided. The log and the console cannot
disagree, because the same fact selects both.

Both messages keep the warn level and the two repo lists.

Mutation-verified: reverting the split turns the no-prior-registry case red
while the preserved case — whose claim was already true — stays green. The
dry-run test's log filter was also widened to the sentence both messages share,
or the new wording would have made that assertion match nothing and pass
regardless.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): make the bridge-failure warning describe what the code guarantees

The warning after a failed `writeBridge` promised that cross-repo impact would
report `truncated` until a sync succeeded. Nothing on that path produces that
signal.

The swap is the last step: `writeBridge` builds the new database in a staging
directory and only then moves the old one aside. A failure during the build
therefore leaves the previous sync's `bridge.lbug` exactly where it was, beside
the `meta.json` stamped for it — a pair that passes `bridgeMetaMatchesFile`
with the previous run's `unreadableRepos`. The next cross-repo query answers
`truncated: false` from superseded contracts, which is the opposite of what the
operator was told to expect, and worse than being told nothing.

The warning now says what is actually true: contracts.json is intact and
canonical, the bridge was not replaced, cross-repo queries may still answer from
the previous sync's contracts, and nothing marks them as superseded.

The metadata is deliberately NOT re-stamped to make the original promise true.
That would recreate exactly the metadata/database mis-pairing the stamping on
the preserve path exists to prevent, and the comment at the warning records it.

The claim is asserted against captured log output rather than left to the state
tests. Those check which pairs match and what the preserve path writes; every
one of them stays green while this sentence reverts to promising a truncation.
An unasserted user-facing branch is the defect class this change is closing, so
it does not get to close it while remaining one.

No filesystem shape makes the real `writeBridge` fail while
`writeContractRegistry` succeeds — they write into the same directory one line
apart — so the failure is armed through a pass-through wrapper on the file's
existing mock. It delegates byte-for-byte unless a test arms it, and is reset
around the new suite.

Mutation-verified: restoring the original wording turns its own assertion red
and nothing else.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(mcp): name every registry outcome group_sync can actually return

The tool's description told agents `registryOutcome` is 'written' or
'preserved'. It has a third reachable value: 'no-prior-registry', returned when
nothing could be read AND there was no previous contracts.json to carry
forward. An agent calling this tool against a group that has never synced got a
value its own tool description said did not exist, and no way to tell it apart
from the case where the previous contracts survive.

The distinction is the whole point of the value. After 'preserved' there is a
registry to read — stale, but real. After 'no-prior-registry' there is nothing
on disk at all, so a following group_contracts or group_impact has no registry
rather than an old one. Those need different responses from the caller.

'not-attempted' stays undocumented because it is unreachable through this tool,
and a guard asserts it stays that way.

The code comment above the annotations claimed the preserve path does NOT write
contracts.json. It does — it rewrites the file, keeping the previous contracts
and cross-links and refreshing only the two diagnostic lists, which the CLI's
own summary was corrected to say a few commits ago. Left alone it would have
re-seeded the same wrong claim next to the text that now states it correctly.

Mutation-verified: deleting the 'no-prior-registry' sentence turns the guard red.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(mcp): explain structural incompleteness on the impact tool and status resource

The impact tool's GROUP MODE paragraph described one cause of truncation — the
fan-out running out of room — and left an agent to assume that was the only one.
So a `truncated: true` carrying `truncationReason: 'incomplete-sync'` read as
"retry with a smaller scope", when retrying returns the identical floor forever:
the repos are absent from the bridge itself, and only a re-sync puts them back.
The old text also said the response carries the truncation fields "when it stops
early", which is wrong for that case — `truncatedRepos` names repos even when
ZERO crossings to them were attempted, because their contracts were never in the
bridge to cross to.

The paragraph now branches on the reason and gives each its remedy: 'timeout'
and 'partial' are runtime limits where a retry or a larger budget can help;
'incomplete-sync' is structural and the remedy is `group_sync`.

The reason union is now derived from an exported `as const` array rather than
written as a bare type. A type-only union gives a guard nothing to enumerate, so
the guard has to hand-list the members — and then it passes forever the moment a
fourth is added, which is the exact regression it exists to catch. The guard
iterates the runtime array instead. Verified by appending a probe member and
watching it go red, then removing it. The resolved type is unchanged; every
importer uses `import type` and none needed an edit.

The status resource said "Group index / contract staleness" and nothing about
the distinctions its payload now carries. It explains all of them: a repo absent
from the registry versus one whose entry could not be resolved, and the
`unreadableRepos` tri-state where an ABSENT key is not an empty one — absent
means the last sync never recorded what it could read, so cross-repo answers for
that group are a floor.

The description an MCP client actually receives lives in `getResourceTemplates`,
not in the context resource's inventory line the plan pointed at. Both now carry
the vocabulary, so the two surfaces cannot disagree about the same payload.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* feat(group): serialize group syncs behind a fail-closed per-group lock

Two concurrent syncs of one group could lose one another's writes. Both read
the prior registry, both built contracts, both wrote — last writer won, and the
loser's work was gone with nothing reporting it. A group sync is long and
expensive and is exactly the operation whose lost update destroys contracts.

`syncGroup` now takes a lock for the whole persist section, acquired exactly
once. `acquireIndexLock` is not reentrant, so a second acquisition anywhere
below would deadlock the happy path rather than an edge case; `withGroupSyncLock`
has one call site and nothing inside it re-acquires.

The lock lives on a dedicated `sync-lock` directory inside the group directory,
mirroring the registry lock's dedicated directory rather than reusing the
resource's own — a lock directory that could collide with a per-repo index slot
repeats a bug the registry lock's comment already warns about.

It fails CLOSED, which is the opposite of `withRegistryLock` and deliberately
so. That one degrades to unlocked because it guards a sub-second JSON merge on
a latency-critical path; here running unprotected is the outcome the lock
exists to prevent. Three exits are covered: a timeout, an unwritable lock
directory, and the lock-free degradation the primitive performs silently.

That third exit needed a change in `index-lock.ts`, and it is the one declared
exception to keeping this work inside core/group/. `acquireIndexLock` answers a
read-only or permission-denied filesystem with a no-op handle that is
byte-identical in shape to a real one, so a caller for whom lock-free is not an
acceptable outcome could not tell the difference. It now carries an optional
`lockFree` marker. The change is additive by construction: no signature moves,
no control flow changes, nothing about when or how a lock is taken changes, and
every caller that ignores the field behaves exactly as before.

A filesystem probe inside the group module was considered and rejected on
evidence: `selectBackend` returns `socket` on Linux and Windows, where
`acquireViaSocket` never touches the filesystem and this branch cannot occur —
so a probe would refuse syncs on the two platforms that never degrade while
missing the one that does.

The timeout ceiling is a named 600s constant passed explicitly. The magnitude
matches the primitive's own analyze-sized default because a group sync is
analyze-shaped and a legitimately queued second sync must be able to wait out a
full first one. Passing it explicitly is about the override, not the magnitude:
`resolveTimeoutMs` resolves `GITNEXUS_INDEX_LOCK_TIMEOUT_MS <= 0` to Infinity,
which would turn fail-closed into a hang.

Cross-process exclusion is proved with a real spawned holder, not an in-process
mock, which cannot demonstrate the property this exists for. The lock-free
scenario pins `GITNEXUS_INDEX_LOCK_BACKEND=file` — unpinned it would pass on
two of three platforms while measuring nothing — and produces the failure by
injecting EACCES on one syscall rather than by chmod, so it runs identically on
Windows instead of being skipped there.

The CLI reports the failure through pino rather than a bare stderr write, which
this package lints as an error to keep that migration moving, and the test reads
the `msg` field rather than a raw substring — matching on the raw text would
have passed only by accident of quoting and would go green again if the line
were downgraded.

Nothing is skipped on any platform, and the test is registered for the
cross-platform shards.

Mutation-verified: removing the lock acquisition turns 6 scenarios red;
removing the lock-free rejection turns the degradation scenario red on its own.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): make the sync-lock timeout name a cause it can establish

The fail-closed lock surfaced the primitive's own timeout message to users for
the first time, and that message says the wait was on "another gitnexus
analyze" — a cause its detection path cannot establish. It is the same
confident-about-what-it-could-not-determine claim this PR exists to remove,
inherited rather than written.

The wrapper now throws its own. It names the group, the lock directory, the
operation, and the elapsed wait, and it says plainly that nothing was written.

The holder clause branches on `holderKnown`. The socket backend exposes no owner
metadata and reports a placeholder pid of -1, so on that backend — and on the
file backend's malformed or vanished-lock timeouts — the message says the lock
stayed held but the backend cannot identify who held it, rather than printing a
pid that means nothing.

The elapsed wait is measured by the wrapper. `IndexLockTimeoutError` carries
only `holder` and `holderKnown`; the figure exists solely inside the string
being replaced, so it had to be taken rather than read.

One pre-existing assertion changed with it: the timeout case asserted
`'Timed out after 600000ms'` from the inherited text, which is precisely the
message this replaces.

Mutation-verified: restoring the inherited message turns the three assertion
cases red and leaves the control — a real acquisition that succeeds — green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): stop a losing sync from downgrading the one that beat it to the lock

Serializing is not ordering. Both syncs run extraction outside the critical
section, so a total-failure sync that acquires second reads the winner's fresh
registry as `prior` and rewrites it with all-unreadable lists. The lock alone
does not prevent that — it only decides who goes second, and the loser then
overwrites a healthy registry with a description of its own failure.
Deterministically, not as a rare interleave.

The guard is a compare-and-swap on the registry file's own identity: stat
before acquiring, re-stat after, and write nothing when they differ. Identity is
presence plus size, mtime and inode — `writeContractRegistry` publishes through
write-then-rename, so a real replacement always changes the inode even if size
and mtime happen to collide.

Deliberately NOT keyed on `generatedAt`, for two independent reasons. It is
stamped when the registry object is built, before the lock is acquired, so a
winner that waited would write a value older than the loser's start. And the
preserve path carries it forward verbatim by design — it dates the contracts,
not the write — so after any preserve sync it does not date the write at all,
leaving the comparison blind on exactly the pairing this guards. A file-identity
compare also needs no cross-process clock agreement.

The skip reports the existing `preserved` outcome. Nothing was written and a
prior registry was kept, which is what that value already means; a new one would
falsify the guard asserting the sync tool's description names every reachable
outcome, and would fall through the CLI's outcome chain, which has no fallback.

The bridge metadata refresh is skipped too, which the plan did not specify.
`refreshPreservedBridgeMeta` stamps THIS run's repo lists into meta.json, and
meta.json is where cross-repo impact reads completeness — so writing it would
report as unaccounted-for exactly the repos the winning sync had just accounted
for. That is the same downgrade being refused, one file over. Skipping both is
what makes `preserved` an honest answer here.

Mutation-verified: removing the after-stat and the skip turns the three decisive
cases red while both non-misfire controls stay green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* refactor(group): run the bridge swap inside the caller's critical section

The bridge swap needed the group lock, and could not take it: `syncGroup`
already holds it when it calls `writeBridge`, and `acquireIndexLock` is not
reentrant. Acquiring inside the swap would deadlock every sync on the happy
path rather than on an edge case.

So the body splits the way this repo already splits this shape — a lock-free
`writeBridgeUnlocked` whose precondition is that the caller holds the lock, and
a thin `writeBridge` wrapper that acquires it for direct callers, mirroring
`registerRepoUnlocked` / `withRegistryLock`. `syncGroup` calls the inner one;
everything else keeps calling `writeBridge` and is now serialized by it.

`writeBridge`'s exported signature is byte-identical to before, so no caller
changed and nothing about the exported surface moved.

The precondition is enforced by a comment naming the single production call
site, which is what the existing precedent does. A type could carry it, but the
repo's own answer to this question is a comment, and diverging here would make
this the odd one out for no additional guarantee.

`refreshPreservedBridgeMeta` is deliberately left unsplit. Its one caller is
already inside the critical section and it has no test callers, so an acquiring
wrapper would be dead code standing in for a guarantee the caller already
provides — and moving the lock inside it would be the second acquisition this
change exists to avoid.

Scope: this delivers writer-writer exclusion only. The reader-side promotion of
a leftover `.bak` into place runs on ordinary reads, outside any lock, and is
not claimed here — the pairing check remains the reader's defense. Confirmed as
live behavior while writing the crash-recovery test, which asserts on file
state rather than through `bridgeExists` for exactly that reason.

One test file beyond the two the unit named had to change: a suite mocks
`bridge-db` to inject a `writeBridge` failure and exercise the bridge-write
warning. Once the sync calls `writeBridgeUnlocked`, that fault was being
injected into a function the path no longer calls, and the test went red. The
mock is repointed.

Mutation-verified three ways. Pointing the sync back at the acquiring wrapper
deadlocks a single UNCONTENDED sync — the evidence that the nesting defect is
real and that this split is what prevents it. Removing the wrapper's
acquisition turns the direct-write exclusion case red. Making the lock-free half
acquire for itself turns the held-lock case red.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test(hygiene): reach every tracked text file with the raw-byte guard

The guard claimed to protect tracked source from a raw NUL — the byte that
makes git classify a file binary and costs it its diff, its inline comments and
its three-way merge on GitHub. It matched on an end-anchored extension regex
covering the JavaScript family, so most of what this repo tracks was never
looked at: JSON, YAML, TOML, Markdown, snapshots, SQL, protobuf, the .NET
project files, the shell and batch scripts.

Worse, an extension regex cannot reach a file that has none. `Dockerfile`,
`CODEOWNERS`, `LICENSE`, the husky hook and every bare dotfile were unreachable
by construction — no amount of widening the pattern would have covered them —
so a second basename filter had to exist for the claim to be true.

It stays an allowlist rather than becoming "everything git tracks", because the
repo legitimately tracks binaries whose extensions must stay out.

The two filters together now collect every one of the 5000 tracked files except
31 — the 30 native prebuilds and one PNG — and those 31 are exactly the files
that carry a NUL. The allowlist no longer has a gap that is not a genuine
binary.

The planted-fixture cases route through the collector's own predicate rather
than straight into the scanner. The pre-existing fixture test bypassed the
filter entirely, so it could only ever prove the byte locator worked, never
that the collector would hand it the file — which is precisely how the gap
survived.

Mutation-verified both ways: removing the basename filter drops `.gitignore`
and `Dockerfile` from the planted results, and reverting the extension regex
drops `.json` and `.md`.

One added case is a preservation pin rather than proof — that tracked binary
formats stay out passes either way, and guards the allowlist from becoming a
denylist later.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test(hygiene): stop the byte guard reading the vendored grammar tree

Widening the guard to every tracked text format also pulled in the vendored
tree-sitter grammars, and those are where the bytes are: four generated
`parser.c` files come to 62 MB between them, Kotlin's alone 33.7 MB. Excluding
that root drops 76 files but 66% of the bytes the scan reads — 97 MB down to
33 MB.

The exclusion is a single anchored prefix, matched case-sensitively with
`startsWith`, and both halves of that matter. A `vendor` path-SEGMENT match
would also drop first-party fixtures this repo tracks under directories named
`vendor` and `Vendor` — a Kotlin one, a PHP one, and three files under
gitnexus-web — silently narrowing coverage while the assertion pinned the loss
in place. Case-insensitivity would do the same to a `Vendor` directory at the
excluded root's own level.

The root is named in the guard itself, so the claim that it covers every
tracked text file stays honest about the one place it deliberately does not
look.

The cost comment was wrong and is now measured rather than estimated. It said
"the scan is ~10 ms" — ambiguous between locating the byte and reading the
files, and stale in its byte basis. Locating is ~14 ms; the reads dominate it
by two orders of magnitude, which is the actual reason for the concurrency pool
and the actual reason this exclusion is worth having. Every figure was
re-derived from the finished file rather than carried over from a draft.

The header's claim that `git ls-files` "never descends into vendor" was already
false — vendored code is tracked, so all 106 of its files were being reported
and read. Corrected here, where the distinction becomes load-bearing.

Registered in the cross-platform list first and given a shard weight second.
The weight table is only consulted for files already in that list, so a weight
entry alone is inert and the shard test filters unregistered keys without
complaining. The three-way split stays within 1.01x of ideal.

Mutation-verified three ways: a case-insensitive segment match, a
case-sensitive segment match, and a case-insensitive anchored prefix each turn
an assertion red.

The casing half was initially unfalsifiable — nothing tracked is named
`gitnexus/Vendor/`, so a tracked-set assertion could not distinguish it. Rather
than leave the claim unpinned or invent a fixture, it is pinned on the
predicate with a synthetic path; the tracked-set assertions pin the anchoring.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test(group): make the strict-read test able to see which read ran

The file bound both registry exports to one mock:

    readRegistry:       (...args) => readRegistryMock(...args),
    readRegistryStrict: (...args) => readRegistryMock(...args),

so the case named for the strict read asserted a behavior it could not
attribute. Point the production call at the lenient export and every assertion
still holds, because the mock answers the same way whichever one is called.

That is not a hypothetical. With this file as it was, and `syncGroup` mutated to
call `readRegistry` instead of `readRegistryStrict`, all 32 tests passed — the
suite was blind to the exact substitution it exists to prevent, and the fix it
guards could have been reverted without a single red.

The exports now have separate mocks: the lenient one always resolves an empty
list, which is its real contract, and only the strict one is armed by the cases
that need a failure. The named case also asserts directly that the strict read
was called and the lenient one was not, so the attribution is explicit rather
than implied by an outcome.

No tests added — the unit is about what the existing ones can see.

Mutation-verified: the same substitution now turns 24 cases red, including the
named one, and everything stays green unmutated.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test(group): pin the CLI output branches this PR introduced

The three sync outcomes and the status table's new labels had no assertions.
Every one of them is a sentence about what happened on disk, and this PR
corrected several that were false — a preserve branch that announced it had not
written the file it rewrites, a status table that called an unreadable registry
a missing entry. Text that describes state, with nothing pinning it, is how
those got wrong in the first place.

Six cases drive the real CLI end to end, through the two shapes that need no
indexed repo: members absent from the registry, and members registered at a
storage path with no index file, which makes every repo unreadable. The file
header claimed no LadybugDB-backed command was driven end to end; that is no
longer true and it now says so.

Each branch was suppressed in turn and its assertion goes red — all five that
the plan named.

One of those mutations first reported PASS, and the cause is worth recording: the
string being suppressed also appears inside a neighbouring branch's comment, so
the harness silenced the wrong line. That is a bad mutation, not a weak test.
The harness now asserts the marker it suppresses is unique before trusting the
result, and the redone check goes red.

The plan's sixth scenario is already covered by an existing case that asserts
both labels in one table, so it is not duplicated. A seventh case was added
beyond the plan: without a populated-list case, "prints neither line" would pass
just as well against a CLI that never printed that line at all.

Adds about 15s of measured spawn time locally; CI runs these against the built
dist, which is materially faster per spawn.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test(group): assert the MCP payloads by exact shape, not by partial match

Nothing asserted what the group tools actually return. The sync response's
unreadable list and registry outcome, and the contract listing's incompleteness
fields, are documented in the tool descriptions an agent reads — and could have
been dropped in a refactor without a single test noticing.

The assertions are exact-shape rather than partial. A `toMatchObject` would let
a dropped key pass, which is precisely the regression these exist to catch: the
failure mode is an absent field, and a partial match is defined not to see one.
Absences are additionally asserted explicitly.

The tri-state has to survive the response boundary, and it is the reason exact
shape matters here more than usual. An absent `unreadableRepos` means the sync
never recorded what it could read, so the listing is a floor; an empty list
means it measured none; a populated list names them. Collapsing absent into
empty turns "we do not know" into "we checked, it is fine" — so a mutation that
replaces the conditional spread with `?? []` is covered specifically, not just
the outright deletion.

Mutation-verified per field: removing either sync forwarding line, deleting the
conditional spread, replacing it with the invent-empty form, dropping the
truncation triple, or hardcoding the provenance flag each turns an assertion
red.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(group): stop the bridge input narrowing what unreadableRepos means

The same field had three definitions. The registry and the bridge metadata both
say it covers a repo this sync could not extract from — an index that would not
open, or an extractor that threw partway through, one bucket because the
consequence is one thing. The bridge input said only "whose index could not be
opened", which describes one cause and silently excludes the other.

It now points at the registry's definition instead of restating it a third
time. A definition written once and referenced cannot drift; three copies of it
already had.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(group): record what the mtime pairing does and does not prove

The write-order fallback is a heuristic standing in for provenance, and a
future reader deciding whether to lean on it needs to know where it breaks
before they do. Both directions are now stated where the function is read
rather than only in the plan that introduced it.

The false-accept direction is a non-monotonic wall clock — mtime is realtime,
so an NTP step back, a snapshot restore, or container skew between the two
writes can leave a mis-paired set reading as ordered. Coarse filesystem
granularity is explicitly called out as NOT being that hazard, because it looks
like it: it collapses a pair written together to equal times, and equal is
accepted, which is the right answer for that pair.

The false-reject direction is any copy or restore that rewrites the database's
mtime after the metadata's. An intact legacy pair is demoted to a lower bound
and stays there until a sync re-stamps it, because nothing on the read path can
tell it apart from the swap window it imitates.

That second direction corrects a claim made while planning this work: that the
rule could only ever demote pairs already broken. It cannot. `cp -r` and
`rsync` without timestamp preservation both produce it on a healthy group, and
saying otherwise where the code is read would leave a future reader to discover
it the hard way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(storage): stop a corrupt registry quoting its own bytes into errors

`JSON.parse`'s SyntaxError embeds a window of the source around the failure —
V8 gives exactly ten characters either side — and the strict read rethrew it
untouched. The registry persists HTTPS remote URLs with their userinfo, so a
file that breaks next to one puts the credential into the error:

    Unexpected token 'L', ..."end.git"},LEAKCAN4RY"... is not valid JSON

The parse now has its own guarded region and reports the path and the failure
class, matching the two corrupt-registry errors already in this function.

The original error is discarded — not logged, not attached as `cause`. This
codebase's convention elsewhere is to hand the logger the Error so it captures
stack and cause, and following that convention here is precisely what would put
the byte window into the log. Under MCP stdio that log is written to the
client's log file on disk, so the thrown-error channel was never the only one
that mattered. The `catch` takes no binding, so the error cannot be reused by
accident later.

That was not theoretical: a sibling commit routes this message into
`unresolvableReason`, which `group status` returns to MCP clients and prints in
the CLI table. Every channel was traced — throw, cause, inspect with the full
chain, the logger, and both downstream consumers.

The leaking shape is narrower than it first appears, and worth recording. The
windowed message only fires when the parser fails at a value-start or trailing
position; a break inside a quoted string yields an unterminated-string error
carrying no window. So a plain mid-URL truncation does not leak — a short write
landing over a longer one does, leaving a URL fragment where a value was
expected. That is a reachable shape for the one machine-wide file every
gitnexus process writes.

The test asserts the message still names the path and the corruption class, not
only that the secret is absent. Asserting absence alone would stay green if the
message became empty.

Mutation-verified: restoring the raw rethrow brings the token back verbatim.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(storage): drop the stale lenient call-site count

The docstring said keeping `readRegistry`'s signature untouched leaves "its
nine other call sites" unaffected. There were thirteen when the discrepancy was
noticed and fourteen by the time it was fixed. The same figure appeared in the
test file's header.

Replaced rather than corrected. A count in prose next to code that moves is a
claim that goes stale without anything failing — which is the defect class this
change set exists to remove, so re-seeding a fresh number would be repeating it
with a longer fuse. The argument was never about the quantity: leaving the
signature alone keeps every lenient caller provably unaffected whether there is
one or fifty.

Also withdrawn while here: the claim that the bridge schema-version guards
diverge between call sites. They do not — the two forms are complements for
every value a writer can produce, there are three sites rather than the two
claimed, and all three agree. Recording a divergence that does not exist would
leave a future reader chasing it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(group): add an auditable finding-to-commit map

The Definition of Done claims every review finding has exactly one commit and
that reverting it reintroduces that finding and no other. Without a map that
claim is only checkable by whoever holds the review report, which is one person
for a short time.

The map lists all 28 primary findings against their commits, the three findings
whose suggested fix was deliberately not implemented and what shipped instead,
and the four defects found while executing that no reviewer raised.

It also records the revert contract honestly. Revertability is
dependency-aware, not absolute: the shared completeness helper has three
consumers, so reverting it alone does not build. That coupled set is named
rather than left for someone to discover mid-revert.

Two sections exist because the work produced them, not because the plan asked.
Six claims in the plan turned out to be contradicted by the code — among them a
scope predicate that would have reintroduced the bug its unit was closing, and
an assertion about the mtime rule that was simply wrong. Recording only the
findings would leave the impression the plan was followed as written. Five
residual risks are listed for the same reason, including that R14 is not met on
this PR: the diff attribute works locally but GitHub reads it from the base
side, so this PR's own sync.ts stays binary in the web view and every PR after
it renders as text.

Not under docs/ — that path is gitignored, so a map written there would never
reach the PR and the audit it exists for could not be performed by anyone else.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): read a version that is not a version as no provenance

Raised by the check bot on this PR, and real — the bot found one symptom of it;
the field splits four gates apart, not one.

`readBridgeMeta` accepted any numeric `version`, and `0` is this file's word for
"no provenance". A parseable but impossible value — negative, fractional — is
not a schema version, and each gate that reads the field disagreed about it:

  ensureBridgeReady      `> 0 && !== CURRENT`  → opens the bridge
  openBridgeDbReadOnly   `> 0 && !== CURRENT`  → opens the bridge
  bridgeExists           `=== 0 || === CURRENT` → says it is not there
  bridgeProvenanceUnknown `=== 0`               → reports the answer complete

Four verdicts about one file, and the last one is a fail-open of exactly the
class this PR exists to close: a bridge nothing can vouch for, reported as
fully accounted for.

The suggested fix was to widen the provenance check to `<= 0`. That closes the
reported symptom and leaves `bridgeExists` still disagreeing with both openers,
so it is fixed at the reader instead: a version that is not a positive integer
normalizes to the sentinel the gates were all written against. One change, four
gates agreeing by construction, rather than teaching each of them the same new
case and hoping the fifth reader remembers.

Infinity is covered too, though by the pre-existing type check rather than the
range one — JSON cannot carry it, so it arrives as `null`. Recorded at the test
so the case is not mistaken for proof of the range check.

Mutation-verified: restoring the loose numeric check turns the negative and
fractional cases red.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): stop a malformed contracts.json reading as an unresolvable registry entry

Raised by the check bot on this PR. Its stated mechanism was wrong — `loadMeta`
returns null on every error and `checkStaleness` catches everything, so neither
can throw — but its conclusion was right, and there is a concrete path it did
not name.

`readContractRegistry` is a bare `JSON.parse(content) as ContractRegistry` with
no shape check, and the snapshot lookup guarded only the registry object:

    registry?.repoSnapshots[repoPath]

The `?.` covers `registry` being null, not `repoSnapshots` being absent. A
contracts.json without that field — a legacy file, a hand-edit, a truncated
write — throws `TypeError: Cannot read properties of undefined`, which lands in
the catch that labels failures as unresolvable GLOBAL-registry entries. So a
group whose own contracts file is malformed reported every repo as a broken
registry row, sending the operator to repair a file that was fine.

An error from one cause presented as another, which is the defect this PR has
been removing everywhere else.

The optional chain closes the crash. The try is also narrowed to the call that
earns the label: only `resolveRepo` sits inside it now, so "did not resolve"
describes something that actually failed to resolve rather than whatever else
happened to throw nearby. The comment records why the other two calls in that
block cannot throw, so the next reader does not have to re-derive it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* refactor(group): give the completeness fold a module no native binding reaches

The shared fold ended up in `cross-impact.ts`, which statically imports
`bridge-db.ts` and through it the native LadybugDB binding. `groupContracts`
therefore reached it through `await import('./cross-impact.js')` — loading that
whole module graph to run a Set union and a ternary. Measured: 44-51ms and
8.4MB of RSS on first call, paid once per MCP server and once per
`gitnexus group contracts` invocation.

`completeness.ts` holds the vocabulary and the fold and imports nothing but
types. `service.ts` imports it statically; the lazy import and the comment
justifying it both go. `cross-impact.ts` re-exports so the three surfaces still
have one import site for the vocabulary.

Three other duplications collapse into the same move.

`traceCompleteness` was hand-writing `{truncated, truncationReason,
riskEpistemic}` — a third writer of the pair `truncationFields` exists to keep
mechanically linked (#2787), in the file the consolidation had just touched. It
calls the helper now.

`recordedRepoList` existed twice, byte-identical, one copy's docblock saying it
mirrored the other. That gate is the predicate the whole
absent-vs-empty-vs-populated distinction rests on, applied to the same two
lists on both the registry and the bridge — tightening one copy would have
fixed one surface silently. One definition now.

The trace's scope predicate compared repo paths with `===` while its sibling in
`cross-impact.ts`, added in the same change, went through `repoInSubgroup` with
a comment about not growing a second notion of membership. It had grown one:
the helper normalizes separators and strips trailing slashes, so the same
group.yaml spelling could be in scope for impact and out of scope for trace.

Also here: `registryIdentifies` was a third, weaker copy of the registry's path
rule — it skipped `realpath`, so a symlinked row would not match where the real
resolver would. It uses `canonicalizePath`/`registryPathEquals` now.
`contracts.json` is no longer respelled as a literal in `sync.ts`; `storage.ts`
owns the name it reads and writes. And the runtime-truncation predicate is
bound once instead of written out at both the flag and the reason, where
forgetting the second would label a retry-able answer `incomplete-sync`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(group): give the lost-the-race sync its own outcome instead of overloading preserved

A sync that finds contracts.json replaced while it waited for the lock reported
`registryOutcome: 'preserved'`. That value already meant something else, and the
two differ in exactly the thing the value is for: `preserved` rewrites the file
with this run's diagnostics; this path does not touch it and deliberately does
not record them.

So both surfaces stated something false about disk. The tool description told
agents `preserved` means "contracts.json was rewritten ... refreshing only
missingRepos/unreadableRepos to describe THIS run (the file changed)". The CLI
said "only the unreadable/missing repo lists were refreshed to describe THIS
run". On the lost-race branch nothing was written and the log line beside it
says so outright.

That is the defect class this whole change set removes, reintroduced by the
change set itself — and the reasoning recorded at the time makes it worse, not
better: a new value was rejected because it "would fall through cli/group.ts's
outcome chain, which has no fallback branch". A renderer limitation decided a
domain value, and the description then had to cover two states with one
sentence that fits one of them.

`superseded` is its own outcome now, described in its own words to agents and
rendered in its own words at the CLI. The registry on disk is FRESHER than this
response's diagnostics, which is the opposite of every other non-written
outcome and is why an agent needs to tell them apart.

The CLI renders from a `Record` keyed on the union, so the next outcome fails
the build here rather than printing nothing — the gap that made folding the
state in look like the cheap option.

The description guard is scoped per clause rather than over the whole string.
It forbade "untouched" anywhere, which was right when one clause could only lie
in that direction and wrong now that another clause is accurately untouched. It
also asserts the superseded clause says so, or the two collapse back into one
word for two states.

Found by the quality pass over this branch, not by review.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test(group): read bytes and stat through one handle, not two path lookups

CodeQL flagged both sites as `js/file-system-race`, high severity, and it is
right about the shape. `stat(path)` followed by `readFile(path)` is two
independent path resolutions with a window between them — the classic
check-then-use race.

It also made the assertions weaker than they read. These two tests exist to
prove a specific file was left untouched, and two lookups can land on different
inodes, so "the bytes and the mtime are both unchanged" was not actually a
statement about one file. The distinction is the whole point here rather than a
technicality.

`snapshotFile` opens the path once and takes both answers from that handle. The
race is gone because there is no second lookup, and the assertion now genuinely
concerns one inode.

I had previously triaged these as below the ruleset's threshold and left them
for the repository owner. That was wrong: they carry
`security_severity_level: high`, and the branch ruleset gates on
`high_or_higher`, so they were blocking the merge rather than sitting under it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Gergő Magyar <gergomagyar@icloud.com>
Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com>
2026-08-26 09:37:16 +01:00

1152 lines
50 KiB
TypeScript

import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest';
import * as fs from 'node:fs';
import fsp from 'node:fs/promises';
import * as path from 'node:path';
import * as os from 'node:os';
import { _captureLogger } from '../../../src/core/logger.js';
import type { BridgeHandle, GroupConfig, RepoHandle } from '../../../src/core/group/types.js';
import { BRIDGE_SCHEMA_VERSION } from '../../../src/core/group/bridge-schema.js';
import { makeGroupToolPort, writeGroupYaml } from './fixtures.js';
/**
* A repo that is registered but whose index cannot be opened must not be
* reported as a MISSING repo, and must not silently replace a good
* contracts.json with an empty one.
*
* The failure this pins: `syncGroup` wrapped `initLbug` + extraction in a bare
* `catch {}` that pushed the repo onto `missingRepos` and discarded the error.
* A LadybugDB storage-version mismatch therefore surfaced as "repo not found",
* `group sync` printed `0 contracts, 0 cross-links` and exited 0, and the
* existing registry was overwritten with an empty one.
*
* Three of these cases exist because mutation testing showed the original four
* could not see the change they were named after:
* - a two-repo case, because with exactly one configured repo
* `unreadableRepos.length === configuredRepoCount` holds whenever anything
* fails, so deleting the `=== configuredRepoCount` conjunct — turning "every
* repo failed" into "any repo failed" — passed everything;
* - an all-missing case, because deleting the `unreadableRepos.length > 0`
* conjunct was caught only by a 9.7 s integration test in another directory;
* - a log assertion, because deleting both `logger.warn` calls — the entire
* stated purpose of the change — passed everything too.
*/
const LBUG_VERSION_ERROR =
'LadybugDB unavailable for backend-repo. Another process may be rebuilding the index. ' +
'Retry later. (Runtime exception: Trying to read a database file with a different version. ' +
'Database file version: 43, Current build storage version: 40)';
const initLbugMock = vi.fn();
const readRegistryStrictMock = vi.fn();
/**
* A SEPARATE mock from the strict one, and that separation is the whole point.
*
* Both exports used to resolve to one mock, so the refuses-to-sync case below —
* which drives the read by rejecting — got the same rejection whichever export
* `syncGroup` called. It would have passed identically against the lenient read
* it exists to rule out, which is to say it measured nothing about which read is
* used.
*
* The implementation here is the lenient export's real contract: `readRegistry`
* swallows EACCES and a corrupt file alike and answers `[]`. Pointing
* `syncGroup` at it therefore turns an unreadable registry back into "no repo is
* registered" — every configured repo MISSING, the total-failure guard off, a
* good contracts.json replaced by an empty one at exit 0 — and the case goes
* red. On this path production reaches the lenient export only under
* `detect.workspace_deps`, which `makeConfig` leaves off, so no other case in
* this file can see the split.
*/
const readRegistryLenientMock = vi.fn(async (..._args: unknown[]): Promise<never[]> => []);
vi.mock('../../../src/core/lbug/pool-adapter.js', () => ({
initLbug: (...args: unknown[]) => initLbugMock(...args),
executeParameterized: vi.fn(async () => []),
pinRepo: vi.fn(() => () => {}),
getMaxResidentRepos: vi.fn(() => 5),
}));
vi.mock('../../../src/storage/repo-manager.js', () => ({
readRegistry: (...args: unknown[]) => readRegistryLenientMock(...args),
readRegistryStrict: (...args: unknown[]) => readRegistryStrictMock(...args),
}));
/**
* Armed by the bridge-write-failure suite at the bottom of this file, `null`
* everywhere else. There is no filesystem shape that makes the real writer fail
* while `writeContractRegistry` — same directory, one line earlier in
* `syncGroup` — still succeeds, and that ordering is the whole subject of the
* warning under test.
*/
let writeBridgeFailure: Error | null = null;
/**
* Only the read-only OPEN legs are stubbed, so `runGroupImpact` can read the
* metadata a preserve sync just wrote without a native LadybugDB open of a
* placeholder file. The bridge write, `writeBridgeMeta`, `readBridgeMeta` and
* `bridgeMetaMatchesFile` all travel their real implementations — they are the
* code under test here, and `syncGroup` reaches the bridge write through this
* module too. The wrapper below is a pass-through in every test that does not
* arm `writeBridgeFailure`.
*
* It intercepts `writeBridgeUnlocked`, NOT the exported `writeBridge`: the swap
* comes in two halves, and `syncGroup` calls the lock-free one because it is
* already inside `withGroupSyncLock` (a second acquisition of a non-reentrant
* lock would hang every sync). Arming the acquiring wrapper instead would inject
* a fault into a function this path never calls, and the failure branch below
* would go quietly untested.
*/
vi.mock('../../../src/core/group/bridge-db.js', async (importOriginal) => {
const actual = await importOriginal<typeof import('../../../src/core/group/bridge-db.js')>();
return {
...actual,
writeBridgeUnlocked: vi.fn(async (...args: Parameters<typeof actual.writeBridgeUnlocked>) => {
if (writeBridgeFailure) throw writeBridgeFailure;
return actual.writeBridgeUnlocked(...args);
}),
getCachedBridgeReadOnly: vi.fn(
async (groupDir: string) =>
({ _db: {}, _conn: {}, groupDir, _readOnly: true }) as BridgeHandle,
),
queryBridge: vi.fn(async () => [] as Array<Record<string, unknown>>),
closeBridgeDb: vi.fn(async () => undefined),
};
});
/**
* Armed by the concurrent-sync suite at the bottom of this file, `null`
* everywhere else. It runs INSIDE the real group sync lock — after this sync
* acquired it, before its persist section starts — which is the one window in
* which another sync's write can land: extraction runs OUTSIDE the lock, so a
* sync that queued behind a winner is holding stats it took before the winner
* ever wrote. Nothing in-process can reach that window otherwise, and a rare
* interleave is not a test.
*/
let whileWaitingForTheGroupLock: (() => Promise<void>) | null = null;
/**
* A pass-through in every test that does not arm the hook: the REAL lock is
* acquired, on the real `<groupDir>/sync-lock`, exactly as production does.
*/
vi.mock('../../../src/core/group/group-lock.js', async (importOriginal) => {
const actual = await importOriginal<typeof import('../../../src/core/group/group-lock.js')>();
return {
...actual,
withGroupSyncLock: <T>(groupDir: string, operation: () => Promise<T>): Promise<T> =>
actual.withGroupSyncLock(groupDir, async () => {
const hook = whileWaitingForTheGroupLock;
whileWaitingForTheGroupLock = null;
if (hook) await hook();
return operation();
}),
};
});
const { syncGroup } = await import('../../../src/core/group/sync.js');
const { runGroupImpact } = await import('../../../src/core/group/cross-impact.js');
const { bridgeMetaMatchesFile, closeAllCachedBridges, readBridgeMeta, writeBridgeMeta } =
await import('../../../src/core/group/bridge-db.js');
const registryEntry = (name: string, dir: string) => ({
name,
path: `/repos/${dir}`,
storagePath: `/repos/${dir}/.gitnexus`,
indexedAt: '2026-01-01T00:00:00.000Z',
lastCommit: 'abc123',
});
const REGISTRY = [registryEntry('backend-repo', 'backend'), registryEntry('web-repo', 'web')];
const makeConfig = (repos: Record<string, string>): GroupConfig => ({
version: 1,
name: 'test',
description: '',
repos,
links: [],
packages: {},
detect: {
http: true,
grpc: false,
thrift: false,
topics: false,
shared_libs: false,
embedding_fallback: false,
includes: false,
workspace_deps: false,
},
matching: { bm25_threshold: 0.7, embedding_threshold: 0.65, max_candidates_per_step: 3 },
});
/**
* Resolve handles from a table keyed on the registry name, so a multi-repo case
* needs no branching inside the test body. An unknown name resolves to `null`,
* which is the production "not in the registry" answer.
*/
const handleTable = (names: readonly string[]) => {
const byName = new Map<string, RepoHandle>(
names.map((name) => [
name,
{
id: `pool-${name}`,
path: `/repos/${name}`,
repoPath: `/repos/${name}`,
storagePath: `/repos/${name}/.gitnexus`,
},
]),
);
return async (registryName: string): Promise<RepoHandle | null> =>
byName.get(registryName) ?? null;
};
/** `initLbug` is called with the pool id, so failures can be keyed on the repo. */
const failInitFor = (failingPoolIds: ReadonlySet<string>) => async (poolId: unknown) => {
if (failingPoolIds.has(String(poolId))) throw new Error(LBUG_VERSION_ERROR);
};
const PRIOR_REGISTRY = {
version: 1,
generatedAt: '2026-01-01T00:00:00.000Z',
repoSnapshots: {},
missingRepos: [],
contracts: [{ contractId: 'http::GET::/api/users' }],
crossLinks: [{ contractId: 'http::GET::/api/users' }],
};
/**
* The one warning that describes the RUN rather than a single repo: it is the
* only record carrying the whole-run repo lists. The per-repo load failures
* logged beside it carry `repo` / `groupPath` instead, so selecting on the list
* field cannot pick one of those up by accident.
*/
const totalFailureWarning = (cap: ReturnType<typeof _captureLogger>) =>
cap.records().find((r) => r.level === 40 && Array.isArray(r.unreadableRepos));
/**
* Read a file's bytes and its stat through ONE open handle.
*
* `stat(path)` followed by `readFile(path)` is two independent path
* resolutions with a window between them — a real check-then-use race, and one
* CodeQL flags as `js/file-system-race`. It also makes the assertion weaker
* than it reads: the two calls can land on different inodes, so "the bytes and
* the mtime are both unchanged" would not actually be a statement about one
* file. Since these tests exist to prove a specific file was left alone, that
* distinction is the whole point rather than a technicality.
*
* One handle, both answers, no second lookup.
*/
const snapshotFile = async (
filePath: string,
): Promise<{ text: string; size: number; mtimeMs: number }> => {
const handle = await fsp.open(filePath, 'r');
try {
const [bytes, stat] = await Promise.all([handle.readFile(), handle.stat()]);
return { text: bytes.toString('utf8'), size: stat.size, mtimeMs: stat.mtimeMs };
} finally {
await handle.close();
}
};
describe('syncGroup with an unreadable index', () => {
let groupDir: string;
beforeEach(() => {
initLbugMock.mockReset();
readRegistryStrictMock.mockReset();
readRegistryStrictMock.mockResolvedValue(REGISTRY);
// `mockClear`, not `mockReset`: the lenient answer IS its implementation
// (see its declaration), so resetting would erase the very behaviour that
// makes calling it distinguishable from calling the strict one.
readRegistryLenientMock.mockClear();
groupDir = fs.mkdtempSync(path.join(os.tmpdir(), 'gitnexus-sync-unreadable-'));
});
afterEach(() => {
fs.rmSync(groupDir, { recursive: true, force: true });
});
it('reports an unopenable index as unreadable, not missing', async () => {
initLbugMock.mockRejectedValue(new Error(LBUG_VERSION_ERROR));
const result = await syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), {
skipWrite: true,
});
expect(result.unreadableRepos).toEqual(['app/backend']);
// The repo IS registered — calling it "missing" sends the operator to
// `gitnexus analyze` for a problem that indexing will not fix.
expect(result.missingRepos).toEqual([]);
});
it('still reports a genuinely unregistered repo as missing', async () => {
const result = await syncGroup(makeConfig({ 'app/ghost': 'not-in-registry' }), {
skipWrite: true,
});
expect(result.missingRepos).toEqual(['app/ghost']);
expect(result.unreadableRepos).toEqual([]);
});
it('logs the underlying load error, with the repo it belongs to', async () => {
initLbugMock.mockRejectedValue(new Error(LBUG_VERSION_ERROR));
const cap = _captureLogger();
try {
await syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), { skipWrite: true });
} finally {
cap.restore();
}
// The whole point of the change is that this error reaches the operator.
// Asserting only on `unreadableRepos` left both `logger.warn` calls
// deletable with every test still green.
const warnings = cap.records().filter((r) => r.level === 40);
const loadFailure = warnings.find((r) => String(r.repo ?? '') === 'backend-repo');
expect(loadFailure).toBeDefined();
expect(String(loadFailure?.groupPath)).toBe('app/backend');
expect(JSON.stringify(loadFailure?.err)).toContain('Current build storage version');
});
it('preserves the previous contracts and refreshes the diagnostics when nothing could be read', async () => {
initLbugMock.mockRejectedValue(new Error(LBUG_VERSION_ERROR));
const contractsPath = path.join(groupDir, 'contracts.json');
fs.writeFileSync(contractsPath, JSON.stringify(PRIOR_REGISTRY));
const result = await syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), { groupDir });
expect(result.unreadableRepos).toEqual(['app/backend']);
expect(result.registryOutcome).toBe('preserved');
const onDisk = JSON.parse(fs.readFileSync(contractsPath, 'utf8')) as Record<string, unknown>;
// The contracts are the previous run's and are kept verbatim — an
// extraction that read nothing is not evidence that the group has none.
expect(onDisk.contracts).toEqual(PRIOR_REGISTRY.contracts);
expect(onDisk.crossLinks).toEqual(PRIOR_REGISTRY.crossLinks);
// `generatedAt` dates the contracts, which did not change, so it does not
// move either — otherwise `group status` would claim this run produced them.
expect(onDisk.generatedAt).toBe(PRIOR_REGISTRY.generatedAt);
// ...but the diagnostic describing THIS run is refreshed, which is what
// makes `gitnexus group status` able to explain the failure afterwards.
expect(onDisk.unreadableRepos).toEqual(['app/backend']);
});
it('writes nothing at all when there is no previous registry to preserve', async () => {
initLbugMock.mockRejectedValue(new Error(LBUG_VERSION_ERROR));
const result = await syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), { groupDir });
// NOT `preserved`. Nothing exists to preserve, and the CLI turns that word
// into "the contracts from the previous sync are preserved" — which sends
// an operator whose group has never synced looking for a file that has
// never existed. Same class of confident-wrong-answer as the rest of this.
expect(result.registryOutcome).toBe('no-prior-registry');
expect(fs.existsSync(path.join(groupDir, 'contracts.json'))).toBe(false);
});
it('reports `preserved` only when a prior registry was actually refreshed', async () => {
initLbugMock.mockRejectedValue(new Error(LBUG_VERSION_ERROR));
fs.writeFileSync(path.join(groupDir, 'contracts.json'), JSON.stringify(PRIOR_REGISTRY));
const result = await syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), { groupDir });
expect(result.registryOutcome).toBe('preserved');
});
it('does not report `preserved` when the prior registry will not parse', async () => {
// An unparseable prior is not a thing that got carried forward either.
initLbugMock.mockRejectedValue(new Error(LBUG_VERSION_ERROR));
fs.writeFileSync(path.join(groupDir, 'contracts.json'), '{"truncated": ');
const result = await syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), { groupDir });
expect(result.registryOutcome).toBe('no-prior-registry');
// ...and the unparseable file is left exactly as it was, not replaced.
expect(fs.readFileSync(path.join(groupDir, 'contracts.json'), 'utf8')).toBe('{"truncated": ');
});
it('names the previous sync in the total-failure warning when a prior registry was kept', async () => {
// This warning used to be emitted BEFORE the prior registry was resolved,
// so it promised "the contracts from the previous sync" without knowing
// whether there were any. This is the branch on which that promise is true.
initLbugMock.mockRejectedValue(new Error(LBUG_VERSION_ERROR));
fs.writeFileSync(path.join(groupDir, 'contracts.json'), JSON.stringify(PRIOR_REGISTRY));
const cap = _captureLogger();
let result;
try {
result = await syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), { groupDir });
} finally {
cap.restore();
}
const warning = totalFailureWarning(cap);
expect(warning).toBeDefined();
// The log and the console say the same thing about which of the two
// happened: the CLI picks its sentence from `registryOutcome`, and this is
// the outcome whose sentence keeps the previous contracts.
expect(result.registryOutcome).toBe('preserved');
expect(String(warning?.msg)).toContain('previous sync');
// Still a warning, still carrying the lists that name the cause.
expect(warning?.level).toBe(40);
expect(warning?.unreadableRepos).toEqual(['app/backend']);
expect(warning?.missingRepos).toEqual([]);
});
it('does not claim anything was preserved when there is no prior registry', async () => {
// The same total failure with nothing on disk to preserve. The warning said
// the contracts from the previous sync were being kept — to an operator
// whose group has never synced, about a file that has never existed, while
// the console line for this same run says the opposite. What the message
// says about disk has to be what happened on it.
initLbugMock.mockRejectedValue(new Error(LBUG_VERSION_ERROR));
const cap = _captureLogger();
let result;
try {
result = await syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), { groupDir });
} finally {
cap.restore();
}
const warning = totalFailureWarning(cap);
expect(warning).toBeDefined();
expect(result.registryOutcome).toBe('no-prior-registry');
expect(String(warning?.msg)).not.toMatch(/previous sync|preserv|keeping|kept/i);
expect(String(warning?.msg)).toContain('no previous contracts.json');
// ...and it is still a warning carrying the same lists as the branch above.
expect(warning?.level).toBe(40);
expect(warning?.unreadableRepos).toEqual(['app/backend']);
expect(warning?.missingRepos).toEqual([]);
});
it('still writes when only SOME configured repos are unreadable', async () => {
// The case that pins the word "every" in `everyRepoFailed`. With a single
// configured repo, "every repo failed" and "any repo failed" are the same
// predicate, so the guard could be widened to abort on a single skewed repo
// in a five-repo group — silently freezing contracts.json forever — with
// nothing going red.
initLbugMock.mockImplementation(failInitFor(new Set(['pool-backend-repo'])));
const result = await syncGroup(
makeConfig({ 'app/backend': 'backend-repo', 'app/web': 'web-repo' }),
{ groupDir, resolveRepoHandle: handleTable(['backend-repo', 'web-repo']) },
);
expect(result.unreadableRepos).toEqual(['app/backend']);
expect(result.missingRepos).toEqual([]);
expect(result.registryOutcome).toBe('written');
const onDisk = JSON.parse(
fs.readFileSync(path.join(groupDir, 'contracts.json'), 'utf8'),
) as Record<string, unknown>;
// The partial result records which repo is unaccounted for, so a reader of
// contracts.json can tell a small registry from a complete one.
expect(onDisk.unreadableRepos).toEqual(['app/backend']);
});
it('records an empty unreadable list on a clean sync, not an absent one', async () => {
// `[]` is a measurement — "this sync accounted for every repo" — and it is
// a different claim from a registry that never recorded the field. Omitting
// the empty case made that state unreachable: every clean sync wrote a
// registry whose `unreadableRepos` was absent, so `gitnexus group status`
// reported it as not recorded and told the operator to re-run the sync that
// had just succeeded.
const result = await syncGroup(
makeConfig({ 'app/backend': 'backend-repo', 'app/web': 'web-repo' }),
{ groupDir, resolveRepoHandle: handleTable(['backend-repo', 'web-repo']) },
);
expect(result.unreadableRepos).toEqual([]);
expect(result.registryOutcome).toBe('written');
const onDisk = JSON.parse(
fs.readFileSync(path.join(groupDir, 'contracts.json'), 'utf8'),
) as Record<string, unknown>;
expect(onDisk).toHaveProperty('unreadableRepos');
expect(onDisk.unreadableRepos).toEqual([]);
});
it('still writes when every repo is merely MISSING and none failed to load', async () => {
// A group whose repos were all deregistered legitimately syncs to empty.
// The guard must stay off here: it is gated on a load ERROR, not on an
// empty result. Dropping the `unreadableRepos.length > 0` conjunct would
// turn a deliberate deregistration into a registry frozen forever.
const result = await syncGroup(
makeConfig({ 'app/ghost': 'not-in-registry', 'app/phantom': 'also-absent' }),
{ groupDir },
);
expect(result.unreadableRepos).toEqual([]);
expect(result.missingRepos).toEqual(['app/ghost', 'app/phantom']);
expect(result.registryOutcome).toBe('written');
expect(fs.existsSync(path.join(groupDir, 'contracts.json'))).toBe(true);
});
it('does not claim to preserve a file on a dry run', async () => {
initLbugMock.mockRejectedValue(new Error(LBUG_VERSION_ERROR));
const cap = _captureLogger();
let result;
try {
result = await syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), { skipWrite: true });
} finally {
cap.restore();
}
expect(result.registryOutcome).toBe('not-attempted');
// The total-failure warning talks about an existing contracts.json. A
// caller that asked not to write may not even have a group directory, so
// telling it the file was left untouched describes a file that need not
// exist.
// Selected on the sentence both total-failure messages share, so this stays
// decisive whichever of the two the persisting path would have emitted.
const totalFailureWarnings = cap
.records()
.filter((r) => String(r.msg ?? '').includes('No repo in this group could be read'));
expect(totalFailureWarnings).toEqual([]);
});
it('refuses to sync when the global registry cannot be read', async () => {
// `readRegistry` swallows every failure and returns `[]`, so an EACCES or a
// truncated registry.json presented as "no repo is registered": every
// configured repo resolved to MISSING, the total-failure guard stayed off
// (it needs a load error), and a good contracts.json was replaced by an
// empty one at exit 0. That is an unreadable condition reported as missing,
// one frame above the code this change fixes.
//
// Only the STRICT export is armed to reject. The lenient one is a separate
// mock answering `[]` — production's own lenient behaviour — so a `syncGroup`
// reading through it never sees this failure at all: it would sync a group
// whose every repo is "unregistered" and overwrite the prior registry, which
// is what makes each of the three assertions below a statement about which
// read was used rather than about EACCES.
const eacces = Object.assign(new Error('EACCES: permission denied'), { code: 'EACCES' });
readRegistryStrictMock.mockRejectedValue(eacces);
const contractsPath = path.join(groupDir, 'contracts.json');
fs.writeFileSync(contractsPath, JSON.stringify(PRIOR_REGISTRY));
await expect(
syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), { groupDir }),
).rejects.toThrow('EACCES');
expect(JSON.parse(fs.readFileSync(contractsPath, 'utf8'))).toEqual(PRIOR_REGISTRY);
// The direct form of the same claim, so a regression names itself instead of
// arriving as "expected a rejection, got a resolved sync".
expect(readRegistryLenientMock).not.toHaveBeenCalled();
expect(readRegistryStrictMock).toHaveBeenCalled();
});
});
/**
* The preserve path rewrites `contracts.json` and deliberately does NOT rebuild
* `bridge.lbug` — the contracts that bridge holds are the ones being preserved,
* so rebuilding it from an extraction that read nothing is the one write that
* could lose them.
*
* But `meta.json`, not `contracts.json`, is where `runGroupImpact` reads
* completeness from. Leaving it alone therefore left the two files telling
* different stories: `contracts.json` said "this sync could not read app/backend"
* while a cross-repo query, reading the previous sync's metadata, answered
* `{ cross: [], truncated: false }` — fully accounted for. That is a confident
* wrong answer about the exact thing the completeness channel exists to make
* legible, and it is what R6 forbids.
*
* Refreshing the metadata is not free, though, and the naive version of it is
* worse than the bug. This file rewrites `meta.json` ATOMICALLY, so its mtime
* becomes now while `bridge.lbug`'s stays old — which is precisely the shape
* the unstamped write-order rule ACCEPTS. A refresh that just carried the old
* fields forward would therefore LAUNDER a pair that was already broken into
* one that passes `bridgeMetaMatchesFile`. Hence the explicit marker, and hence
* the cases below that pin a broken pair as still broken afterwards.
*/
describe('the preserve path and the bridge metadata beside it', () => {
let home: string;
let groupDir: string;
let dbPath: string;
let metaPath: string;
/** Fixed, whole-second instants — exactly representable on any filesystem. */
const WRITTEN_AT = new Date('2026-01-01T00:00:00.000Z');
const TEN_SECONDS_LATER = new Date('2026-01-01T00:00:10.000Z');
const PRIOR_META_GENERATED_AT = '2026-01-01T00:00:00.000Z';
beforeEach(async () => {
initLbugMock.mockReset();
readRegistryStrictMock.mockReset();
readRegistryStrictMock.mockResolvedValue(REGISTRY);
home = await fsp.mkdtemp(path.join(os.tmpdir(), 'gitnexus-preserve-bridge-'));
groupDir = path.join(home, 'groups', 'waveful');
dbPath = path.join(groupDir, 'bridge.lbug');
metaPath = path.join(groupDir, 'meta.json');
await writeGroupYaml(groupDir, ['app/backend']);
});
afterEach(async () => {
await closeAllCachedBridges();
await fsp.rm(home, { recursive: true, force: true });
});
const seedPriorRegistry = (): Promise<void> =>
fsp.writeFile(path.join(groupDir, 'contracts.json'), JSON.stringify(PRIOR_REGISTRY));
/** A stamped pair that matches: what a successful `writeBridge` leaves behind. */
const seedMatchingPair = async (): Promise<void> => {
await fsp.writeFile(dbPath, 'the previous sync database');
const stat = await fsp.stat(dbPath);
await writeBridgeMeta(groupDir, {
version: BRIDGE_SCHEMA_VERSION,
generatedAt: PRIOR_META_GENERATED_AT,
bridgeSize: stat.size,
bridgeMtimeMs: stat.mtimeMs,
missingRepos: [],
unreadableRepos: [],
});
};
/**
* The legacy shape, broken: metadata with no stamp sitting beside a database
* that was replaced after it. `unstampedMetaPairsByWriteOrder` is the ONLY
* thing that can see this, and it sees it purely through the two file times —
* which is why an atomic rewrite of `meta.json` erases the evidence.
*/
const seedUnstampedPairWithNewerDatabase = async (): Promise<void> => {
await fsp.writeFile(dbPath, 'a database swapped in after the metadata');
await writeBridgeMeta(groupDir, {
version: BRIDGE_SCHEMA_VERSION,
generatedAt: PRIOR_META_GENERATED_AT,
missingRepos: [],
unreadableRepos: [],
});
await fsp.utimes(metaPath, WRITTEN_AT, WRITTEN_AT);
await fsp.utimes(dbPath, TEN_SECONDS_LATER, TEN_SECONDS_LATER);
};
const runTotalFailureSync = () => {
initLbugMock.mockRejectedValue(new Error(LBUG_VERSION_ERROR));
return syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), { groupDir });
};
const runSuccessfulSync = () => {
initLbugMock.mockReset();
return syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), {
groupDir,
resolveRepoHandle: handleTable(['backend-repo']),
});
};
const runImpact = () =>
runGroupImpact(
{ port: makeGroupToolPort(home), gitnexusDir: home },
{ name: 'waveful', repo: 'app/backend', target: 'publish', direction: 'upstream' },
);
const pairsAfterwards = async (): Promise<boolean> =>
bridgeMetaMatchesFile(groupDir, await readBridgeMeta(groupDir));
it('reports the repos this sync could not read as a lower bound on the next cross-repo query', async () => {
// The headline case, and the one that makes `contracts.json` and `group
// impact` describe the same set of unaccounted repos. Every other signal
// says "complete": the local walk finished, the bridge returned no
// crossings, no cap and no clock fired.
await seedPriorRegistry();
await seedMatchingPair();
const result = await runTotalFailureSync();
expect(result.registryOutcome).toBe('preserved');
const impact = await runImpact();
expect(impact).toMatchObject({
cross: [],
truncated: true,
truncationReason: 'incomplete-sync',
riskEpistemic: 'lower-bound',
truncatedRepos: ['app/backend'],
});
});
it('leaves the bridge database itself byte-for-byte untouched', async () => {
// The contracts this bridge holds are the ones being preserved. A refresh
// that rebuilt it would be the single write capable of losing them.
await seedPriorRegistry();
await seedMatchingPair();
const before = await snapshotFile(dbPath);
await runTotalFailureSync();
const after = await snapshotFile(dbPath);
expect(after.text).toBe(before.text);
expect(after.size).toBe(before.size);
expect(after.mtimeMs).toBe(before.mtimeMs);
});
it('keeps a stamped pair that already failed the check failing, with its stamp untouched', async () => {
// Re-stamping here would MANUFACTURE provenance: it would declare that this
// metadata describes the database beside it, which is the one thing the
// failed check just said is not known. The stamp fields are carried through
// verbatim instead — dropping them would leave an unstamped file whose
// freshly-moved mtime the write-order rule then accepts.
await seedPriorRegistry();
await fsp.writeFile(dbPath, 'a database this metadata was never written for');
await writeBridgeMeta(groupDir, {
version: BRIDGE_SCHEMA_VERSION,
generatedAt: PRIOR_META_GENERATED_AT,
bridgeSize: 999_999,
bridgeMtimeMs: 1_700_000_000_000,
missingRepos: [],
unreadableRepos: [],
});
expect(await pairsAfterwards()).toBe(false);
await runTotalFailureSync();
const after = await readBridgeMeta(groupDir);
expect(after.bridgeSize).toBe(999_999);
expect(after.bridgeMtimeMs).toBe(1_700_000_000_000);
expect(after.provenanceUnknown).toBe(true);
expect(after.unreadableRepos).toEqual(['app/backend']);
expect(await pairsAfterwards()).toBe(false);
});
it('keeps an unstamped pair that already failed the check failing, though the rewrite moves meta.json to now', async () => {
// The laundering case, and the only shape that exercises the write-order
// rule. Before the sync the database is NEWER than the metadata beside it,
// which is the inverted write order that rule rejects. The atomic rewrite
// then makes `meta.json` the newer file — the exact shape it ACCEPTS — so
// without an explicit marker a preserve sync would hand back "verified" for
// a pair it just found broken.
await seedPriorRegistry();
await seedUnstampedPairWithNewerDatabase();
expect(await pairsAfterwards()).toBe(false);
await runTotalFailureSync();
const dbStat = await fsp.stat(dbPath);
const metaStat = await fsp.stat(metaPath);
// The evidence the write-order rule reads has genuinely been inverted...
expect(metaStat.mtimeMs).toBeGreaterThanOrEqual(dbStat.mtimeMs);
const after = await readBridgeMeta(groupDir);
// ...no stamp was invented to replace it...
expect(after.bridgeSize).toBeUndefined();
expect(after.bridgeMtimeMs).toBeUndefined();
// ...and the verdict survives in the metadata, which is the only place it
// can, because the refresh cannot avoid moving the mtime.
expect(after.provenanceUnknown).toBe(true);
expect(await pairsAfterwards()).toBe(false);
const impact = await runImpact();
expect(impact).toMatchObject({
truncated: true,
truncationReason: 'incomplete-sync',
riskEpistemic: 'lower-bound',
});
});
it('never writes either reader-side field back into meta.json', async () => {
// `repoListsUnreadable` and `pairedWithDatabase` are things a READER
// computes ABOUT a file; both are documented NEVER PERSISTED. This path is
// the first code to read metadata and write it back, so a naive
// `writeBridgeMeta(await readBridgeMeta(dir))` persists whichever of them
// the read produced. A stale `pairedWithDatabase: true` on disk is actively
// poisonous: it tells every future reader the pair was verified.
await seedPriorRegistry();
await fsp.writeFile(dbPath, 'db');
await fsp.writeFile(
metaPath,
JSON.stringify({
version: BRIDGE_SCHEMA_VERSION,
generatedAt: PRIOR_META_GENERATED_AT,
// Not a list of repo paths, so `readBridgeMeta` answers with
// `repoListsUnreadable: true` on the object this path then rewrites.
missingRepos: { 'app/backend': true },
// A foreign writer, a hand-edit, or an earlier naive round-trip.
pairedWithDatabase: true,
}),
);
await runTotalFailureSync();
const raw = JSON.parse(await fsp.readFile(metaPath, 'utf8')) as Record<string, unknown>;
expect(raw).not.toHaveProperty('pairedWithDatabase');
expect(raw).not.toHaveProperty('repoListsUnreadable');
// ...and the unusable list was replaced by this run's real measurement,
// rather than being carried forward as garbage.
expect(raw.missingRepos).toEqual([]);
expect(raw.unreadableRepos).toEqual(['app/backend']);
});
it('completes when there is no bridge.lbug for the metadata to describe', async () => {
// `writeBridge` can leave this behind: the old database is renamed aside
// and the new one never arrives. The refresh must not stat a file that is
// not there, and must not vouch for one either.
await seedPriorRegistry();
await writeBridgeMeta(groupDir, {
version: BRIDGE_SCHEMA_VERSION,
generatedAt: PRIOR_META_GENERATED_AT,
bridgeSize: 4096,
bridgeMtimeMs: 1_700_000_000_000,
missingRepos: [],
unreadableRepos: [],
});
const result = await runTotalFailureSync();
expect(result.registryOutcome).toBe('preserved');
expect(fs.existsSync(dbPath)).toBe(false);
const after = await readBridgeMeta(groupDir);
expect(after.provenanceUnknown).toBe(true);
// Carried through verbatim: the stamp still records which database this
// metadata was written for, which is information, not a claim about what
// is on disk now.
expect(after.bridgeSize).toBe(4096);
expect(after.bridgeMtimeMs).toBe(1_700_000_000_000);
expect(after.unreadableRepos).toEqual(['app/backend']);
// The query that follows answers rather than throwing. With no database
// there is nothing to answer FROM, so it names the missing file and sends
// the operator to `group sync` — never a confident "nothing depends on
// this". (The lower-bound answer is the shape above, where a database IS
// present and the marker is what stops it being trusted.)
const impact = await runImpact();
expect(impact).toMatchObject({ error: expect.stringContaining('No bridge.lbug') });
});
it('does not manufacture metadata for a bridge that has never existed', async () => {
// Neither file is on disk, so there is no pair that could disagree with
// anything and nothing to keep honest. `readBridgeMeta` already answers
// `version: 0` — provenance unknown — for an absent file, and writing a
// `version: 0` file that says the same thing only invents state.
await seedPriorRegistry();
await runTotalFailureSync();
expect(fs.existsSync(metaPath)).toBe(false);
expect(fs.existsSync(dbPath)).toBe(false);
});
it('records this run against a database whose metadata is missing entirely', async () => {
// The other half of the pair being absent. The database is real and the
// metadata is gone — provenance is already unknown, and staying silent
// costs the operator the NAMES of the repos this run could not read.
await seedPriorRegistry();
await fsp.writeFile(dbPath, 'a database with no metadata beside it');
await runTotalFailureSync();
const after = await readBridgeMeta(groupDir);
expect(after.provenanceUnknown).toBe(true);
expect(after.unreadableRepos).toEqual(['app/backend']);
expect(await pairsAfterwards()).toBe(false);
});
it('does not launder the pair it already marked on a second preserve run', async () => {
// The invariant in its strongest form: no preserve run ever increases the
// number of pairs that pass the check. The second run reads metadata that
// now carries the marker, and the marker has to survive its own rewrite.
await seedPriorRegistry();
await seedUnstampedPairWithNewerDatabase();
await runTotalFailureSync();
expect(await pairsAfterwards()).toBe(false);
await runTotalFailureSync();
const after = await readBridgeMeta(groupDir);
expect(after.provenanceUnknown).toBe(true);
expect(await pairsAfterwards()).toBe(false);
});
it('clears the marker on the next successful sync', async () => {
// Nothing clears the marker deliberately: a successful `writeBridge`
// builds fresh metadata from a literal and simply never sets the field.
// That is what keeps a marked bridge from being marked forever.
await seedPriorRegistry();
await seedUnstampedPairWithNewerDatabase();
await runTotalFailureSync();
expect((await readBridgeMeta(groupDir)).provenanceUnknown).toBe(true);
const ok = await runSuccessfulSync();
expect(ok.registryOutcome).toBe('written');
const after = await readBridgeMeta(groupDir);
expect(after.provenanceUnknown).toBeUndefined();
expect(await pairsAfterwards()).toBe(true);
});
it('control: a successful sync writes a pair that passes the check, unmarked', async () => {
// Without this, "the marker is absent after a good sync" could be true
// because the marker is absent from everything.
const ok = await runSuccessfulSync();
expect(ok.registryOutcome).toBe('written');
const after = await readBridgeMeta(groupDir);
expect(after.provenanceUnknown).toBeUndefined();
expect(after.unreadableRepos).toEqual([]);
expect(await pairsAfterwards()).toBe(true);
});
});
/**
* The branch taken when `writeBridge` throws. `contracts.json` has already been
* written and is canonical by then, so the failure is a recoverable degradation
* — and the warning is the ONLY thing this branch produces. The return value,
* `registryOutcome` and every file on disk are identical whether the sentence
* is true or not, which is why the text needs an assertion of its own instead of
* borrowing a state assertion from elsewhere in this file.
*/
describe('the warning after a failed bridge write', () => {
let groupDir: string;
beforeEach(() => {
initLbugMock.mockReset();
readRegistryStrictMock.mockReset();
readRegistryStrictMock.mockResolvedValue(REGISTRY);
writeBridgeFailure = null;
groupDir = fs.mkdtempSync(path.join(os.tmpdir(), 'gitnexus-sync-bridge-write-'));
});
afterEach(async () => {
writeBridgeFailure = null;
await closeAllCachedBridges();
fs.rmSync(groupDir, { recursive: true, force: true });
});
const runSync = () =>
syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), {
groupDir,
resolveRepoHandle: handleTable(['backend-repo']),
});
/** The bridge-failure warning is the only record carrying `groupDir`. */
const bridgeWarning = (cap: ReturnType<typeof _captureLogger>) =>
cap.records().find((r) => r.level === 40 && typeof r.groupDir === 'string');
it('names the registry as intact and does not promise a truncation this branch never reports', async () => {
writeBridgeFailure = new Error('ENOSPC: no space left on device');
const cap = _captureLogger();
let result;
try {
result = await runSync();
} finally {
cap.restore();
}
// The registry write happens before the bridge write and is not rolled back
// — the reason this failure is survivable at all.
expect(result.registryOutcome).toBe('written');
const warning = bridgeWarning(cap);
expect(warning).toBeDefined();
expect(String(warning?.msg)).toContain('contracts.json is intact');
// The claim the code does not keep. A failed `writeBridge` leaves the
// PREVIOUS sync's database and the metadata stamped for it untouched, so the
// next cross-repo query reads a pair that checks out, finds no unreadable
// repos recorded in it, and answers `truncated: false` — from contracts this
// sync has already superseded. Nothing on this branch marks the bridge at
// all, so telling the operator to wait for `truncated` is telling them to
// wait for a signal that is never coming.
expect(String(warning?.msg)).not.toMatch(/truncat/i);
// What the code does guarantee instead: the registry is the good copy, the
// bridge may still answer from the previous sync, and only another sync
// replaces it.
expect(String(warning?.msg)).toMatch(/previous sync/i);
expect(String(warning?.msg)).toContain('group sync');
// ...and the underlying failure still reaches the operator.
expect(String(warning?.err)).toContain('ENOSPC');
});
it('control: a sync whose bridge write succeeds emits no such warning', async () => {
// Without this, "the warning does not promise a truncation" could be true
// because no warning is emitted on any run at all.
const cap = _captureLogger();
let result;
try {
result = await runSync();
} finally {
cap.restore();
}
expect(result.registryOutcome).toBe('written');
expect(bridgeWarning(cap)).toBeUndefined();
});
});
/**
* R9, the half a lock does not fix: serializing is not ordering.
*
* Both syncs run EXTRACTION outside the lock and only the persist section
* inside it, so a total-failure sync that queues behind a healthy one arrives at
* the critical section holding a snapshot of a group it read minutes ago. The
* preserve path then re-reads `contracts.json` as `prior` — and the file it
* finds is the winner's, written while this run waited — and stamps its own
* all-unreadable lists over it. That is not a rare interleave: it is what
* happens every time the total-failure sync loses the race, and it downgrades a
* registry that describes repos that were readable seconds earlier.
*
* The guard is a compare-and-swap on the prior file's own identity: stat it
* BEFORE acquiring, re-stat AFTER, and skip the diagnostic refresh when the two
* differ. Keyed on the file, not on `generatedAt`: that field is stamped when
* the registry object is built (before the lock), so a winner that waited writes
* one OLDER than the loser's start, and the preserve path carries it forward
* verbatim by design — after any preserve sync it does not date the write at
* all. File identity also needs no cross-process clock agreement and has no
* undefined case for an absent or unparseable timestamp.
*/
describe('a total-failure sync that reaches the group lock second', () => {
let groupDir: string;
let contractsPath: string;
let dbPath: string;
let metaPath: string;
/** What the sync that won the lock wrote while this one was still waiting. */
const WINNER_REGISTRY = {
version: 1,
generatedAt: '2026-02-02T00:00:00.000Z',
repoSnapshots: {},
missingRepos: [],
unreadableRepos: [],
contracts: [{ contractId: 'http::GET::/api/users' }, { contractId: 'http::POST::/api/users' }],
crossLinks: [{ contractId: 'http::GET::/api/users' }],
};
beforeEach(() => {
initLbugMock.mockReset();
readRegistryStrictMock.mockReset();
readRegistryStrictMock.mockResolvedValue(REGISTRY);
whileWaitingForTheGroupLock = null;
groupDir = fs.mkdtempSync(path.join(os.tmpdir(), 'gitnexus-sync-second-'));
contractsPath = path.join(groupDir, 'contracts.json');
dbPath = path.join(groupDir, 'bridge.lbug');
metaPath = path.join(groupDir, 'meta.json');
});
afterEach(async () => {
whileWaitingForTheGroupLock = null;
await closeAllCachedBridges();
fs.rmSync(groupDir, { recursive: true, force: true });
});
const runTotalFailureSync = () => {
initLbugMock.mockRejectedValue(new Error(LBUG_VERSION_ERROR));
return syncGroup(makeConfig({ 'app/backend': 'backend-repo' }), { groupDir });
};
const seedPriorRegistry = (): void =>
fs.writeFileSync(contractsPath, JSON.stringify(PRIOR_REGISTRY));
/** The winner's write, landing while this sync waits on the lock. */
const winnerWritesTheRegistry = async (): Promise<void> => {
fs.writeFileSync(contractsPath, JSON.stringify(WINNER_REGISTRY));
};
const readOnDisk = (): Record<string, unknown> =>
JSON.parse(fs.readFileSync(contractsPath, 'utf8')) as Record<string, unknown>;
it('leaves the registry the winning sync wrote exactly as it found it, and reports superseded', async () => {
seedPriorRegistry();
whileWaitingForTheGroupLock = winnerWritesTheRegistry;
const result = await runTotalFailureSync();
// Byte-identical to what the winner wrote. NOT the winner's contracts with
// this run's all-unreadable list stamped over them, which is what re-reading
// `prior` inside the lock produces — a registry that says every repo in the
// group is unreadable, written on top of a sync that had just read them.
expect(fs.readFileSync(contractsPath, 'utf8')).toBe(JSON.stringify(WINNER_REGISTRY));
expect(readOnDisk().unreadableRepos).toEqual([]);
// The existing outcome, not a new one: nothing was written and a prior
// registry was kept, which is exactly what `preserved` already means. A new
// value would fall through `cli/group.ts`'s outcome chain, which has no
// fallback branch, and falsify the guard asserting the sync tool's
// description names every reachable outcome.
expect(result.registryOutcome).toBe('superseded');
// ...and the caller still learns what THIS run could not read.
expect(result.unreadableRepos).toEqual(['app/backend']);
});
it('treats a registry that was absent before the lock and present after as changed', async () => {
// No prior file at all when this sync stat'd: on its own reading it was
// heading for `no-prior-registry` (write nothing), and then found a registry
// to "refresh" — one belonging to a sync it never overlapped in extraction.
whileWaitingForTheGroupLock = winnerWritesTheRegistry;
const result = await runTotalFailureSync();
expect(fs.readFileSync(contractsPath, 'utf8')).toBe(JSON.stringify(WINNER_REGISTRY));
expect(readOnDisk().unreadableRepos).toEqual([]);
expect(result.registryOutcome).toBe('superseded');
});
it('does not stamp this run into the bridge metadata beside the registry it skipped', async () => {
// `meta.json` is where `runGroupImpact` reads completeness from, so writing
// this run's lists there is the same downgrade one file over: it would
// report repos as unaccounted for that the winning sync had just accounted
// for. The refresh describes THIS run, and on this path this run is the
// stale one — and `refreshPreservedBridgeMeta` moves meta.json's mtime and
// can mark a pair `provenanceUnknown`, so it can only degrade a pair the
// winner left consistent. Nothing is written, which is what makes
// `preserved` an honest answer here.
fs.writeFileSync(dbPath, 'the winning sync database');
const dbStat = fs.statSync(dbPath);
await writeBridgeMeta(groupDir, {
version: BRIDGE_SCHEMA_VERSION,
generatedAt: '2026-02-02T00:00:00.000Z',
bridgeSize: dbStat.size,
bridgeMtimeMs: dbStat.mtimeMs,
missingRepos: [],
unreadableRepos: [],
});
const metaBefore = await snapshotFile(metaPath);
seedPriorRegistry();
whileWaitingForTheGroupLock = winnerWritesTheRegistry;
await runTotalFailureSync();
const metaAfter = await snapshotFile(metaPath);
expect(metaAfter.text).toBe(metaBefore.text);
expect(metaAfter.mtimeMs).toBe(metaBefore.mtimeMs);
const meta = await readBridgeMeta(groupDir);
expect(meta.unreadableRepos).toEqual([]);
expect(meta.provenanceUnknown).toBeUndefined();
});
it('refreshes as usual when it is the sync that got to the lock first', async () => {
// The same interleaving in the other order: the other sync is still
// extracting and has written nothing, so this run's stats match across the
// acquisition and the diagnostic refresh — the entire point of the preserve
// path — must still happen. A guard that fired on "a second sync exists"
// rather than on "the file changed" would freeze the diagnostics of every
// contended group.
seedPriorRegistry();
let otherSyncStillExtracting = false;
whileWaitingForTheGroupLock = async () => {
otherSyncStillExtracting = true;
};
const result = await runTotalFailureSync();
expect(otherSyncStillExtracting).toBe(true);
expect(result.registryOutcome).toBe('preserved');
const onDisk = readOnDisk();
expect(onDisk.contracts).toEqual(PRIOR_REGISTRY.contracts);
expect(onDisk.unreadableRepos).toEqual(['app/backend']);
});
it('control: an uncontended sync sees identical stats and refreshes as usual', async () => {
// Nothing armed at all, so the compare-and-swap runs over a file no one
// else touched. Without this, every assertion above could be satisfied by a
// guard that skipped the refresh on every run.
seedPriorRegistry();
const result = await runTotalFailureSync();
expect(result.registryOutcome).toBe('preserved');
const onDisk = readOnDisk();
expect(onDisk.contracts).toEqual(PRIOR_REGISTRY.contracts);
expect(onDisk.unreadableRepos).toEqual(['app/backend']);
});
});