git 5.0.0.beta.2 → 5.0.0.beta.4

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 30866d1c683ae76cdb07eb526d9adecd45c8ec08bb53824c3a027984297ec256
-  data.tar.gz: a326ea01ed821d33c4edc60963cd2f6473ecaae2cad0daa82c06747456daa8dc
+  metadata.gz: 24512a581eb9da75ed5026f0579869d4ae549a3c028d94a4d97edb5b5b063ac5
+  data.tar.gz: 86ce5ddca8a1bb92802afbb61e84e7b186a782222f8ff8fa7e6ee14d57020779
 SHA512:
-  metadata.gz: a0f4cc725c36422a2afa046897d89bef4597fe8120215f83b22c9814d8c1817d4b795525c2aa4edd2c8d52bf617e36bba3b181d5a67af9067a5a6b859bbd6707
-  data.tar.gz: 15957da7f84ef75aa7ad78d6eb7eac4d96aab21b56c265749c5def8a7cb035b5fdce651a395a98ce30fccab3d62c5e66f479fae621d16227c1eb1468c4372f5c
+  metadata.gz: fff5622c9a132467a43459c4ea2c5ad059d8e50a18ac7d45b2a7af37abfd37c0ed2e8cc834b654f2cabd99e6a53330a47f0b8e626cbf0e67433ff42f376bf8e0
+  data.tar.gz: 927adb62c1023e826cf76da5522fc7b5fb5c182bfec637e0c3d191967ad148b1b134403f7151a2f66460536bcf0ba4383c9daf40d2cc3a730e4aecb2fa97555a

data/.dockerignore

@@ -0,0 +1,27 @@
+# Keep the Docker build context free of host-generated artifacts so the
+# image always builds gems fresh instead of picking up stale or
+# host-specific state (see .gitignore for the equivalent git-tracked list).
+#
+# .git is also excluded: the Dockerfile initializes its own throwaway git
+# repo instead of relying on the host's, since the host's `.git` may be a
+# linked-worktree pointer file referencing a path that doesn't exist in the
+# image (see docker/test/Dockerfile for details).
+.git
+*.gem
+*.kpf
+*.sw?
+.DS_Store
+.bundle/
+vendor/bundle/
+coverage
+doc
+.yardoc
+pkg
+rdoc
+Gemfile.lock
+node_modules
+package-lock.json
+ai-prompt.erb
+rubocop-report.json
+.rspec_status
+git-reference/

data/.github/copilot-instructions.md

@@ -40,20 +40,15 @@ or explanation does not require a skill.
 | Purpose | Command |
 | --- | --- |
 | First-time setup | `bin/setup` |
-| Run all tests and linters(CI-equivalent) | `bundle exec rake default:parallel` |
-| Run all tests (both suites) | `bundle exec rake test-all:parallel` |
-| Run Test::Unit tests | `bundle exec rake test:parallel` |
+| Run all tests and linters (CI-equivalent) | `bundle exec rake default` |
+| Run all tests and linters (force parallel) | `bundle exec rake default:parallel` |
 | Run all RSpec tests | `bundle exec rake spec:parallel` |
 | Run RSpec unit tests | `bundle exec rake spec:unit:parallel` |
 | Run RSpec integration tests | `bundle exec rake spec:integration:parallel` |
-| Run a specific Test::Unit test | `bundle exec bin/test <test-base-name>` |
 | Run a specific RSpec spec | `bundle exec rspec <path>` |
 | Run linters | `bundle exec rake rubocop yard build` |
 
-**Test suites:** `spec/` (RSpec) is the current suite — all new tests go here.
-`tests/` (Test::Unit) is legacy; only touch it when modifying existing tests there
-or adding pre-migration coverage to verify that a `Git::Lib` → `Git::Commands`
-migration doesn't break existing behavior.
+**Test suite:** `spec/` (RSpec) is the sole test suite — all new tests go here.
 
 ## Commit Conventions
 

data/.github/hooks/bin-setup-on-worktree.json

@@ -0,0 +1,11 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "type": "command",
+        "command": ".github/hooks/run-bin-setup-once.sh",
+        "timeout": 900
+      }
+    ]
+  }
+}

data/.github/hooks/run-bin-setup-once.sh

@@ -0,0 +1,14 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Skip if this repo does not use bin/setup.
+[[ -x "./bin/setup" ]] || exit 0
+
+# Keep setup idempotent per-worktree.
+command -v git >/dev/null 2>&1 || exit 0
+marker="$(git rev-parse --git-path copilot-bin-setup.done 2>/dev/null)" || exit 0
+[[ -f "$marker" ]] && exit 0
+
+./bin/setup
+mkdir -p "$(dirname "$marker")"
+touch "$marker"

data/.github/skills/breaking-change-analysis/SKILL.md

@@ -26,8 +26,6 @@ impact and plan migration.
 
 ## Related skills
 
-- [Review Backward Compatibility](../review-backward-compatibility/SKILL.md) —
-   verify backward compatibility after command migrations
 - [Development Workflow](../development-workflow/SKILL.md) — implement required
    changes using strict TDD
 
@@ -35,20 +33,20 @@ impact and plan migration.
 
 1. Determine which classes and methods are affected.
 2. Check API visibility (`@api public` vs `@api private` in YARD docs).
-3. Check if the change affects `Git::Lib` (facade layer used by most callers).
+3. Check if the change affects `Git::Repository` (the current facade layer, modules under `lib/git/repository/`).
 
 ## Step 2: Find All Usages
 
 1. **Internal usages:**
 
    ```bash
-   grep -rn "method_name" lib/ tests/ spec/
+   grep -rn "method_name" lib/ spec/
    ```
 
 2. **External usage (if applicable):**
 
    ```bash
-   gh search code "Git::Base#method_name language:ruby"
+   gh search code "Git::Repository#method_name language:ruby"
    ```
 
 ## Step 3: Assess and Document Impact
@@ -82,14 +80,13 @@ Produce an impact assessment:
 ## Step 4: Plan Migration Path
 
 **Project versioning policy:**
-- Current release line: v4.x (heading to v5.0.0)
-- Breaking changes are batched for major releases (v5.0.0)
-- Use deprecation warnings in the current release line before removal in the next major
+- Breaking changes are batched for major releases
+- Use deprecation warnings in the current major series before removal in the next major release
 
 **Deprecation approach:**
 
 ```ruby
-# @deprecated Use {#new_method} instead. Will be removed in v5.0.
+# @deprecated Use {#new_method} instead. Will be removed in the next major release.
 def old_method(*args)
   warn "[DEPRECATION] `old_method` is deprecated. Use `new_method` instead."
   new_method(*args)

data/.github/skills/ci-cd-troubleshooting/SKILL.md

@@ -132,7 +132,7 @@ Based on the failure type, investigate:
 2. Run the failing tests locally:
 
    ```bash
-   bundle exec bin/test <test-name>
+   bundle exec rspec <path/to/spec.rb>
    ```
 
 3. Run linters:
@@ -211,7 +211,7 @@ After implementing fixes:
 1. **Run Affected Tests Locally:**
 
    ```bash
-   bundle exec bin/test <test-name>
+   bundle exec rspec <path/to/spec.rb>
    ```
 
 2. **Run Full CI Suite:**

data/.github/skills/command-implementation/REFERENCE.md

@@ -98,8 +98,8 @@ class Diff < Git::Commands::Base
   end
 end
 
-# lib/git/lib.rb — parser contract is visible and auditable:
-Git::Commands::Diff.new(self).call(patch: true, numstat: true, ...)
+# lib/git/repository/diffing.rb — parser contract is visible and auditable:
+Git::Commands::Diff.new(@execution_context).call(patch: true, numstat: true, ...)
 ```
 
 The same applies for `--format=<string>`, `--pretty=<fmt>`, `--no-color`, and all
@@ -156,11 +156,11 @@ the pattern of `cat_file.rb`. The file has three required sections in this order
 4. A "This module contains command classes split by…" paragraph with a bullet for
    every sub-command class using `{Foo::Bar}` YARD links followed by ` — ` and a
    short description
-5. `@api private`
-6. `@see https://git-scm.com/docs/git-foo git-foo documentation`
-7. At least two `@example` blocks — one per sub-command class; each example should
+5. At least two `@example` blocks — one per sub-command class; each example should
    demonstrate the most common (non-error-path) call using a local variable named
    `cmd` and `lib` as the constructor argument
+6. `@see https://git-scm.com/docs/git-foo git-foo documentation`
+7. `@api private`
 8. Empty `module Foo` + `end` block (no methods, no constants)
 
 **Tag ordering inside the YARD comment block:**
@@ -173,10 +173,6 @@ the pattern of `cat_file.rb`. The file has three required sections in this order
 # - {Foo::Bar} — short description
 # - {Foo::Baz} — short description
 #
-# @api private
-#
-# @see https://git-scm.com/docs/git-foo git-foo documentation
-#
 # @example <Short description of the Bar use case>
 #   cmd = Git::Commands::Foo::Bar.new(lib)
 #   cmd.call(...)
@@ -184,6 +180,10 @@ the pattern of `cat_file.rb`. The file has three required sections in this order
 # @example <Short description of the Baz use case>
 #   cmd = Git::Commands::Foo::Baz.new(lib)
 #   cmd.call(...)
+#
+# @see https://git-scm.com/docs/git-foo git-foo documentation
+#
+# @api private
 ```
 
 **Full template:**
@@ -203,10 +203,6 @@ module Git
     # - {Foo::Bar} — what Bar does
     # - {Foo::Baz} — what Baz does
     #
-    # @api private
-    #
-    # @see https://git-scm.com/docs/git-foo git-foo documentation
-    #
     # @example <Short description for bar>
     #   cmd = Git::Commands::Foo::Bar.new(lib)
     #   cmd.call(...)
@@ -215,6 +211,10 @@ module Git
     #   cmd = Git::Commands::Foo::Baz.new(lib)
     #   cmd.call(...)
     #
+    # @see https://git-scm.com/docs/git-foo git-foo documentation
+    #
+    # @api private
+    #
     module Foo
     end
   end
@@ -233,7 +233,7 @@ module's overview.
 - [ ] `@see` link points to `git-scm.com/docs/git-foo` documentation
 - [ ] At least one `@example` block per sub-command class
 - [ ] Each example uses `cmd = Git::Commands::Foo::Bar.new(lib)` form (variable `cmd`, arg `lib`)
-- [ ] Tag order: summary → bullet list → `@api private` → `@see` → `@examples`
+- [ ] Tag order: summary → bullet list → `@example` blocks → `@see` → `@api private`
 - [ ] No class is defined inside the module file; the `module Foo` block is empty
 
 ## Architecture contract
@@ -285,7 +285,7 @@ Structural requirements:
   `@execution_context`
 - `require` statements are limited to files actually used within the command
   class file itself — do not carry over `require` entries that belong only to
-  the facade (`Git::Lib`) or parser layer
+  the `Git::Repository::*` facade or parser layer
 
 ## Command template (Base pattern)
 
@@ -326,9 +326,14 @@ module Git
       class Bar < Git::Commands::Base  # never name the class Object
         arguments do
           # Group related options with section comments (e.g. # Output, # Safety)
-          # NEVER add trailing inline comments (e.g. `# --verbose`) to DSL entries.
-          # The DSL is self-documenting; inline comments duplicate YARD docs and
-          # were removed project-wide in commit 370dffb.
+          # NEVER add trailing inline comments (e.g. `# --verbose`) to DSL entries;
+          # the DSL is self-documenting and inline comments duplicate the YARD docs.
+          # NEVER put YARD tags (@see, @param, @return, etc.) in comments inside this
+          # block. A DSL call such as `flag_option :x` is not a documentable construct,
+          # so YARD silently drops the whole comment (an orphaned doc comment that
+          # Documentation/OrphanedDocComment flags). Put per-option references in the
+          # matching @option tag (use continuation text for URLs) and command-wide
+          # references in a class-level @see.
         end
 
         # Optional: for commands where non-zero exits are valid
@@ -683,7 +688,7 @@ single source of truth for its own option semantics. There are two narrow except
 See `redesign/3_architecture_implementation.md` Insight 6 for the full policy.
 
 This step is required. A command class that only exposes the options that happen to
-be used today in `Git::Lib` is incomplete — callers of the future API should not need
+be used today in the `Git::Repository::*` facade is incomplete — callers of the future API should not need
 to re-open the docs just because the scaffold only covered current usage.
 
 ### Scoping options to sub-command classes
@@ -728,7 +733,7 @@ single-class commands, include all options as described in the decision table ab
 ### Execution-model conflicts
 
 Command classes are neutral — they never hardcode policy choices. Policy defaults
-(`no_edit: true`, `no_progress: true`, etc.) belong to the facade (`Git::Lib`).
+(`no_edit: true`, `no_progress: true`, etc.) belong to the `Git::Repository::*` facade.
 
 > **Anti-pattern:** `literal '--no-edit'` inside a command class.
 >
@@ -833,7 +838,7 @@ allow_exit_status 0..7
 ## Facade delegation and policy options
 
 The command class is only half the story. After scaffolding the command, you must
-also write (or update) the `Git::Lib` method that **delegates** to it. The facade
+also write (or update) the `Git::Repository::*` facade method that **delegates** to it. The facade
 sets safe policy defaults at each call site — `no_edit: true`, `no_progress: true`,
 etc. — not as `literal` entries inside the command class. See "Command-layer
 neutrality" in CONTRIBUTING.md.
@@ -850,7 +855,7 @@ Policy defaults fall into two categories (see also
   that goes through `**opts`.
 
 ```ruby
-# lib/git/lib.rb — facade method for `git pull`
+# lib/git/repository/remote_operations.rb — facade method for `git pull`
 
 PULL_ALLOWED_OPTS = %i[allow_unrelated_histories].freeze
 
@@ -861,7 +866,7 @@ def pull(remote = nil, branch = nil, opts = {})
   allowed_opts = opts.slice(*PULL_ALLOWED_OPTS)
   positional_args = [remote, branch].compact
   # no_edit: true is the non-interactive default (see CONTRIBUTING.md)
-  Git::Commands::Pull.new(self).call(*positional_args, no_edit: true, **allowed_opts).stdout
+  Git::Commands::Pull.new(@execution_context).call(*positional_args, no_edit: true, **allowed_opts).stdout
 end
 ```
 
@@ -878,10 +883,6 @@ Key points for the facade method:
 - **Return the legacy type** — typically `.stdout` or a parsed struct, not
   `CommandLineResult`.
 
-See [Extract Command from Lib](../extract-command-from-lib/SKILL.md) for the complete
-delegation workflow and additional patterns (stdout passthrough, parsed return
-values, opts-hash normalization).
-
 ## Internal compatibility contract
 
 This is the canonical location for the internal compatibility contract. Other
@@ -940,10 +941,10 @@ flag_option :progress, negatable: true
 flag_option :verbose
 value_option :format
 
-# ✅ In Git::Lib — facade passes the policy value explicitly
-Git::Commands::Pull.new(self).call(no_edit: true, no_progress: true)
-Git::Commands::Mv.new(self).call(*args, verbose: true)
-Git::Commands::Fsck.new(self).call(no_progress: true)
+# ✅ In Git::Repository::* — facade passes the policy value explicitly
+Git::Commands::Pull.new(@execution_context).call(no_edit: true, no_progress: true)
+Git::Commands::Mv.new(@execution_context).call(*args, verbose: true)
+Git::Commands::Fsck.new(@execution_context).call(no_progress: true)
 ```
 
 See "Command-layer neutrality" in CONTRIBUTING.md for the full policy.
@@ -965,8 +966,8 @@ newlines are data), hardcode it in a `def call` override instead — exposing it
 ### Unnecessary `require` statements
 
 A command class file should only `require` what it actually uses. The canonical
-example is parser requires: `require 'git/parsers/foo'` is needed by the facade
-(`Git::Lib`) but not by the command class itself — the command class just runs git
+example is parser requires: `require 'git/parsers/foo'` is needed by the
+`Git::Repository::*` facade but not by the command class itself — the command class just runs git
 and returns `CommandLineResult`.
 
 ```ruby

data/.github/skills/command-implementation/SKILL.md

@@ -36,7 +36,8 @@ Additional related skills:
   sibling consistency within a command family
 - [Facade Implementation](../facade-implementation/SKILL.md) — the v5.0.0 facade
   layer (`Git::Repository::*`) that calls these command classes; new facade
-  wiring goes there rather than into `Git::Lib`
+  wiring goes into a `Git::Repository::*` facade module rather than directly into
+  the command class
 
 ## Input
 
@@ -181,7 +182,7 @@ This skill supports three modes. Determine which mode applies before starting:
    failures](REFERENCE.md#common-failures). Additionally:
 
    - For **scaffold** and **update** modes: write or update the
-     `Git::Lib` method per [Facade delegation and policy
+     `Git::Repository::*` facade method per [Facade delegation and policy
      options](REFERENCE.md#facade-delegation-and-policy-options).
    - For **migration PRs**: verify [Phased rollout
      requirements](REFERENCE.md#phased-rollout-requirements).
@@ -210,8 +211,8 @@ For **scaffold** and **update** modes, produce:
    module file for the first command in a namespace)
 2. **Unit tests** — `spec/unit/git/commands/{command}_spec.rb`
 3. **Integration tests** — `spec/integration/git/commands/{command}_spec.rb`
-4. **Facade delegation** — updated `Git::Lib` method in `lib/git/lib.rb`
-5. **All quality gates pass** — rspec, minitest, rubocop, and yard all green
+4. **Facade delegation** — updated `Git::Repository::*` facade method in `lib/git/repository/<topic>.rb`
+5. **All quality gates pass** — RSpec, RuboCop, YARD, and build all green
 
 For **review** mode, produce:
 

data/.github/skills/command-test-conventions/SKILL.md

@@ -241,20 +241,24 @@ expect `--no-edit` unless the test is specifically exercising that option.
 > **Correct pattern:** test each option independently (`it 'passes --no-edit
 > when no_edit is true'`); test the default (no option passed) separately. Policy
 > enforcement (which options the facade passes and why) is tested at the facade
-> layer (`lib_command_spec.rb`).
+> layer (for example, `spec/unit/git/repository/remote_operations_spec.rb`).
 
 **Where to test policy enforcement:** Policy tests belong in the facade layer,
-not in command specs. When a `Git::Lib` method sets policy defaults like
-`no_edit: true` or `no_progress: true`, the corresponding `lib_command_spec.rb`
-(or `lib_spec.rb`) test should verify those defaults reach the command:
+not in command specs. When a `Git::Repository::*` facade method sets policy defaults like
+`no_edit: true` or `no_progress: true`, the corresponding facade unit spec
+(e.g. `spec/unit/git/repository/remote_operations_spec.rb`) should verify those defaults reach the command:
 
 ```ruby
-# spec/unit/git/lib_command_spec.rb — facade policy-default test
+# spec/unit/git/repository/remote_operations_spec.rb — facade policy-default test
 describe '#pull' do
-  it 'defaults to no_edit: true for non-interactive execution' do
-    expect_any_instance_of(Git::Commands::Pull)
-      .to receive(:call).with(anything, no_edit: true).and_call_original
-    lib.pull('origin', 'main')
+  let(:pull_command) { instance_double(Git::Commands::Pull) }
+  let(:pull_result) { command_result('') }
+
+  it 'adds no_edit: true and no_progress: true for non-interactive execution' do
+    expect(Git::Commands::Pull).to receive(:new).with(execution_context).and_return(pull_command)
+    expect(pull_command)
+      .to receive(:call).with('origin', 'main', no_edit: true, no_progress: true).and_return(pull_result)
+    described_instance.pull('origin', 'main')
   end
 end
 ```

data/.github/skills/command-yard-documentation/SKILL.md

@@ -177,12 +177,20 @@ conflicting documentation for the method.
 - Missing `# @!method call(*, **)` directive when there is no `def call` override
   (loses child-specific docs in generated YARD)
 - `@option` docs out of sync with `arguments do`
+- **YARD tags inside the `arguments do` block** — placing a tag (`@see`, `@param`,
+  `@return`, etc.) in a comment above a DSL entry such as `flag_option :x` produces an
+  orphaned doc comment. The DSL call is not a documentable construct, so YARD silently
+  drops the comment and `Documentation/OrphanedDocComment` flags it. Document each
+  option in its `@option` tag (put URLs in continuation text) and use a class-level
+  `@see` for command-wide references. A plain-prose comment (no leading `@tag`) inside
+  the block is fine.
 - **Missing `@raise [ArgumentError]` when `**options` is in the overload signature** —
   every `@overload` that includes `**options` requires
-  `@raise [ArgumentError] if unsupported options are provided`. The base `ArgsBuilder`
-  always raises this at bind time for unknown keys. For commands whose `arguments`
-  block declares **no** options (only `operand` entries), drop `**options` from the
-  signature entirely — then no `@raise [ArgumentError]` is needed.
+  `@raise [ArgumentError] if unsupported options are provided`. The `Arguments` DSL
+  always raises this at bind time for unknown keys via `validate_unsupported_options!`.
+  For commands whose `arguments` block declares **no** options (only `operand` entries),
+  drop `**options` from the signature entirely — then no `@raise [ArgumentError]` is
+  needed.
 - **`**options` in `@overload` without `@param options [Hash]`** — whenever an
   `@overload` signature includes `**options`, a corresponding `@param options [Hash]`
   tag is required. For commands whose `arguments` block declares **no** options (only
@@ -337,8 +345,8 @@ For each command file, run through these checks in order:
       tags) — every command class is `@api private` at the class level, but `call` is
       the public contract and must be marked `@api public`
 - [ ] whenever the `@overload` signature includes `**options`, include
-      `@raise [ArgumentError] if unsupported options are provided` — the base
-      `ArgsBuilder` always raises this at bind time for unknown keys
+      `@raise [ArgumentError] if unsupported options are provided` — the `Arguments`
+      DSL always raises this at bind time for unknown keys via `validate_unsupported_options!`
 - [ ] `@raise [Git::FailedError]` uses the canonical generic wording — **never**
       enumerate specific failure causes; use the form that matches the command's
       declared exit-status range:

data/.github/skills/development-workflow/SKILL.md

@@ -65,11 +65,6 @@ needed.
   reviewing `Git::Commands::*` classes during implementation
 - [Facade Implementation](../facade-implementation/SKILL.md) — scaffolding and
   reviewing `Git::Repository::*` facade methods during implementation
-- [Extract Command from Lib](../extract-command-from-lib/SKILL.md) — migrating a
-  `#command` call in `Git::Lib` into a `Git::Commands::*` class
-- [Extract Facade from Base/Lib](../extract-facade-from-base-lib/SKILL.md) —
-  migrating a public method from `Git::Base` / `Git::Lib` into a
-  `Git::Repository::*` facade method
 
 ## Core TDD Principles
 
@@ -210,8 +205,8 @@ When all tasks are complete, proceed to **Phase 3: FINALIZE**.
    - **Keep It Minimal:** Only write enough of a test to get an expected, failing
      result (the test should fail for the *right* reason).
    - **Execute and Analyze:** Run the specific test file (e.g.,
-     `bundle exec rspec spec/unit/git/commands/<command>_spec.rb` for RSpec or
-     `bundle exec bin/test <test_file>` for TestUnit) and analyze the output.
+     `bundle exec rspec spec/unit/git/commands/<command>_spec.rb`) and analyze the
+     output.
    - **Confirm Expected Failure:** Confirm it fails with an expected error (e.g.,
      assertion failure or missing definition).
    - **Validate:** If the test passes without implementation, the test is invalid or
@@ -479,20 +474,31 @@ Each task follows this cycle: **RED → GREEN → REFACTOR → VERIFY → COMMIT
 **RED:** Write a failing test that describes the desired behavior.
 
 ```ruby
-def test_creates_new_branch
-  @git.branch('feature').create
-  assert @git.branches.local.map(&:name).include?('feature')
+# spec/unit/git/commands/example_spec.rb
+it 'passes the --force flag when force: true is given' do
+  expect_command_capturing('example', '--force').and_return(command_result(''))
+
+  described_class.new(execution_context).call(force: true)
 end
-# Run: bundle exec bin/test test_branch → fails with NoMethodError
+# Run: bundle exec rspec spec/unit/git/commands/example_spec.rb
+#      → fails: NameError (Git::Commands::Example is not defined yet)
 ```
 
 **GREEN:** Write minimal code to make the test pass.
 
 ```ruby
-def create
-  @base.lib.branch_new(@name)
+# lib/git/commands/example.rb
+module Git
+  module Commands
+    class Example < Base
+      arguments do
+        literal 'example'
+        flag_option :force
+      end
+    end
+  end
 end
-# Run: bundle exec bin/test test_branch → passes
+# Run: bundle exec rspec spec/unit/git/commands/example_spec.rb → passes
 ```
 
 **REFACTOR:** Improve code quality without changing behavior, then run all tests.

data/.github/skills/facade-implementation/REFERENCE.md

@@ -10,7 +10,7 @@ is loaded by subagents during the [Facade Implementation](SKILL.md) workflow.
 - [Topic module selection](#topic-module-selection)
   - [Existing modules](#existing-modules)
   - [Decision rules for adding a new module](#decision-rules-for-adding-a-new-module)
-    - [One-at-a-time extraction from `Git::Base` / `Git::Lib`](#one-at-a-time-extraction-from-gitbase--gitlib)
+    - [Choosing a module for a new facade method](#choosing-a-module-for-a-new-facade-method)
   - [Naming a new topic module](#naming-a-new-topic-module)
 - [Designing a facade method](#designing-a-facade-method)
   - [Choosing the return type](#choosing-the-return-type)
@@ -85,16 +85,15 @@ methods is fine when the topic is genuinely distinct; the question is always
 *fit*, not count. Default to extending an existing module whenever the new method
 plausibly fits there.
 
-#### One-at-a-time extraction from `Git::Base` / `Git::Lib`
+#### Choosing a module for a new facade method
 
-When migrating a single method without a planned batch:
+When placing a single facade method without a planned batch:
 
-1. Before deciding placement, scan `Git::Base` and `Git::Lib` for sibling methods
-   on the same git topic (e.g. when extracting `branches_all`, also look for
-   `branch`, `branch_current`, `branch_delete`, `current_branch_state`).
+1. Before deciding placement, scan existing `Git::Repository::*` modules for
+   sibling methods on the same git topic (e.g. when adding a method related to
+   branches, check `Git::Repository::Branching` for existing siblings).
 2. If those siblings form a coherent topic that does not fit any existing module,
-   create the new module on this first extraction so subsequent extractions have
-   a home.
+   create the new module so subsequent additions have a home.
 3. Otherwise place the method in the closest existing module. Revisit module
    organization later if a distinct topic emerges; promote the cluster to its own
    module in a single `refactor(repository):` commit at that point.
@@ -133,11 +132,10 @@ cases, orchestration sequence otherwise.
 
 Apply these rules in order:
 
-1. **Extracting from `Git::Base` or `Git::Lib`?** The facade method **must**
-   return exactly what the legacy method returned (same type, same shape, same
-   nil/empty semantics). Backward compatibility for users who called
-   `g.foo` / `g.lib.foo` is the public contract being preserved during
-   migration; capture the legacy return in the Step 2 plan.
+1. **Changing an existing `Git::Repository` method?** Preserve the existing return
+   type exactly — same shape, same nil/empty semantics. Backward compatibility for
+   callers of `Git::Repository` is the public contract; capture the existing return
+   in the Step 2 plan.
 2. **No legacy method (greenfield facade method)?** Choose the return type from
    the public-API perspective, in this order of preference:
    1. A **domain object** (`Git::BranchInfo`, `Git::DiffResult`, …) when the
@@ -158,11 +156,10 @@ Apply these rules in order:
 The Ruby signature is part of the public contract — just as binding as the
 return type. Apply these rules in order:
 
-1. **Extracting from `Git::Base` or `Git::Lib`?** The facade method **must**
-   preserve the legacy signature exactly: same positional arguments in the same
-   order, same defaults, same `opts = {}` vs. `**options` shape, same
-   nil/sentinel semantics. Capture the legacy signature in the Step 2 plan and
-   diff against it after implementation.
+1. **Changing an existing `Git::Repository` method?** Preserve the existing
+   signature exactly: same positional arguments in the same order, same defaults,
+   same `opts = {}` vs. `**options` shape, same nil/sentinel semantics. Capture the
+   existing signature in the Step 2 plan and diff against it after implementation.
 2. **No legacy method (greenfield facade method)?** Design the signature from
    the public-API perspective:
    1. **Positional arguments** for the natural domain identifiers the method
@@ -197,7 +194,7 @@ patterns](#argument-pre-processing-patterns).
 When the facade method takes no options hash, does no pre-processing, and only
 a trivial post-processing step (such as `.stdout.chomp`), it is a single-line
 delegation. For example, a hypothetical `Git::Repository::Inspection#current_branch`
-preserving `Git::Lib#current_branch`'s `String` contract:
+preserving the `String` return type contract:
 
 ```ruby
 # Return the name of the currently checked-out branch
@@ -491,7 +488,7 @@ or via `include`). `include` copies private instance methods onto the host class
 so any caller with a `Git::Repository` instance can `repo.send(:helper, ...)`.
 This:
 
-1. Re-creates the `Git::Lib` god-class problem the redesign is escaping.
+1. Re-creates the god-class problem `Git::Lib` had — the reason the redesign introduced topic modules.
 2. Couples every topic module silently to ambient mixin state.
 3. Is not actually private and not `@api`-marked, so YARD/tooling cannot enforce it.
 
@@ -782,9 +779,9 @@ body.
 
 ### Changing the legacy return type or signature on extraction
 
-When a facade method is extracted from `Git::Base` / `Git::Lib`, returning a
+When adding or changing a `Git::Repository` facade method, returning a
 different type, accepting a different positional/keyword shape, or changing
-nil-handling silently breaks every caller. Capture the legacy contract in the
+nil-handling silently breaks every caller. Capture the existing contract in the
 Step 2 plan and diff before/after — see
 [Choosing the return type](#choosing-the-return-type) rule 1 and
 [Choosing the method signature](#choosing-the-method-signature) rule 1.

data/.github/skills/facade-implementation/SKILL.md

@@ -48,9 +48,6 @@ Facade Implementation review: Git::Repository::Committing#commit.
   reviewing tests)
 - [Facade YARD Documentation](../facade-yard-documentation/SKILL.md) — facade-specific
   YARD rules for module-level and method-level docs
-- [Extract Facade from Base/Lib](../extract-facade-from-base-lib/SKILL.md) — when a
-  new facade method is migrated from `Git::Base` or `Git::Lib`, the extraction
-  workflow drives this skill in scaffold/update mode
 - [Command Implementation](../command-implementation/SKILL.md) — the underlying
   `Git::Commands::*` classes a facade method calls. Scaffold any missing command
   class first.
@@ -69,8 +66,6 @@ The user provides:
 2. **Git operation(s)** — which `Git::Commands::*` class(es) the method orchestrates.
    If the relevant command class does not exist yet, scaffold it first via
    [Command Implementation](../command-implementation/SKILL.md).
-3. **Optional context** — the source `Git::Lib` / `Git::Base` method when migrating
-   (handled by [Extract Facade from Base/Lib](../extract-facade-from-base-lib/SKILL.md)).
 
 > **Note:** `Git::Repository` is intentionally empty during early phases of the
 > redesign. Its `initialize(execution_context:)` constructor is introduced