gemvault 0.2.5 → 0.2.7

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 4447e59a767dbc08bd6c0964964fefaf00bb1f2768421f7ce1fc6247f9e8f2c4
-  data.tar.gz: b017dc605efee9f1a576b1fc362b2cf51ebab25e48b424c2be7e50d9cb5f1e3f
+  metadata.gz: d8478b689eb6f6b68e0c18872f4b2ca47034b1bd93ef9d0d16ecb92e8666de85
+  data.tar.gz: cb7f53a602a6b55a1a0593eda146635197e79dadb7366ca930a1e67b5b40d80d
 SHA512:
-  metadata.gz: 5c993d8b4fd00d8c35ed6de9645653400882565860f44449e7adbbcd53730ad7ca161e4cae10e7e817f512c3b63e2101e2ceb58496ebebe97eadd32eceefc46a
-  data.tar.gz: 39bfbb4959725d6ad92401dfd3d6841ea72c94021031bdf7680bdde9f2563bd721b51329db7cd76eaf0ef01a32dbfb0a9a788e7795befc50cdc6396f8c2db595
+  metadata.gz: afa47c5b978c008d5fe46fb7399a3d1625505c8ad502d7e86e54c2f59a74b20b77077db8a31e60c70e294beeb54d51e8b808e005196c0b42f5e7e5cba0237574
+  data.tar.gz: b9a93c14eaeb496f1a46e78494b6129faeb8501333f678a85e8d1d07afb1a14465b32f7cc941eed294eae0bb7c319dcbbd5a0264305843394a4f1a1113a62530

data/CHANGELOG.md

@@ -9,15 +9,17 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Added
 - Tarball vault format ("Tarvault"): new vaults are portable tarballs with a
-  `manifest.json` index and per-gem SHA256 integrity, with no sqlite3 dependency
-  on the read/write path (works on JRuby). The original SQLite format
-  ("Dbvault") is still read transparently.
+  plain-text `manifest` index and per-gem SHA256 integrity, with no sqlite3
+  dependency on the read/write path (works on JRuby). The original SQLite
+  format ("Dbvault") is still read transparently.
 - Vaults carry an explicit on-disk **format version**, decoupled from the gem
   version and validated on open; gemvault refuses a vault written by a newer
   gemvault instead of misreading it.
 - `gemvault upgrade` migrates a vault to the current format (e.g. SQLite → tar),
-  preserving every gem and timestamp, writing a `.bak` backup by default, with
-  `--dry-run` and `--no-backup` flags. It is a no-op on an already-current vault.
+  preserving every gem, writing a `.bak` backup by default, with `--dry-run` and
+  `--no-backup` flags. Timestamps survive a v1 upgrade; a v2 vault's are
+  restamped, its stored times living in an index this gemvault no longer reads
+  (see Changed). It is a no-op on an already-current vault.
 
 - All CLI commands accept `vault://` and `file://` locators wherever they take
   a vault path, e.g. `gemvault list vault:///path/to/myvault.gemv`; resolution
@@ -33,6 +35,29 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   plugin.)` — Bundler reinstalls the gem correctly but validates the ghost's
   dead path — and nothing project-local can recover, because the wreck lives
   in the ambient gem home (issue #23).
+- `gemvault doctor` now works in a project whose Gemfile is inline
+  (`bundler/inline`). Such a script keeps its plugin index in
+  `<project>/.bundle/plugin`, a root bundler only consults mid-script, so
+  doctor's uninstall silently repaired nothing and the `bundle install` that
+  followed dumped bundler's entire usage screen. Doctor now reaches the
+  project's index the way `bundler/inline` does and, with no Gemfile to
+  reinstall from, says so and exits 0 — the inline gemfile reinstalls the
+  plugin the next time the script runs (issue #14). Run outside any project,
+  doctor no longer claims to have cleared a project index it never touched.
+- `gemvault doctor` no longer strands a machine without the plugin. Its
+  closing `bundle install` does more than reinstall the plugin, and when that
+  extra work failed (a Ruby version pin, an unresolvable gem) the already-run
+  uninstall had cleared the plugin index for nothing — strictly worse than
+  the wreck doctor was asked to repair. The index is now snapshotted before
+  the uninstall and restored when the reinstall never happened, `bundle
+  install` runs as a child rather than replacing the process, and every
+  failure is one line on stderr and exit 1 instead of a backtrace
+  (issues #27, #24).
+- The shim no longer spams `already initialized constant` warnings when
+  bundler evaluates two installed copies of it in one process — an upgrade
+  resolving a newer bundler-source-vault while the plugin index still names
+  the old one. The first copy wins, matching the guard plugins.rb already
+  applies to the vault source class (issue #26).
 - `bundle plugin install bundler-source-vault` no longer dies with
   `LoadError: cannot load such file -- bundler/plugin/vault_source`. The shim's
   `plugins.rb` now derives the gem root from its own installed location (local
@@ -60,17 +85,20 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   evaluation, so `Gemvault::GemEntry` can no longer be defined twice from two
   different gem roots (issue #13).
 - `gemvault new` no longer raises `cannot load such file -- json` on a stock
-  distro ruby. json backs the tarball vault's manifest, so every current-format
-  vault needs it; it is a default gem upstream but a separate package on
-  distros, where `dnf install ruby` leaves it absent. It is now a declared
-  runtime dependency.
+  distro ruby, where json is a default gem upstream but a separate package that
+  `dnf install ruby` leaves absent. json backed the tarball vault's manifest
+  when this was first fixed by declaring it a runtime dependency; the manifest
+  is now plain text and gemvault never loads json at runtime, so the failure is
+  retired outright rather than papered over (see Changed, issue #25).
 - Reading a vault through the Bundler source no longer raises `cannot load such
   file -- json` either. Loading gemvault off `$LOAD_PATH` skips activation, and
-  therefore skips its dependencies, so the declared dependency alone did not
-  reach the plugin path. The shim now resolves gemvault's declared runtime
-  dependencies the same way it resolves gemvault and puts their require paths —
-  extension directories included — on `$LOAD_PATH`. A dependency it cannot find
-  is skipped rather than fatal, which is what activation could not do.
+  therefore skips its dependencies, so a declared dependency (json, at the time)
+  never reached the plugin path. The shim now resolves gemvault's declared
+  runtime dependencies the same way it resolves gemvault and puts their require
+  paths — extension directories included — on `$LOAD_PATH`; a dependency it
+  cannot find is skipped rather than fatal, which is what activation could not
+  do. The manifest being plain text, nothing on this path requires json at all
+  (see Changed, issue #25).
 - `bundle install` no longer fails with `Could not find 'command_kit' (~> 0.6)`
   when gemvault is installed into the plugin root without its dependencies.
   Loading the vault source no longer activates the gemvault gem, which would
@@ -78,6 +106,22 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   gemvault through `require_relative` alone (issue #13).
 
 ### Changed
+- The manifest is now line-oriented text rather than JSON (vault format 3).
+  It was never document-shaped: a header plus one whitespace-separated line
+  per gem — name, version, platform, stored-at, SHA256, encrypted — with no
+  nesting and no free text, so `tar -xOf myvault.gemv manifest` gives you
+  something `grep` and `awk` read directly. Because every field comes from an
+  alphabet without whitespace, reading needs no parser beyond `split` plus
+  per-field validation: no recursion to exhaust the stack, no escape grammar,
+  and no library to load — which is what stops gemvault from ever activating
+  a json gem a project had locked (issue #25). Times are stored as
+  `2026-08-12T18:23:32Z`; a legacy vault's `2026-08-12 18:23:32` is converted
+  on upgrade. A format-2 vault (`manifest.json`) stays readable: it opens
+  read-only through the same path a legacy SQLite vault does, and
+  `gemvault upgrade` migrates it. That backend never parses the old manifest —
+  it derives the index from the stored gems, each of which carries its own
+  gemspec — so migrated gems keep their identity but are restamped, the old
+  index's times being unrecoverable.
 - `sqlite3` is no longer a runtime dependency. Gemvault runs dependency-free on
   the tarball path (including JRuby); `sqlite3` is loaded lazily only to read a
   legacy SQLite vault, with a clear error if it is not installed.
@@ -89,10 +133,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   `spec:integration` rake task exists alongside a non-integration `spec:core`, the
   unit job no longer needs podman, and the integration job installs podman
   when the runner image lacks it.
-- Reading a vault's `manifest.json` is now strict: an entry missing any required
-  field (`name`, `version`, `platform`, `created_at`, `sha256`, `encrypted`)
-  raises instead of silently loading `nil` fields, so a truncated or hand-edited
-  manifest fails fast rather than yielding a subtly broken vault.
+- Reading a vault's manifest is now strict: every field is validated against
+  its own alphabet, so a truncated or hand-edited manifest fails fast rather
+  than yielding a subtly broken vault.
 
 ### Deprecated
 - The SQLite vault format is deprecated and now **read-only**: existing SQLite

data/CLAUDE.md

@@ -27,7 +27,7 @@ Do NOT modify `.rubocop.yml` or use inline `# rubocop:disable` tags without expl
 
 ## Project Overview
 
-Multi-gem portable archives. A single `.gemv` file is a tarball holding multiple `.gem` files plus a `manifest.json` index; legacy SQLite vaults are read-only.
+Multi-gem portable archives. A single `.gemv` file is a tarball holding multiple `.gem` files plus a line-oriented `manifest` index; legacy SQLite vaults are read-only.
 
 Two gems, one repo:
 
@@ -58,7 +58,10 @@ gem install --source file:///path/to/myvault.gemv foo
 ## Architecture
 
 - `gemvault.gemspec` — main gem spec (name: `gemvault`)
-- `lib/gemvault/vault.rb` — Vault facade choosing a backend by file format (Tarvault current, legacy Dbvault read-only)
+- `lib/gemvault/vault.rb` — Vault facade choosing a backend by file format (Tarvault current; Dbvault and LegacyTarvault read-only)
+- `lib/gemvault/legacy_tarvault.rb` — read-only backend for a format-2 (manifest.json) vault; derives its index from the stored gems instead of parsing that manifest, so `gemvault upgrade` migrates one through the ordinary pipeline
+- `lib/gemvault/manifest_text.rb` — the manifest's on-disk notation: a header plus one whitespace-separated line per gem, validated field by field on read
+- `lib/gemvault/timestamp.rb` — the space-free notation a vault records times in, and conversion of a legacy vault's times into it
 - `lib/gemvault/cli.rb` — CLI dispatcher (new/add/list/remove/extract)
 - `lib/gemvault/ghost_specification.rb` — installation records whose gem directory is gone; swept by `gemvault doctor` (issue #23)
 - `lib/bundler/plugin/vault_source.rb` — Bundler `Plugin::API::Source` implementation
@@ -165,6 +168,6 @@ container.
 
 - `bundler` — NOT a dependency; the plugin always runs inside an existing Bundler process, and declaring it breaks gem activation under `bundle exec`'s restricted GEM_PATH
 - `command_kit` (~> 0.6) — runtime (CLI)
-- `json` — NOT a dependency, though it backs the tarball vault's manifest. A default gem upstream; distros that unbundle it (Fedora's `rubygem-json`) still install it alongside ruby itself, and it stays requireable even under `bundle exec`'s restricted view. Declaring it would compile a native extension on every `gem install gemvault` for no gain.
+- `json` — NOT a dependency and never loaded at runtime. The manifest is a table, not a document, so `Gemvault::ManifestText` reads and writes it directly; nothing in `lib/` may `require "json"`. On rubies where require resolves through gem activation, a require inside a Bundler process activates the newest installed json and a project locking an older one dies in `check_for_activated_spec!` (issue #25).
 - `sqlite3` (~> 2.0) — NOT a runtime dependency; loaded lazily only to read a legacy SQLite (Dbvault) vault. Declared in the Gemfile for development/test.
 - `minitest`, `rspec`, `rake` — development

data/README.md

@@ -48,23 +48,33 @@ gemvault upgrade myvault.gemv                 # migrate to the current format
 
 ## Vault format versioning
 
-Every vault records an on-disk **format version** — `1` for the original SQLite format, `2` for the current tarball format. This version lives inside the file and is **independent of the gemvault gem version**: it changes only when the storage layout changes, so upgrading the gem never invalidates your vaults.
+Every vault records an on-disk **format version** — `1` for the original SQLite format, `2` for a tarball with a JSON manifest, `3` for the current tarball with a plain-text manifest. This version lives inside the file and is **independent of the gemvault gem version**: it changes only when the storage layout changes, so upgrading the gem never invalidates your vaults.
 
 gemvault reads any format up to the one it understands and **refuses a vault written by a newer gemvault** with a clear message (rather than silently misreading it).
 
-The SQLite format (`1`) is **deprecated and read-only**: you can still read and migrate an existing SQLite vault, but `add`/`remove` are refused and print `gemvault upgrade`. Opening one shows a one-time deprecation notice (silence it with `GEMVAULT_SILENCE_DEPRECATIONS=1`). SQLite support will be removed in a future release (0.3–0.5). To migrate a vault to the current format:
+Formats `1` (SQLite) and `2` (JSON manifest) are **deprecated and read-only**: you can still list, extract from, and migrate an existing one, but `add`/`remove` are refused and print `gemvault upgrade`. Opening one shows a one-time deprecation notice (silence it with `GEMVAULT_SILENCE_DEPRECATIONS=1`). SQLite support will be removed in a future release (0.3–0.5). To migrate a vault to the current format:
 
 ```bash
-gemvault upgrade myvault.gemv              # e.g. SQLite (v1) -> tarball (v2)
+gemvault upgrade myvault.gemv              # e.g. SQLite (v1) or JSON manifest (v2) -> current (v3)
 gemvault upgrade myvault.gemv --dry-run    # show the plan, change nothing
 gemvault upgrade myvault.gemv --no-backup  # skip the default myvault.gemv.bak copy
 ```
 
-`upgrade` preserves every gem and its timestamp, writes `myvault.gemv.bak` by default, and is a no-op on an already-current vault.
+`upgrade` preserves every gem, writes `myvault.gemv.bak` by default, and is a no-op on an already-current vault. Timestamps survive a v1 upgrade; a v2 vault's are restamped, because its stored times live in the JSON index this gemvault deliberately no longer reads — the gems themselves are read straight out of the tarball.
 
 ## How It Works
 
-The gemv file is a tarball containing your .gem files and a json manifest. It has no dependencies other than the tar utilities that rubygems provides.
+The gemv file is a tarball containing your .gem files and a plain-text manifest. It has no dependencies other than the tar utilities that rubygems provides.
+
+```console
+$ tar -xOf myvault.gemv manifest
+gemvault 3
+created 2026-08-12T18:23:32Z
+
+rails 7.1.3 ruby 2026-08-12T18:23:32Z 9f2c...  0
+```
+
+One header, then one line per gem: name, version, platform, when it was stored, its SHA256, and whether it is encrypted. Every field is drawn from an alphabet without whitespace, so reading the index needs no parser beyond `split` — and `grep`, `awk` and `cut` work on it directly.
 
 When Bundler sees `type: :vault` in your Gemfile, it auto-installs the `bundler-source-vault` plugin from rubygems.org. The plugin implements the `Bundler::Plugin::API::Source` interface — it reads gemspecs from the vault, participates in dependency resolution, then extracts and installs gems from the vault's blob storage.
 
@@ -98,7 +108,11 @@ To recover, update the Gemfile to point at the new path and run:
 gemvault doctor
 ```
 
-`doctor` removes any ghost installation records, clears the broken entry from bundler's plugin index (`bundle plugin uninstall bundler-source-vault`) and then re-runs `bundle install`, which reinstalls the plugin against whatever the current Gemfile declares. Run it from your project directory. If a ghost record sits in a root-owned gem home, doctor says so on one line — re-run it with permissions for that gem home (e.g. `sudo gemvault doctor`).
+`doctor` removes any ghost installation records, clears the broken entry from bundler's plugin index (`bundle plugin uninstall bundler-source-vault`) and then, when a Gemfile exists, re-runs `bundle install`, which reinstalls the plugin against whatever the current Gemfile declares. Run it from your project directory. If a ghost record sits in a root-owned gem home, doctor says so on one line — re-run it with permissions for that gem home (e.g. `sudo gemvault doctor`).
+
+A project whose Gemfile is inline (`require "bundler/inline"`) works too. Such a script keeps its plugin index in `<project>/.bundle/plugin`, a root bundler only consults while the script runs; doctor reaches it the same way the script did. With no Gemfile on disk there is nothing to reinstall from, so doctor clears the entry, says so, and exits 0 — the inline gemfile reinstalls the plugin the next time the script runs. Run outside any project, doctor works against bundler's global index and points you back at the project directory for the reinstall.
+
+The repair is transactional. `bundle install` does more than reinstall the plugin, and that extra work can fail on its own — a Ruby version pin, an unresolvable gem. When it does, doctor says so in one line and exits 1; and if the failure struck before the plugin was reinstalled, doctor puts the plugin index back the way it found it. A failed run never leaves the machine with less than it started with — fix the install error and re-run.
 
 The published `bundler-source-vault` gem installed from rubygems.org is immune to this: it lives in a bundler-managed directory that does not move.
 

data/issues.rec

@@ -750,7 +750,42 @@ Id: 14
 Updated: Wed, 29 Jul 2026 16:41:11 -0400
 Name: gemvault doctor fails when bundler/inline is used
 Description: Loudly fails with 2 errors, one of which is "can't find gemfile"
-Status: open
++
++ RESOLUTION: both errors reproduced in podman, and doctor turned out to be
++ broken twice over rather than once.
++
++ (1) "Plugin bundler-source-vault is not installed". bundler/inline sets
++ BUNDLE_GEMFILE to a bare "Gemfile" for the life of the script (bundler
++ inline.rb:53), so Bundler.root is the script's working directory and the plugin
++ index is written to <project>/.bundle/plugin. A later `gemvault doctor` sets no
++ such variable and finds no Gemfile on disk, so Bundler::Plugin.root --
++ local_root only when SharedHelpers.in_bundle?, global_root otherwise
++ (plugin.rb:162) -- falls back to ~/.bundle/plugin. The uninstall therefore
++ looked in the wrong root and repaired nothing, silently.
++
++ (2) "Could not locate Gemfile". doctor then exec'd `bundle install`, which with
++ no Gemfile prints its entire usage screen and exits 10 -- reading as gemvault
++ itself failing, after the repair it was asked for had already not happened.
++
++ doctor now runs the uninstall with BUNDLE_GEMFILE="Gemfile" when the project
++ owns a plugin root Bundler would ignore, which is bundler/inline's own trick and
++ needs no file to exist; verified against the real thing (plain uninstall says
++ "not installed", the same command with BUNDLE_GEMFILE set says "Uninstalled
++ plugin bundler-source-vault" and empties the index). When no Gemfile exists it
++ skips the reinstall and says so, exiting 0, because clearing the entry is the
++ repair and only the reinstall is unavailable -- an inline gemfile reinstalls the
++ plugin the next time the script runs.
++
++ Gemvault::BundlerGemfile mirrors SharedHelpers#find_gemfile and
++ Gemvault::BundlerPluginRoot mirrors Plugin.root, both reimplemented rather than
++ delegated because bundler is deliberately not a dependency and doctor runs
++ outside any Bundler process. Replicated first by
++ spec/integration/cli/commands/doctor_inline_spec.rb -- all 8 examples failed
++ against the old code -- with unit cover in spec/gemvault/bundler_gemfile_spec.rb,
++ spec/gemvault/bundler_plugin_root_spec.rb and the extended doctor_spec.rb. The
++ inline support now runs its script from the project directory, as a real user
++ does; that is what puts the plugin root where the report describes.
+Status: closed
 
 Id: 15
 Updated: Wed, 29 Jul 2026 17:39:23 -0400
@@ -783,7 +818,11 @@ Id: 16
 Updated: Wed, 29 Jul 2026 18:25:48 -0400
 Name: Add jruby-ci workflow
 Description: It should be already set up on the jruby-support branch. It just needs to be picked from it. DO NOT use the other code in that - it is very outdated
-Status: open
++
++ RESOLUTION: shipped in commit 635ba41 ("ci: add JRuby test job") -- the jruby
++ job in .github/workflows/ci.yml runs the minitest suite on jruby-10.1.0.0 and
++ is green on CI.
+Status: closed
 
 Id: 17
 Updated: Thu, 30 Jul 2026 00:07:42 +0000
@@ -972,7 +1011,15 @@ Description: [dev@rstore]/workspace% bundle install
 + 	from /usr/local/bin/bundle:25:in '<main>'
 + 
 + Though I will add that gemvault doctor followed by bundle install fixed the issue
-Status: open
++
++ RESOLUTION: the broken-plugin-path wreck, recovered exactly as reported --
++ gemvault doctor then bundle install. The plugin index entry pointed into a
++ reinstalled rbenv ruby's gem home; bundler does not revalidate stored plugin
++ paths, skips loading the plugin, and crashes in SourceList#add_plugin_source,
++ upstream behavior README documents under "A broken plugin path". doctor is
++ the repair. Hinting at doctor from the failure site was considered and
++ declined: the crash happens in bundler frames before any gemvault code loads.
+Status: closed
 
 Id: 21
 Updated: Fri, 31 Jul 2026 13:54:09 -0400
@@ -1011,12 +1058,27 @@ Description: bundler-cache: true on the ruby/setup-ruby action will not work cor
 +         run: | # confine gems to vendor/bundle so the cache never shadows vendor/vendored.gemv
 +           bundle config set --local path vendor/bundle
 +           bundle install --jobs 4 --retry 3
+Status: open
+
+Id: 26
 Updated: Mon, 10 Aug 2026 10:14:51 -0400
 Name: Gemvault spams warnings on bundle install
 Description: /workspace/.bundle/plugin/gems/bundler-source-vault-0.2.2/gemvault_load_path.rb:31: warning: already initialized constant BundlerSourceVault::GemvaultLoadPath::GEM
 + /workspace/.bundle/plugin/gems/bundler-source-vault-0.2.2/gemvault_load_path.rb:32: warning: already initialized constant BundlerSourceVault::GemvaultLoadPath::SHIM
 + /workspace/.bundle/plugin/gems/bundler-source-vault-0.2.2/gemvault_load_path.rb:33: warning: already initialized constant BundlerSourceVault::GemvaultLoadPath::VAULT_SOURCE
-Status: open
++
++ RESOLUTION: bundler can evaluate two installed copies of the shim in one
++ process -- an upgrade resolving a newer bundler-source-vault while the index
++ still names the old one, the dual-version plugin root the failure report
++ also recorded as issue #29 -- and require_relative cannot deduplicate
++ across paths, so the second copy reopened GemvaultLoadPath and warned on
++ every constant. gemvault_load_path.rb now returns before redefining
++ anything when the module is already loaded, first copy winning as
++ plugins.rb already arranges for Bundler::Plugin::VaultSource. Replicated by
++ spec/shim_reload_spec.rb (two copies loaded in one process, red against the
++ old shim), with the plain-install path guarded in
++ spec/integration/bundle_install_spec.rb.
+Status: closed
 
 Id: 23
 Updated: Mon, 10 Aug 2026 17:40:28 -0400
@@ -1086,4 +1148,133 @@ Id: 24
 Updated: Mon, 10 Aug 2026 23:16:35 +0000
 Name: doctor prints a backtrace when the plugin uninstall step fails
 Description: gemvault doctor's `bundle plugin uninstall` step runs with exception: true; a nonzero exit raises RuntimeError and a missing bundle raises Errno::ENOENT, and both escape Command#run to command_kit's ExceptionHandler, which prints error.full_message -- a full backtrace -- violating the one-line-and-exit-1 convention issue #15 established. Adjacent to issue #14 (doctor failing under bundler/inline). The ghost-specification sweep added for issue #23 reports its own failures as one line; the uninstall step should match.
++
++ RESOLUTION: fixed alongside issue #27's transactional rework. The uninstall
++ step no longer runs with exception: true; a failing or missing bundle is one
++ line on stderr ("doctor: bundle plugin uninstall bundler-source-vault
++ failed") and exit 1, matching the convention issues #15 and #23 established,
++ and the snapshotted index is left untouched.
+Status: closed
+
+Id: 25
+Updated: Tue, 11 Aug 2026 20:05:27 -0400
+Name: Project with Gemfile + locked json version + gemvault throws error
+Description: Project with Gemfile + locked json version + gemvault throws "bundler: failed to load command: rails (/private/tmp/local/flipmine/flipmine/vendor/ruby/4.0.0/bin/rails)
++ /Users/davidgillis/.rbenv/versions/4.0.1/lib/ruby/gems/4.0.0/gems/bundler-4.0.18/lib/bundler/runtime.rb:328:in 'Bundler::Runtime#check_for_activated_spec!': You have already activated json 2.21.2, but your Gemfile requires json 2.19.7. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)"
++ 
++ I believe this error to be coming from gemvault's dependency on JSON. It is clear that dependencies are cursed in this project, whether its the added load time for reinstalling them on every `bundle install`, or errors like this one. Rather than rely on JSON, I think it would be better to just marshal our own manifest, or use some other serialization tool if any that rubygems already provides.
++
++ RESOLUTION: gemvault no longer loads json, and the manifest is no longer a
++ JSON document. Whether gemvault's require was the activator on the reported
++ machine cannot be settled from here -- on the Fedora reproduction stack
++ require resolves json from the stdlib path with no activation at all, and
++ bundler loads json itself before the vault source runs -- but on rbenv-style
++ stacks require does activate, gemvault held a live require in its
++ vault-read path, and it can no longer be the component that detonates
++ check_for_activated_spec!.
++
++ Marshal was considered as the reporter suggested and rejected: a .gemv is a
++ file that arrives from elsewhere, the manifest is the root of trust (the
++ SHA256 digests live inside it, so nothing verifies it first), and
++ Marshal.load runs attacker-chosen code during load itself -- demonstrated
++ here, a hash key's #hash fires inside load before the caller touches the
++ result. `gemvault list` on an untrusted vault would become arbitrary code
++ execution, and Marshal's versioned wire format would break the portability
++ a .gemv exists for.
++
++ What replaced JSON is neither: the manifest was never document-shaped. It is
++ a table -- a header plus fixed-arity records of scalars, no nesting, no free
++ text -- and every field is drawn from an alphabet without whitespace once
++ times are canonicalized (Gemvault::Timestamp; rubygems itself validates gem
++ names against /\A[a-zA-Z0-9._-]+\z/). Gemvault::ManifestText writes and
++ reads it as lines. There is no recursion to exhaust the stack, no escape
++ grammar, no backtracking, and no library to load -- the same reasoning that
++ keeps BundlerPluginIndex from requiring yaml. Reading validates every field
++ and rejects everything else, because the file comes from elsewhere; writing
++ trusts the value objects this library constructed. Precedent is rubygems'
++ own compact index and Gemfile.lock, both line-oriented text.
++
++ Format version 3; vaults are inspectable with `tar -xOf v.gemv manifest`.
++
++ An existing format-2 vault keeps working. Gemvault::LegacyTarvault opens one
++ read-only, exactly as Dbvault does for SQLite, so `gemvault upgrade` migrates
++ it through the ordinary pipeline rather than leaving its gems stranded behind
++ an error. That backend never parses manifest.json: it derives the index from
++ the payload, since every stored .gem carries the gemspec the manifest's
++ identity fields came from -- which keeps the old notation from re-entering
++ the codebase and makes the reader indifferent to a damaged manifest. Two
++ things the old index held are lost with it: each gem's stored time (entries
++ are restamped on open, and the deprecation notice says so) and the per-gem
++ digests (the new vault records fresh digests of exactly the bytes it copied).
++ Covered end to end by spec/integration/cli/commands/legacy_tarvault_spec.rb
++ against a committed format-2 fixture: list, extract, refused add, upgrade,
++ and writing to the upgraded vault.
++
++ Settled after all: the Fedora image reproduces the rbenv-style stack once
++ the unbundled stdlib json is cleared away -- require then resolves through
++ gem activation, exactly the reported semantics.
++ spec/integration/locked_json_spec.rb runs the reporter's flow (a project
++ locking an older json than the machine's newest, gemvault ambient, bundle
++ exec through the vault source) and fails against a gemvault that requires
++ json on either the CLI path or the plugin path, the latter dying with the
++ reported check_for_activated_spec! error verbatim.
+Status: closed
+
+Id: 27
+Updated: Wed, 12 Aug 2026 16:05:55 +0000
+Name: gemvault doctor can leave the machine with no plugin at all
+Description: Reported from a container where bundle install could not succeed
++ (ruby version pin mismatch): doctor removed ghost records, uninstalled the
++ plugin, emptied .bundle/plugin/index, then exec'd bundle install -- which
++ failed, leaving no plugin installed. Strictly worse than the broken-path
++ state doctor was invoked to repair, and recoverable only by knowing to run
++ `bundle plugin install bundler-source-vault` by hand. doctor repairs by
++ mutation with no dry-run, no report of findings before acting, and no
++ rollback when the reinstall it hands off to fails. Suggested in the report:
++ report-then-fix (--dry-run, or report by default and repair under --fix);
++ reinstall the plugin directly with `bundle plugin install` and verify the
++ index rather than exec'ing into `bundle install`, so a failed dependency
++ install cannot take the plugin down with it; or restore the previous index
++ when the step after the uninstall fails.
++
++ RESOLUTION: the uninstall-reinstall pair is now transactional. doctor
++ snapshots the plugin index bundler will consult (Gemvault::BundlerPluginIndex
++ over BundlerPluginRoot#consulted) before clearing it, runs `bundle install`
++ as a child instead of exec'ing into it, and on failure checks whether the
++ plugin came back: reinstalled means the repair stands and the one-line error
++ says only the bundle is unfinished; not reinstalled means the snapshot is
++ restored, so the machine is left as found and re-running doctor once the
++ install error is fixed recovers fully. Replicated first by
++ spec/integration/cli/commands/doctor_reinstall_failure_spec.rb -- doctor run
++ against a Gemfile still naming a renamed plugin path, an un-installable
++ bundle in the reporter's shape -- which fails against the old code and
++ proves the restored index heals on the next run. Unit cover in
++ spec/gemvault/bundler_plugin_index_spec.rb and the reworked doctor_spec.rb.
+Status: closed
+
+Id: 28
+Updated: Wed, 12 Aug 2026 16:05:55 +0000
+Name: plugins.rb dies with a bare LoadError when gemvault is installed nowhere
+Description: A plugin root holding only the shim -- the normal state wherever
++ `gem install gemvault` has run, since Bundler skips installing a plugin
++ dependency already present -- stops loading when the tree lands on a machine
++ with no gemvault in any gem root: GemvaultLoadPath.entries returns [] and
++ `require "bundler/plugin/vault_source"` raises a bare LoadError with no hint.
++ Observed after a macOS working tree was copied into a Linux container (the
++ shim alone in .bundle/plugin, gemvault absent from every gem root on the
++ box); also reachable by `gem uninstall gemvault` on a single machine. The
++ ambient-root search cannot cover gemvault being truly absent. Suggested:
++ fail with an explicit "gemvault not found in any gem root" message naming
++ the remedy (gem install gemvault, or bundle plugin uninstall + install to
++ get a self-contained root), or vendor gemvault into the shim.
+Status: open
+
+Id: 29
+Updated: Wed, 12 Aug 2026 16:05:55 +0000
+Name: Stale plugin versions are never reaped from the plugin root
+Description: bundler-source-vault-0.2.4 survived in the plugin root's gems/,
++ specifications/ and cache/ across the 0.2.5 upgrade and an explicit `bundle
++ plugin uninstall`; only 0.2.5 was ever referenced by the index. Possibly
++ Bundler's doing rather than the plugin's, but doctor is well placed to sweep
++ plugin-root versions the index no longer references.
 Status: open

data/lib/gemvault/bundler_gemfile.rb

@@ -0,0 +1,63 @@
+require "pathname"
+
+module Gemvault
+  ##
+  # The Gemfile Bundler would load from a directory.
+  #
+  # Mirrors Bundler::SharedHelpers#find_gemfile: <tt>BUNDLE_GEMFILE</tt> wins
+  # when set and non-empty, otherwise the search walks up looking for
+  # <tt>gems.rb</tt> then <tt>Gemfile</tt> in each directory. Reimplemented
+  # rather than delegated because bundler is deliberately not a gemvault
+  # dependency (see gemvault.gemspec) and +gemvault doctor+ runs as a plain
+  # CLI, outside any Bundler process.
+  #
+  # One difference is deliberate. Bundler returns <tt>BUNDLE_GEMFILE</tt>
+  # whatever it points at, existing or not -- bundler/inline relies on that,
+  # setting it to a bare "Gemfile" purely to make Bundler treat the working
+  # directory as the app root. The question here is whether +bundle install+
+  # could work, so a value that does not name a file is ignored and the
+  # walk-up search decides instead.
+  class BundlerGemfile
+    # Checked in this order within each directory, as Bundler checks them.
+    NAMES = ["gems.rb", "Gemfile"].freeze
+
+    def initialize(dir: Dir.pwd, env: ENV)
+      @dir = Pathname(dir)
+      @env = env
+    end
+
+    # :call-seq:
+    #   path -> Pathname or nil
+    #
+    # The Gemfile Bundler would load, or +nil+ when there is none.
+    def path
+      return @path if defined?(@path)
+
+      @path = from_env || search_up
+    end
+
+    # Whether Bundler would find a Gemfile at all.
+    def exist?
+      !path.nil?
+    end
+
+    private
+
+    def from_env
+      given = @env["BUNDLE_GEMFILE"].to_s
+      return nil if given.empty?
+
+      candidate = Pathname(given).expand_path(@dir)
+      candidate.file? ? candidate : nil
+    end
+
+    def search_up
+      @dir.expand_path.ascend do |dir|
+        found = NAMES.map { |name| dir / name }.find(&:file?)
+        return found if found
+      end
+
+      nil
+    end
+  end
+end

data/lib/gemvault/bundler_plugin_index.rb

@@ -0,0 +1,58 @@
+require "pathname"
+
+module Gemvault
+  ##
+  # Bundler's plugin index file inside a plugin root.
+  #
+  # The uninstall step of +gemvault doctor+ clears entries from this file, and
+  # the reinstall that follows can fail for reasons unrelated to the plugin.
+  # Snapshot and restore make that pair transactional: a repair that cannot
+  # finish puts the index back instead of leaving the machine with no plugin
+  # registered at all (issue #27).
+  #
+  # The plugin_paths section is scanned textually rather than parsed as YAML:
+  # loading a YAML library into doctor's process invites the same
+  # stdlib-activation conflicts as issue #25, and bundler's own emitter writes
+  # one two-space-indented "name: path" line per plugin.
+  class BundlerPluginIndex
+    def initialize(root)
+      @root = Pathname(root)
+    end
+
+    def file
+      @root / "index"
+    end
+
+    # Whether plugin_paths currently lists +plugin+.
+    def registered?(plugin)
+      plugin_paths.any? { |line| line.match?(/\A\s{2}#{Regexp.escape(plugin)}:/) }
+    end
+
+    # :call-seq:
+    #   snapshot -> String or nil
+    #
+    # The index content as it stands, +nil+ when no index exists.
+    def snapshot
+      file.file? ? file.read : nil
+    end
+
+    # Puts the index back the way +snapshot+ recorded it; restoring +nil+
+    # removes an index that did not exist at snapshot time.
+    def restore(snapshot)
+      return file.write(snapshot) if snapshot
+
+      file.delete if file.exist?
+    end
+
+    private
+
+    def plugin_paths
+      return [] unless file.file?
+
+      file.readlines
+          .drop_while { |line| !line.start_with?("plugin_paths:") }
+          .drop(1)
+          .take_while { |line| line.start_with?(" ") }
+    end
+  end
+end

data/lib/gemvault/bundler_plugin_root.rb

@@ -0,0 +1,59 @@
+require "pathname"
+require_relative "bundler_gemfile"
+
+module Gemvault
+  ##
+  # Where Bundler keeps plugin data for a directory.
+  #
+  # Bundler::Plugin.root answers the project-local <tt>.bundle/plugin</tt> when
+  # <tt>SharedHelpers.in_bundle?</tt> holds, and the global
+  # <tt>~/.bundle/plugin</tt> when it does not. Since +in_bundle?+ is just
+  # "was a Gemfile found", a project can own a plugin root that Bundler
+  # declines to look in.
+  class BundlerPluginRoot
+    LOCAL_DIR = ".bundle/plugin".freeze
+
+    def initialize(dir: Dir.pwd, gemfile: BundlerGemfile.new(dir: dir), env: ENV)
+      @dir = Pathname(dir)
+      @gemfile = gemfile
+      @env = env
+    end
+
+    # The project's own plugin root, whether or not Bundler would consult it.
+    def local
+      @dir.expand_path / LOCAL_DIR
+    end
+
+    # Where Bundler keeps plugins for a user outside any project, mirroring
+    # Bundler's user_bundle_path lookup for plugins: <tt>BUNDLE_USER_PLUGIN</tt>
+    # names the root directly, <tt>BUNDLE_USER_HOME</tt> relocates
+    # <tt>.bundle</tt>, and the home directory is the default.
+    def global
+      named = @env["BUNDLE_USER_PLUGIN"]
+      return Pathname(named) if named
+
+      Pathname(@env["BUNDLE_USER_HOME"] || File.join(Dir.home, ".bundle")) / "plugin"
+    end
+
+    # The plugin root Bundler will consult here: beside the Gemfile when one
+    # was found, the project's own root when doctor points Bundler at it (see
+    # #unreachable?), the global root otherwise.
+    def consulted
+      return @gemfile.path.dirname / LOCAL_DIR if @gemfile.exist?
+      return local if unreachable?
+
+      global
+    end
+
+    # Whether this project has a plugin root that Bundler currently ignores.
+    #
+    # bundler/inline installs plugins into <tt><cwd>/.bundle/plugin</tt>, having
+    # set <tt>BUNDLE_GEMFILE</tt> to a bare "Gemfile" for the duration of the
+    # script. A later command in that same directory sets no such variable and
+    # finds no Gemfile on disk, so Bundler falls back to the global root and
+    # reports the plugin as not installed -- while the entry sits here.
+    def unreachable?
+      !@gemfile.exist? && local.directory?
+    end
+  end
+end