standard_id-google 0.3.0 → 0.4.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 88bce7685da60d2df6e41c103d179a5baa6bfb71d9e7f82ecaabb43e280680c7
-  data.tar.gz: 55a57eaba19c3907515a9609548e4d1370adaf400aa3481125e3d2a42e866c9b
+  metadata.gz: 24f43e5bf2451f85eeefc67854060b443fe88781f76228eac4754dc8fcaf42c7
+  data.tar.gz: d17aa2f191d3616e3c17f838f2c4c0630c93c4e1afb8372d1f6fd311b61ccbf1
 SHA512:
-  metadata.gz: 1453686923aaf994a195d5d8d811fce1d1f02a4128eba1bcecffe457a533bad0a9345be8ae6f2545375e5c65d5357a170d450f18ca5ae71ae322f822b5a2013c
-  data.tar.gz: 1d23bfa48f33aab5980bbd9f6a4e5594dba9259dbe8cac91b434a3700f13187884972ca783674bc29986ebfc7c22040bf516445c338cc0d24ae15eb1099a0f9f
+  metadata.gz: 361bd688a31baaf8bed7ec6a4adfd13c130f146af786ec20e00809be932ee304b9f27bd73890754053a972bad67e51e92dacd1dd6dfc8fe20e5b5c13800a10f8
+  data.tar.gz: 7dfbd6c33aa66ec005e29774a7b8419c68593d78c5959933b7ec8c71814dfe454f718e147a8714b32a6b51ce85f04d0cf8c163b0f69d1ae9d0bc636aa2cf4e8d

data/CHANGELOG.md

@@ -7,6 +7,73 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.4.0] - 2026-07-31
+
+### Added
+
+- **Install generator: `bin/rails g standard_id:google:install`.** Writes
+  `config/initializers/standard_id_google.rb` with the `social.google_*` fields
+  wired to ENV, then prints the environment variables the host has to set and
+  the reminder that `/auth/callback/google` must be registered as an authorized
+  redirect URI for **every** origin served — the Google console matches the
+  redirect exactly, so staging and production each need their own. Idempotent:
+  re-running skips an existing initializer; `--force` overwrites,
+  `--skip-initializer` writes nothing.
+
+  It writes a **separate** file rather than editing `standard_id.rb`, so the
+  provider can be removed by deleting one file and `standard_id`'s own install
+  generator stays free to overwrite its initializer without clobbering these
+  credentials. Initializers load alphabetically, so the base config is applied
+  first. The generated file uses the `config.social.` form throughout — a spec
+  pins that it never emits the unqualified `config.google_*` form, which works
+  today only because the names happen to be unique across scopes.
+
+  Five of the nine `standard_*` gems shipped an install generator and this was
+  not one of them, which left both consumers assembling the block from the
+  README by hand.
+
+### Documentation
+
+- **Consumer list corrected in `CLAUDE.md`: this gem has two consumers, not
+  one.** It named `luminality-web` only; `sidekick-web` also consumes it. Both
+  live in sibling workspaces rather than beside this repo, which is how the
+  second one went unnoticed.
+
+- **Corrected the Configuration section, which showed a form that raised on
+  `standard_id` <= 0.32.0.** These fields are declared by this gem, and until
+  `standard_id` 0.33.0 they were declared from this gem's Railtie
+  `after_initialize` — after `config/initializers` — so the documented plain
+  initializer raised `StandardId::ConfigurationError: Unknown field
+  'google_client_id' for scope 'social'`. The README now records the
+  `after_initialize` workaround for older `standard_id`, states that 0.33.0
+  declares provider fields before `:load_config_initializers` so the plain form
+  is correct there, and notes that the fields do not exist at all without this
+  gem in the Gemfile — on any `standard_id` version.
+
+### Changed
+
+- **`standard_id` dependency tightened from `~> 0.1, >= 0.1.7` to `~> 0.29.0`.**
+  The old constraint claimed compatibility with every `0.x` release while this
+  plugin reaches into `StandardId::ProviderRegistry` and
+  `StandardId::Providers::Google`, and `standard_id` is pre-1.0 with breaking
+  minors. Bundler would happily resolve against an untested minor and fail at
+  runtime instead of at resolution. Both current consumers already pin
+  `standard_id "~> 0.29.0"`, so nothing existing is affected.
+
+### Fixed
+
+- Gemspec no longer packages the `.claude/` directory. Published `0.3.0` shipped
+  `.claude/settings.json`, `.claude/hooks/enforce-worktree.sh`, and three skill
+  files to every consumer — this gem's `spec.files` reject-list was the only one
+  in the `standard_*` family missing the `.claude/` prefix (`standard_id-apple`
+  already had it). Packaged file count drops 21 → 16; `lib/` and `LICENSE` are
+  unaffected.
+- Gemspec now uses an allow-list (`Dir["lib/**/*", …]`) rather than a
+  `git ls-files` reject-list, so packaging fails **closed** and this class of
+  leak cannot recur. Also drops `.editorconfig`, `.pinact.yaml`, `.rspec`,
+  `.rubocop.yml`, `.ruby-version`, `AGENTS.md`, `CLAUDE.md`, and
+  `CODE_OF_CONDUCT.md`; `lib/` is byte-identical.
+
 ## [0.3.0] - 2026-04-29
 
 ### Added

data/{LICENSE.txt → LICENSE}

@@ -1,6 +1,6 @@
 The MIT License (MIT)
 
-Copyright (c) Jaryl Sim
+Copyright (c) 2026 Rarebit One
 
 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the

data/README.md

@@ -20,11 +20,28 @@ bundle install
 
 The gem automatically registers itself with StandardId when it is required.
 
+Then run the install generator to drop the credentials block in place:
+
+```bash
+bin/rails g standard_id:google:install
+```
+
+This writes `config/initializers/standard_id_google.rb` — deliberately a
+separate file from `config/initializers/standard_id.rb`, so the provider can be
+removed by deleting one file and `standard_id`'s own install generator stays
+free to overwrite its initializer without clobbering these values. Initializers
+load alphabetically, so the base config is applied first. The generator is
+idempotent; re-running on an existing initializer skips with a clear message
+(pass `--force` to overwrite).
+
 ## Configuration
 
-Configure your Google credentials inside the StandardId configuration block:
+The generator writes this for you; the block is documented here for hosts
+configuring by hand. Configure your Google credentials inside the StandardId
+configuration block:
 
 ```ruby
+# config/initializers/standard_id.rb
 StandardId.configure do |config|
   config.social.google_client_id = ENV.fetch("GOOGLE_OAUTH_CLIENT_ID", nil)
   config.social.google_client_secret = ENV.fetch("GOOGLE_OAUTH_CLIENT_SECRET", nil)
@@ -33,6 +50,37 @@ end
 
 With those values in place, StandardId routes such as `/auth/callback/google` continue to function using this provider gem.
 
+### Boot ordering (standard_id <= 0.32.0)
+
+These fields are declared by *this gem*, not by `standard_id`, and until
+`standard_id` 0.33.0 they were declared from this gem's Railtie
+`after_initialize` — which runs *after* `config/initializers`. On `standard_id`
+**0.32.0 and earlier** the block above therefore raised:
+
+```
+StandardId::ConfigurationError: Unknown field 'google_client_id' for scope 'social'
+```
+
+The workaround was to wrap the writes:
+
+```ruby
+# Only needed on standard_id <= 0.32.0
+Rails.application.config.after_initialize do
+  StandardId.configure do |config|
+    config.social.google_client_id = ENV.fetch("GOOGLE_OAUTH_CLIENT_ID", nil)
+    config.social.google_client_secret = ENV.fetch("GOOGLE_OAUTH_CLIENT_SECRET", nil)
+  end
+end
+```
+
+`standard_id` **>= 0.33.0** declares every loaded provider's fields before
+`:load_config_initializers`, so a plain initializer is correct. The wrapper is no
+longer needed and existing ones keep working unchanged.
+
+Note this is about *ordering*, not just versions: **the fields do not exist
+without this gem in your Gemfile**, on any `standard_id` version. Configuring
+`social.google_*` with the plugin absent raises the same error, correctly.
+
 ## Testing
 
 Run the provider test suite with:
@@ -53,4 +101,4 @@ To release a new version:
 
 ## License
 
-The gem is available as open source under the terms of the [MIT License](LICENSE.txt).
+The gem is available as open source under the terms of the [MIT License](LICENSE).

data/lib/generators/standard_id/google/install/install_generator.rb

@@ -0,0 +1,76 @@
+# frozen_string_literal: true
+
+require "rails/generators"
+
+module StandardId
+  module Google
+    module Generators
+      # Installs the Google provider's credentials block in a host Rails app.
+      #
+      # Writes `config/initializers/standard_id_google.rb` — a separate file
+      # from `config/initializers/standard_id.rb` on purpose. The provider is
+      # opt-in per app, so its credentials should be removable by deleting one
+      # file, and `standard_id`'s own install generator must stay free to
+      # overwrite its initializer without clobbering these values.
+      #
+      # Initializers load alphabetically, so `standard_id.rb` runs before
+      # `standard_id_google.rb` — the base configuration is already applied by
+      # the time this file sets the `social.google_*` fields.
+      #
+      # Idempotent: re-running skips an initializer that is already there.
+      # `--skip-initializer` opts out; `--force` overwrites.
+      class InstallGenerator < Rails::Generators::Base
+        source_root File.expand_path("templates", __dir__)
+
+        INITIALIZER_PATH = "config/initializers/standard_id_google.rb"
+
+        desc <<~DESC
+          Installs StandardId Google. This writes #{INITIALIZER_PATH} with the
+          social.google_* fields wired to ENV, and prints the env vars the host
+          needs to set.
+
+          The generator is idempotent — an existing initializer is skipped with
+          a clear message. Pass --force to overwrite.
+        DESC
+
+        class_option :skip_initializer, type: :boolean, default: false,
+          desc: "Do not write #{INITIALIZER_PATH}"
+        class_option :force, type: :boolean, default: false,
+          desc: "Overwrite #{INITIALIZER_PATH} if it already exists"
+
+        def copy_initializer
+          if options[:skip_initializer]
+            say_status("skip", "#{INITIALIZER_PATH} (--skip-initializer)", :yellow)
+            return
+          end
+
+          if File.exist?(File.join(destination_root, INITIALIZER_PATH)) && !options[:force]
+            say_status("identical", "#{INITIALIZER_PATH} (already exists; pass --force to overwrite)", :blue)
+            return
+          end
+
+          template "initializer.rb.erb", INITIALIZER_PATH, force: options[:force]
+        end
+
+        def print_env_hint
+          return if options[:skip_initializer]
+
+          say ""
+          say "=" * 79
+          say "StandardId Google installed."
+          say ""
+          say "Set these in the host's environment (1Password / DO app spec / .env):"
+          say ""
+          say "  GOOGLE_OAUTH_CLIENT_ID      the OAuth 2.0 Web application client ID"
+          say "  GOOGLE_OAUTH_CLIENT_SECRET  its client secret"
+          say ""
+          say "Register /auth/callback/google as an authorized redirect URI in the"
+          say "Google Cloud console for EVERY origin you serve — the console matches"
+          say "the redirect exactly, so staging and production each need their own."
+          say "=" * 79
+          say ""
+        end
+      end
+    end
+  end
+end

data/lib/generators/standard_id/google/install/templates/initializer.rb.erb

@@ -0,0 +1,30 @@
+# frozen_string_literal: true
+
+# Google Sign In credentials for StandardId.
+#
+# These two fields are declared by the standard_id-google gem, NOT by
+# standard_id — they do not exist unless this gem is in the Gemfile, on any
+# standard_id version. Removing the gem and leaving this file behind raises
+# `StandardId::ConfigurationError: Unknown field 'google_client_id' for scope
+# 'social'`, which is correct behaviour, not a bug.
+#
+# Set them in the `social` scope, as below. The unqualified form
+# (`config.google_client_id = ...`) happens to work today because StandardId
+# routes a unique unqualified name to its owning scope, but it stops working
+# the day another scope declares a colliding name. Use `config.social.`.
+#
+# On standard_id <= 0.32.0 these fields were declared from this gem's Railtie
+# `after_initialize`, which runs AFTER config/initializers — so the plain block
+# below raised at boot and had to be wrapped:
+#
+#   Rails.application.config.after_initialize do
+#     StandardId.configure { |config| config.social.google_client_id = ... }
+#   end
+#
+# standard_id >= 0.33.0 declares every loaded provider's fields before
+# `:load_config_initializers`, so the plain form is correct. Existing wrappers
+# keep working and need no change.
+StandardId.configure do |config|
+  config.social.google_client_id = ENV.fetch("GOOGLE_OAUTH_CLIENT_ID", nil)
+  config.social.google_client_secret = ENV.fetch("GOOGLE_OAUTH_CLIENT_SECRET", nil)
+end

data/lib/standard_id/google/version.rb

@@ -2,6 +2,6 @@
 
 module StandardId
   module Google
-    VERSION = "0.3.0"
+    VERSION = "0.4.0"
   end
 end

metadata

@@ -1,11 +1,11 @@
 --- !ruby/object:Gem::Specification
 name: standard_id-google
 version: !ruby/object:Gem::Version
-  version: 0.3.0
+  version: 0.4.0
 platform: ruby
 authors:
 - Jaryl Sim
-bindir: exe
+bindir: bin
 cert_chain: []
 date: 1980-01-02 00:00:00.000000000 Z
 dependencies:
@@ -27,22 +27,22 @@ dependencies:
   name: standard_id
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.1'
     - - ">="
       - !ruby/object:Gem::Version
-        version: 0.1.7
+        version: '0.29'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '1.0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.1'
     - - ">="
       - !ruby/object:Gem::Version
-        version: 0.1.7
+        version: '0.29'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '1.0'
 description: Extracted StandardId::Providers::Google implementation packaged as a
   standalone gem so StandardId installations can opt into Sign in with Google independently.
 email:
@@ -51,22 +51,12 @@ executables: []
 extensions: []
 extra_rdoc_files: []
 files:
-- ".claude/hooks/enforce-worktree.sh"
-- ".claude/settings.json"
-- ".claude/skills/publish-gem/SKILL.md"
-- ".claude/skills/start/SKILL.md"
-- ".claude/skills/worktree/SKILL.md"
-- ".editorconfig"
-- ".rspec"
-- ".rubocop.yml"
-- ".ruby-version"
-- AGENTS.md
 - CHANGELOG.md
-- CLAUDE.md
-- CODE_OF_CONDUCT.md
-- LICENSE.txt
+- LICENSE
 - README.md
 - Rakefile
+- lib/generators/standard_id/google/install/install_generator.rb
+- lib/generators/standard_id/google/install/templates/initializer.rb.erb
 - lib/standard_id/google.rb
 - lib/standard_id/google/providers/google.rb
 - lib/standard_id/google/railtie.rb

data/.claude/hooks/enforce-worktree.sh

@@ -1,84 +0,0 @@
-#!/bin/bash
-# Enforce worktree-only file modifications for Claude Code
-#
-# Runs on PreToolUse for Edit, Write, and NotebookEdit tools.
-# Blocks all file modifications in the main checkout — changes must
-# happen inside a git worktree (.worktrees/<name>/).
-#
-# Exit codes:
-#   0 — allow (in a worktree, CI, or non-git path)
-#   2 — block (in main checkout)
-#
-# No programmatic bypass — this is intentional. If the hook itself has a bug,
-# a human must fix it manually (edit the file or remove from settings.json).
-#
-# Note: This hook covers Edit, Write, and NotebookEdit tools. Bash tool writes
-# (echo/sed/tee/cp) are not intercepted — the CLAUDE.md instruction is the
-# enforcement layer for those. Covering Bash reliably would require parsing
-# arbitrary shell commands, which is brittle.
-
-# Guard: jq required for JSON parsing
-if ! command -v jq >/dev/null 2>&1; then
-  exit 0
-fi
-
-# Skip in CI environments
-if [[ "${CI:-}" == "true" ]] || [[ -n "${GITHUB_ACTIONS:-}" ]]; then
-  exit 0
-fi
-
-INPUT=$(cat)
-TOOL_NAME=$(printf '%s' "$INPUT" | jq -r '.tool_name // ""') || exit 0
-
-# Extract file path based on tool (NotebookEdit uses notebook_path, not file_path)
-case "$TOOL_NAME" in
-  Edit|Write)
-    FILE_PATH=$(printf '%s' "$INPUT" | jq -r '.tool_input.file_path // ""') || exit 0
-    ;;
-  NotebookEdit)
-    FILE_PATH=$(printf '%s' "$INPUT" | jq -r '.tool_input.notebook_path // .tool_input.file_path // ""') || exit 0
-    ;;
-  *)
-    exit 0
-    ;;
-esac
-
-if [[ -z "$FILE_PATH" ]]; then
-  exit 0
-fi
-
-# Find an existing directory to run git commands in
-if [[ -d "$FILE_PATH" ]]; then
-  CHECK_DIR="$FILE_PATH"
-elif [[ -e "$FILE_PATH" ]]; then
-  CHECK_DIR=$(dirname "$FILE_PATH")
-else
-  # File doesn't exist yet — walk up to find an existing directory
-  CHECK_DIR=$(dirname "$FILE_PATH")
-  while [[ ! -d "$CHECK_DIR" ]] && [[ "$CHECK_DIR" != "/" ]]; do
-    CHECK_DIR=$(dirname "$CHECK_DIR")
-  done
-fi
-
-if [[ ! -d "$CHECK_DIR" ]]; then
-  exit 0
-fi
-
-# Check if we're inside a git repository at all
-GIT_DIR=$(cd "$CHECK_DIR" && git rev-parse --git-dir 2>/dev/null) || exit 0
-
-# Make relative paths absolute
-if [[ "$GIT_DIR" != /* ]]; then
-  GIT_DIR=$(cd "$CHECK_DIR" && cd "$GIT_DIR" && pwd) || exit 0
-fi
-
-# If git-dir contains /worktrees/, we're in a worktree — allow
-if [[ "$GIT_DIR" == *".git/worktrees/"* ]]; then
-  exit 0
-fi
-
-# We're in the main checkout — block
-echo "❌ Blocked: Cannot modify files in the main checkout." >&2
-echo "   Create a worktree first: /worktree or /start <issue>" >&2
-echo "   File: $FILE_PATH" >&2
-exit 2

data/.claude/settings.json

@@ -1,24 +0,0 @@
-{
-  "permissions": {
-    "allow": [
-      "Skill(worktree)",
-      "Skill(start)",
-      "Bash(git worktree:*)",
-      "Bash(git stash:*)"
-    ]
-  },
-  "hooks": {
-    "PreToolUse": [
-      {
-        "matcher": "Edit|Write|NotebookEdit",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/enforce-worktree.sh",
-            "timeout": 10
-          }
-        ]
-      }
-    ]
-  }
-}

data/.claude/skills/publish-gem/SKILL.md

@@ -1,211 +0,0 @@
----
-name: publish-gem
-description: "Publish a Ruby gem to RubyGems.org via CI. Use when the user says 'publish gem', 'push gem', 'release gem', or '/publish-gem'. Handles version bump, changelog, build verification, PR, tagging, and CI-driven publish."
----
-
-# Publish Gem Skill
-
-Prepare and publish a Ruby gem to RubyGems.org via GitHub Actions trusted publishing.
-
-Publishing is done by CI (not locally) — pushing a version tag triggers the `release.yml` workflow which builds the gem, creates a GitHub Release, and pushes to RubyGems via OIDC. This skill handles everything up to and including the tag push.
-
-## Usage
-
-```
-/publish-gem              # Full release flow
-/publish-gem --dry-run    # Verify everything, stop before PR creation
-```
-
-## Workflow
-
-### 1. Verify Context
-
-Confirm we're in a gem project:
-
-```bash
-# Check current branch
-git branch --show-current
-
-# Must have a .gemspec file
-ls *.gemspec
-```
-
-**Blockers:**
-- No `.gemspec` found — stop, not a gem project
-- Multiple `.gemspec` files found — ask the user which one to build
-
-**Branch handling:**
-- If not on `main`, switch automatically: `git checkout main` (publishing from non-main is almost never intentional). If the user explicitly requested publishing from a non-main branch, warn and ask for confirmation before switching.
-- After switching (or if already on `main`), always sync with remote:
-  ```bash
-  git pull --rebase origin main
-  ```
-- If the rebase fails due to conflicts, stop and ask the user to resolve them before proceeding
-- After syncing, verify the working tree is clean (`git status --porcelain`). Warn if dirty — the build may include uncommitted changes.
-- Clean up any stale `.gem` files in the working directory before proceeding:
-  ```bash
-  rm -f *.gem
-  ```
-
-### 2. Extract Gem Metadata
-
-Read the gemspec to extract key details:
-
-```bash
-# Get gem name and version
-ruby -e "spec = Gem::Specification.load(Dir['*.gemspec'].first); puts \"#{spec.name} #{spec.version}\""
-```
-
-Also read and display:
-- Current version from the gemspec
-- CHANGELOG.md entry for this version (if exists)
-- `spec.files` count to verify packaging
-
-### 3. Pre-Publish Checks
-
-```bash
-# Check if this version is already published on RubyGems.org
-gem info -r <gem_name> -v <version>
-
-# Check if CHANGELOG.md exists when gemspec references it
-ruby -e "spec = Gem::Specification.load(Dir['*.gemspec'].first); puts spec.metadata['changelog_uri']"
-test -f CHANGELOG.md && echo "CHANGELOG.md found" || echo "CHANGELOG.md missing"
-```
-
-**Blockers:**
-- Version already published — ask the user what version to bump to (suggest next patch/minor/major). If the user declines, abort the publish.
-
-**Warnings:**
-- Gemspec `changelog_uri` is set but `CHANGELOG.md` does not exist locally — warn the user. This will result in a broken link on RubyGems.org.
-- CHANGELOG.md has no entry for the version being published — warn the user. The `release.yml` workflow will fail if no changelog entry exists for the version.
-
-### 4. Version Bump (if needed)
-
-When the current version is already published, or the user requests a bump:
-
-1. Update `lib/<gem_name>/version.rb` with the new version
-2. Run `bundle install` to sync `Gemfile.lock`
-
-**Critical:** Always run `bundle install` after changing the version to keep `Gemfile.lock` in sync. Skipping this causes CI failures.
-
-### 5. Update CHANGELOG.md
-
-If the `[Unreleased]` section in CHANGELOG.md has content:
-1. Rename `[Unreleased]` to `[<version>] - <today's date>` (format: YYYY-MM-DD)
-2. Add a new empty `[Unreleased]` section above it
-
-If `[Unreleased]` is empty, warn the user and ask if they want to proceed without changelog entries for this version.
-
-### 6. Run Tests
-
-```bash
-bundle exec rspec
-```
-
-**Blockers:**
-- Tests fail — stop and ask the user to fix. Do not proceed with a failing test suite.
-
-### 7. Build Verification
-
-```bash
-gem build <name>.gemspec
-```
-
-Verify the `.gem` file was created, show its size, then clean up:
-
-```bash
-rm <name>-<version>.gem
-```
-
-### 8. Release Summary
-
-Present a summary before proceeding:
-
-```
-## Release Summary
-
-Name:     <gem_name>
-Version:  <version>
-Files:    <file count> files in gem
-Registry: https://rubygems.org (published by CI via trusted publisher)
-
-Changelog:
-  <first few lines of the version's CHANGELOG entry>
-
-Next steps:
-  1. Create version bump PR
-  2. Merge PR (manual)
-  3. Tag release → CI publishes to RubyGems + creates GitHub Release
-```
-
-If `--dry-run` was passed, stop here.
-
-### 9. Create Version Bump PR
-
-Commit the version bump, changelog, and lockfile on a branch and open a PR:
-
-```bash
-git checkout -b chore/release-v<version>
-git add lib/<gem_name>/version.rb Gemfile.lock CHANGELOG.md
-git commit -m "chore: Release v<version>"
-git push -u origin chore/release-v<version>
-gh pr create --title "chore: Release v<version>" --body "$(cat <<'EOF'
-## Release v<version>
-
-<changelog entry for this version>
-
-After merging, Claude will tag `v<version>` which triggers CI to:
-- Create a GitHub Release with changelog notes
-- Build and publish the gem to RubyGems.org via trusted publisher
-EOF
-)"
-```
-
-Tell the user to review and merge the PR, then let you know when it's merged.
-
-### 10. Tag the Release (after PR merge)
-
-When the user confirms the PR is merged:
-
-```bash
-# Sync main — use reset to avoid divergent branch issues from squash merge
-git checkout main
-git fetch origin main
-git reset --hard origin/main
-
-# Tag the merged commit
-git tag -a v<version> -m "Release v<version>"
-git push origin v<version>
-
-# Clean up the bump branch locally
-# -D needed because squash merge doesn't preserve individual commits in main's history
-git branch -D chore/release-v<version>
-# Remote branch may already be deleted by GitHub's auto-delete setting — ignore errors
-git push origin --delete chore/release-v<version> 2>/dev/null || true
-```
-
-The tag push triggers `release.yml` which:
-1. Verifies the tag version matches `version.rb`
-2. Waits for CI to pass
-3. Extracts changelog notes and creates a GitHub Release
-4. Builds the gem and publishes to RubyGems.org via OIDC trusted publisher
-
-### 11. Output
-
-Report:
-1. RubyGems URL: `https://rubygems.org/gems/<name>` (available after CI completes)
-2. Git tag created: `v<version>`
-3. GitHub Release + RubyGems publish: triggered by CI — link: `https://github.com/<owner>/<repo>/actions`
-4. Remind: allow a few minutes for CI to complete, then the gem will appear on RubyGems and the GitHub Release will be created
-
-## Error Handling
-
-| Error | Solution |
-|-------|----------|
-| `gem build` fails | Fix gemspec errors and retry |
-| Tests fail | Fix tests before proceeding |
-| Tag already exists | Version was previously tagged — skip tagging |
-| Tag push fails | Likely a permissions issue — report and continue |
-| Remote branch already deleted | GitHub auto-deleted it — ignore the error |
-| User declines version bump | Abort the publish |
-| CI publish fails | Check the Actions tab — common causes: trusted publisher not configured on RubyGems.org, `rubygems` environment not set up in GitHub repo settings, or version mismatch between tag and version.rb |

data/.claude/skills/start/SKILL.md

@@ -1,185 +0,0 @@
----
-name: start
-description: "Start working on Linear issues. Use when the user says 'start working on', 'pick up issue', 'work on RAR-123', or wants to begin development on Linear issues. Handles status updates, branch creation, and context gathering."
----
-
-# Start Skill
-
-Begin working on Linear issues with proper setup: update status, create branches, gather context, and track progress.
-
-## Prerequisites
-
-This skill requires the Linear MCP server to be configured. If Linear tools (`mcp__linear__*`) are not available, the skill will warn and offer to proceed with git-only setup (branch creation without status updates).
-
-## Scope
-
-This skill sets up local development for Linear issues. It does **NOT**:
-- Merge PRs to main (merging is a human decision)
-- Delete branches or worktrees automatically
-- Close or complete Linear issues
-
-## Usage
-
-```
-/start <issue-identifiers...>   # Start specific issues (e.g., /start RAR-123 RAR-124)
-/start --mine                    # Show my assigned issues ready to start
-/start --backlog                 # Show backlog issues for a team
-```
-
-## Workflow
-
-> **Note:** MCP tool calls shown below use pseudocode syntax for readability.
-> Actual invocation uses Claude's tool use API with the `mcp__linear__*` tools.
-
-### 1. Parse Input and Fetch Issues
-
-**If specific identifiers provided:**
-
-Fetch each issue using Linear MCP:
-
-```
-mcp__linear__get_issue(id: "RAR-123", includeRelations: true)
-```
-
-**If `--mine` flag:**
-
-```
-mcp__linear__list_issues(assignee: "me", state: "Todo", limit: 10)
-```
-
-**If `--backlog` flag (with optional `--team` and `--project` filters):**
-
-```
-mcp__linear__list_issues(
-  team: "<from --team flag, default: Rarebit>",
-  project: "<from --project flag, if provided>",
-  state: "Backlog",
-  limit: 10
-)
-```
-
-Present the issues and let the user select which to work on.
-
-### 2. Pre-Work Checks
-
-Before starting, verify:
-
-**Check for blockers:**
-
-```
-# From get_issue with includeRelations: true
-# Look at the blocking/blockedBy relations
-```
-
-If blocked:
-```
-Warning: RAR-123 is blocked by:
-  - RAR-120: "Set up middleware" (In Progress)
-
-Options:
-1. Start anyway (work may be blocked)
-2. Start the blocking issue instead
-3. Cancel
-```
-
-**Check issue readiness:**
-- Has description/acceptance criteria?
-- Has assigned estimate?
-
-If missing context, warn but allow proceeding.
-
-### 3. Update Issue Status
-
-**Skip this step if `--no-status` flag is provided.**
-
-Update each issue to "In Progress":
-
-```
-mcp__linear__save_issue(
-  id: "<issue-uuid>",
-  stateId: "<in-progress-state-id>"
-)
-```
-
-The workflow should not block on Linear failures — local development can proceed.
-
-### 4. Set Up Worktree
-
-**Always create a worktree** to isolate this work from any other state in the repo. This prevents changes from different sessions bleeding into unrelated PRs.
-
-```bash
-DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@refs/remotes/origin/@@')
-DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
-git fetch origin "$DEFAULT_BRANCH"
-git worktree add .worktrees/<identifier> -b <branch-name> "origin/$DEFAULT_BRANCH"
-```
-
-**`--no-worktree` flag:** If the user explicitly passes `--no-worktree`, check the current state:
-- On the default branch with a clean working tree → fall back to a simple branch:
-  ```bash
-  DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@refs/remotes/origin/@@')
-  DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
-  git fetch origin "$DEFAULT_BRANCH"
-  git checkout -b <branch-name> "origin/$DEFAULT_BRANCH"
-  ```
-- Otherwise → **stop and report why**:
-  _"Cannot skip worktree: working tree has uncommitted changes (or is on a feature branch). Stash or commit your changes first, switch to the default branch, then re-run with `--no-worktree`."_
-
-> **Note:** The previous version of this skill offered stash and branch-switch workflows. Those paths have been removed in favor of always using worktrees. If you prefer to stash instead, run `git stash push -m "WIP"` manually before `/start`.
-
-See `/worktree` skill for full worktree conventions.
-
-**Branch name format:**
-
-Use Linear's `gitBranchName` field if available, or generate:
-`{identifier}/{short-description}` (e.g., `rar-123/add-feature-name`)
-
-**Worktree naming:** `.worktrees/<identifier>` (e.g., `.worktrees/rar-123`)
-
-### 5. Display Issue Context
-
-```
-Starting: RAR-123
-Issue: <title>
-URL: https://linear.app/...
-
-Description:
-<full description>
-
-Acceptance Criteria:
-- [ ] ...
-
-Branch: <branch-name>
-```
-
-### 6. Create Initial Todo List
-
-Based on the issue description, create a todo list to track progress.
-
-## Flags Reference
-
-| Flag | Description |
-|------|-------------|
-| `--mine` | List my assigned issues in Todo state |
-| `--backlog` | List team backlog issues |
-| `--no-worktree` | Skip worktree if on the default branch + clean; stops with error otherwise |
-| `--no-status` | Skip status update (just create branch) |
-| `--team <name>` | Filter by team (default: Rarebit) |
-| `--project <name>` | Filter by project |
-
-## Error Handling
-
-| Error | Solution |
-|-------|----------|
-| Linear MCP unavailable | Warn and offer to proceed with just git setup |
-| Issue not found | Verify identifier, check team access |
-| Issue already in progress | Ask if user wants to continue anyway |
-| Issue is done/canceled | Warn and suggest reopening or selecting different issue |
-| Status update fails | Offer to continue with local setup, retry, or cancel |
-| Branch already exists | Offer to checkout existing or create with suffix |
-| Worktree already exists | Offer to use existing worktree or create with suffix |
-
-## Integration with Other Skills
-
-- After completing work, create a PR with `gh pr create`, or use `/publish-gem` when ready to release
-- The branch naming convention ensures the Linear issue can be auto-detected from the branch

data/.claude/skills/worktree/SKILL.md

@@ -1,143 +0,0 @@
----
-name: worktree
-description: "Create an isolated worktree for new work. Always creates a worktree by default to prevent cross-contamination between sessions. Use at the start of any session, or when the user says 'worktree', 'isolate', 'fresh start', or 'new worktree'."
----
-
-# Worktree Skill
-
-Creates an isolated worktree for new work. **Always creates a worktree by default** — this prevents changes from different work sessions bleeding into unrelated PRs.
-
-## Why Worktree-by-Default
-
-Every new piece of work gets its own worktree. This eliminates the most common source of cross-contamination: starting new work in a repo that has leftover state from a previous session (uncommitted changes, wrong branch, etc.). The only exception is when the user explicitly opts out.
-
-> **Note:** The previous version of this skill offered a stash-based workflow. That path has been removed in favor of always using worktrees. If you prefer to stash instead, run `git stash push -m "WIP"` manually before invoking `/start` or `/worktree`.
-
-## Why `.worktrees/`
-
-Worktrees are created inside the repo at `.worktrees/<name>` (not under `.claude/worktrees/`). This ensures:
-- Worktrees are accessible inside devcontainers (mounted at `/workspace/.worktrees/`)
-- Consistent convention across all repos in the workspace
-- The `.worktrees/` directory is gitignored in each repo
-
-## Usage
-
-```
-/worktree                          # Create a worktree (always, regardless of state)
-/worktree <name>                   # Create a named worktree directly
-/worktree --stay            # Skip worktree creation, work in current checkout
-```
-
-## Workflow
-
-### Phase 1: Detect Current State
-
-Gather the repo state (for reporting, not for deciding whether to create a worktree):
-
-```bash
-# Current branch
-CURRENT_BRANCH=$(git branch --show-current)
-
-# Default branch
-DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@refs/remotes/origin/@@')
-DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
-
-# Uncommitted changes (staged + unstaged + untracked)
-git status --porcelain
-```
-
-### Phase 2: Decision
-
-**Default behavior:** Always create a worktree. Go straight to Phase 3 → Phase 4. Any uncommitted changes on the current branch are left untouched — the worktree is a separate checkout, so existing work is preserved exactly as-is.
-
-**`--stay` flag:** Skip worktree creation and stay in the current checkout. This is for when the user explicitly wants to continue work on the current branch (e.g., resuming a previous session). If dirty state is detected, inform the user what's there but **do not stop** — the user is consciously choosing to stay. This differs from `/start --no-worktree`, which hard-stops on dirty state because starting new work on an unclean tree risks cross-contamination.
-
-### Phase 3: Fetch Latest
-
-Always fetch the latest default branch, regardless of whether a worktree will be created:
-
-```bash
-git fetch origin "$DEFAULT_BRANCH"
-```
-
-This ensures any new branch or worktree starts from the latest codebase.
-
-### Phase 4: Create Worktree
-
-**Naming convention:**
-
-If a name is provided (e.g., from a Linear issue identifier):
-```bash
-git worktree add .worktrees/<name> -b <branch-name> "origin/$DEFAULT_BRANCH"
-```
-
-If no name is provided, generate one from context:
-- If starting a Linear issue: use the issue identifier (e.g., `swe-123`)
-- If the user described the task: use a short slug (e.g., `fix-auth-timeout`)
-- Fallback: use today's date in `YYYY-MM-DD` format
-
-**Ensure `.worktrees/` is gitignored:**
-
-```bash
-# Check if .worktrees is already in .gitignore
-if ! grep -q '\.worktrees' .gitignore 2>/dev/null; then
-  echo '.worktrees/' >> .gitignore
-fi
-```
-
-### Phase 5: Report
-
-After setup, display:
-
-```
-Worktree created at: .worktrees/<name>
-Branch: <branch-name>
-Based on: origin/$DEFAULT_BRANCH (fetched latest)
-
-Previous state preserved:
-  Branch: <original-branch>
-  Changes: <summary of uncommitted changes left behind, if any>
-
-Working directory: .worktrees/<name>
-```
-
-If `--stay` was used:
-
-```
-Staying in current checkout: <branch>
-  (fetched latest origin/$DEFAULT_BRANCH)
-  <summary of uncommitted changes, if any>
-
-To create a new branch:
-  git checkout -b <branch-name> origin/$DEFAULT_BRANCH
-```
-
-## Integration with /start
-
-The `/start` skill always creates a worktree as part of its workflow. Both skills follow the same conventions:
-- Worktrees go in `.worktrees/`
-- Always fetch latest before creating
-- Naming follows the `<identifier>` convention (e.g., `.worktrees/swe-123`)
-
-**Opt-out flags differ by context:**
-- `/worktree --stay` — "stay in current checkout" (you invoked the worktree tool, you're opting out of its action; dirty state is allowed)
-- `/start --no-worktree` — "don't create a worktree" (you're starting new work, skipping one aspect; dirty state causes a hard stop)
-
-This `/worktree` skill can also be invoked independently when you want to isolate work without picking up a Linear issue.
-
-## Error Handling
-
-| Error | Solution |
-|-------|----------|
-| `.worktrees/<name>` already exists | Offer to reuse existing or create with suffix |
-| Branch name already exists | Check out existing branch in the worktree instead of `-b` |
-| No origin remote | Create worktree from local default branch HEAD |
-| Fetch fails | Warn and create from local default branch HEAD |
-| `.gitignore` is read-only | Warn the user to add `.worktrees/` manually |
-
-## Safety Rules
-
-1. **Never discard uncommitted changes** - the whole point is to preserve them
-2. **Never force-checkout** over dirty state - always worktree instead
-3. **Always fetch before creating** - worktrees should start from latest
-4. **This skill only creates worktrees** - it does not remove or clean up stale ones

data/.editorconfig

@@ -1,15 +0,0 @@
-root = true
-
-[*]
-indent_style = space
-indent_size = 2
-end_of_line = lf
-charset = utf-8
-trim_trailing_whitespace = true
-insert_final_newline = true
-
-[*.md]
-trim_trailing_whitespace = false
-
-[Makefile]
-indent_style = tab

data/.rspec

@@ -1,3 +0,0 @@
---format documentation
---color
---require spec_helper

data/.rubocop.yml

@@ -1,8 +0,0 @@
-# Omakase Ruby styling for Rails
-inherit_gem: { rubocop-rails-omakase: rubocop.yml }
-
-# Overwrite or add rules to create your own house style
-
-# Use `[a, [b, c]]` not `[ a, [ b, c ] ]`
-Layout/SpaceInsideArrayLiteralBrackets:
-  EnforcedStyle: no_space

data/.ruby-version

@@ -1 +0,0 @@
-4.0.1

data/AGENTS.md

@@ -1,71 +0,0 @@
-# AGENTS.md - AI Agent Guide for standard_id-google
-
-`standard_id-google` is a provider plugin for the [StandardId](https://github.com/rarebit-one/standard_id) authentication engine. It packages a `StandardId::Providers::Google` implementation for Sign in with Google, and auto-registers itself with the host StandardId installation via a `Rails::Railtie` so apps that bundle the gem don't need an explicit initializer.
-
-## Quick Reference
-
-```bash
-# Run tests
-bundle exec rspec
-
-# Run a single spec file
-bundle exec rspec spec/standard_id/google/providers/google_spec.rb
-
-# Run linting (note: --config flag is required on Ruby 4.0)
-bundle exec rubocop --config .rubocop.yml
-
-# Auto-fix lint issues
-bundle exec rubocop --config .rubocop.yml -A
-```
-
-## Project Structure
-
-```
-standard_id-google/
-├── lib/standard_id/
-│   ├── google.rb                        # Top-level require entrypoint
-│   └── google/
-│       ├── version.rb                   # Gem version constant
-│       ├── railtie.rb                   # Auto-registers provider on after_initialize
-│       └── providers/google.rb          # StandardId::Providers::Google implementation
-└── spec/
-    ├── spec_helper.rb                   # Boots a minimal Rails app so the Railtie fires
-    └── standard_id/                     # Provider specs
-```
-
-## Key Patterns
-
-### Provider class
-
-`StandardId::Providers::Google` inherits from `StandardId::Providers::Base` (defined in the parent `standard_id` gem) and implements the provider contract: `provider_name`, `authorization_url`, `get_user_info`, `config_schema`, plus Google-specific helpers (`verify_id_token`, `fetch_user_info`, code/token exchange via Google's tokeninfo + userinfo endpoints).
-
-### Railtie auto-registration
-
-`StandardId::Google::Railtie` runs on `config.after_initialize` and calls `StandardId::ProviderRegistry.register(:google, StandardId::Providers::Google)`. Host apps just need the gem in their Gemfile — no initializer required.
-
-### Spec bootstrapping
-
-`spec/spec_helper.rb` defines a tiny `Rails::Application` and calls `Rails.application.initialize!` so the Railtie's `after_initialize` hook fires during the spec run; without this the provider would not appear in the registry.
-
-## Key Files
-
-| File | Purpose |
-|------|---------|
-| `lib/standard_id/google.rb` | Top-level require entrypoint |
-| `lib/standard_id/google/railtie.rb` | Provider registration on Rails boot |
-| `lib/standard_id/google/providers/google.rb` | Google provider implementation |
-| `lib/standard_id/google/version.rb` | Gem version constant |
-| `standard_id-google.gemspec` | Gem metadata + runtime deps |
-
-## Dependencies
-
-- **standard_id** `~> 0.1`, `>= 0.1.7` (parent engine — provides `Providers::Base`, `ProviderRegistry`, `HttpClient`, errors)
-- **activesupport** `>= 8.0` (`present?`/`blank?`, indifferent access)
-
-Dev: rspec, rubocop, webmock, lefthook.
-
-## Testing
-
-- WebMock stubs Google's tokeninfo and userinfo endpoints — never make real network calls in specs.
-- The dummy Rails app in `spec_helper.rb` is intentionally minimal; add config via `StandardId.config.google_*` setters in individual specs rather than expanding the dummy app.
-- CI runs the full Ruby 4.0.x patch matrix via the shared `rarebit-one/.github` reusable workflow.

data/CLAUDE.md

@@ -1,26 +0,0 @@
-# CLAUDE.md
-
-## Worktree-Only Workflow (Enforced)
-
-**All file modifications are blocked in the main checkout.** A PreToolUse hook (`enforce-worktree.sh`) rejects Edit, Write, and NotebookEdit operations targeting files outside a worktree. There are no opt-outs. Do not use Bash to write files in the main checkout either (e.g., `echo >`, `sed -i`, `tee`, `cp`) — the hook cannot intercept shell commands, so this rule is instruction-enforced.
-
-Before writing any code, create a worktree:
-
-```bash
-DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@refs/remotes/origin/@@')
-DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
-git fetch origin "$DEFAULT_BRANCH"
-git worktree add .worktrees/<name> -b <branch-name> "origin/$DEFAULT_BRANCH"
-```
-
-Then work inside `.worktrees/<name>/` for the rest of the session.
-
-**Naming:** Use the Linear issue identifier if available (e.g., `.worktrees/<identifier>`), a task slug (e.g., `.worktrees/fix-auth-timeout`), or today's date (e.g., `.worktrees/2026-04-01`) as fallback.
-
-**The hook allows modifications only when:**
-
-1. The file is inside a git worktree (detected via `git rev-parse --git-dir` returning a path under `.git/worktrees/`)
-2. Running in a CI/automated context where the checkout is already isolated
-**Why this matters:** Working directly on the main checkout causes cross-contamination between sessions — uncommitted changes, wrong branches, and dirty state leak into unrelated work. Worktrees eliminate this entirely.
-
-See the `/worktree` and `/start` skills for full conventions and flags.

data/CODE_OF_CONDUCT.md

@@ -1,132 +0,0 @@
-# Contributor Covenant Code of Conduct
-
-## Our Pledge
-
-We as members, contributors, and leaders pledge to make participation in our
-community a harassment-free experience for everyone, regardless of age, body
-size, visible or invisible disability, ethnicity, sex characteristics, gender
-identity and expression, level of experience, education, socio-economic status,
-nationality, personal appearance, race, caste, color, religion, or sexual
-identity and orientation.
-
-We pledge to act and interact in ways that contribute to an open, welcoming,
-diverse, inclusive, and healthy community.
-
-## Our Standards
-
-Examples of behavior that contributes to a positive environment for our
-community include:
-
-* Demonstrating empathy and kindness toward other people
-* Being respectful of differing opinions, viewpoints, and experiences
-* Giving and gracefully accepting constructive feedback
-* Accepting responsibility and apologizing to those affected by our mistakes,
-  and learning from the experience
-* Focusing on what is best not just for us as individuals, but for the overall
-  community
-
-Examples of unacceptable behavior include:
-
-* The use of sexualized language or imagery, and sexual attention or advances of
-  any kind
-* Trolling, insulting or derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or email address,
-  without their explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
-
-## Enforcement Responsibilities
-
-Community leaders are responsible for clarifying and enforcing our standards of
-acceptable behavior and will take appropriate and fair corrective action in
-response to any behavior that they deem inappropriate, threatening, offensive,
-or harmful.
-
-Community leaders have the right and responsibility to remove, edit, or reject
-comments, commits, code, wiki edits, issues, and other contributions that are
-not aligned to this Code of Conduct, and will communicate reasons for moderation
-decisions when appropriate.
-
-## Scope
-
-This Code of Conduct applies within all community spaces, and also applies when
-an individual is officially representing the community in public spaces.
-Examples of representing our community include using an official email address,
-posting via an official social media account, or acting as an appointed
-representative at an online or offline event.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported to the community leaders responsible for enforcement at
-[INSERT CONTACT METHOD].
-All complaints will be reviewed and investigated promptly and fairly.
-
-All community leaders are obligated to respect the privacy and security of the
-reporter of any incident.
-
-## Enforcement Guidelines
-
-Community leaders will follow these Community Impact Guidelines in determining
-the consequences for any action they deem in violation of this Code of Conduct:
-
-### 1. Correction
-
-**Community Impact**: Use of inappropriate language or other behavior deemed
-unprofessional or unwelcome in the community.
-
-**Consequence**: A private, written warning from community leaders, providing
-clarity around the nature of the violation and an explanation of why the
-behavior was inappropriate. A public apology may be requested.
-
-### 2. Warning
-
-**Community Impact**: A violation through a single incident or series of
-actions.
-
-**Consequence**: A warning with consequences for continued behavior. No
-interaction with the people involved, including unsolicited interaction with
-those enforcing the Code of Conduct, for a specified period of time. This
-includes avoiding interactions in community spaces as well as external channels
-like social media. Violating these terms may lead to a temporary or permanent
-ban.
-
-### 3. Temporary Ban
-
-**Community Impact**: A serious violation of community standards, including
-sustained inappropriate behavior.
-
-**Consequence**: A temporary ban from any sort of interaction or public
-communication with the community for a specified period of time. No public or
-private interaction with the people involved, including unsolicited interaction
-with those enforcing the Code of Conduct, is allowed during this period.
-Violating these terms may lead to a permanent ban.
-
-### 4. Permanent Ban
-
-**Community Impact**: Demonstrating a pattern of violation of community
-standards, including sustained inappropriate behavior, harassment of an
-individual, or aggression toward or disparagement of classes of individuals.
-
-**Consequence**: A permanent ban from any sort of public interaction within the
-community.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage],
-version 2.1, available at
-[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
-
-Community Impact Guidelines were inspired by
-[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
-
-For answers to common questions about this code of conduct, see the FAQ at
-[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
-[https://www.contributor-covenant.org/translations][translations].
-
-[homepage]: https://www.contributor-covenant.org
-[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
-[Mozilla CoC]: https://github.com/mozilla/diversity
-[FAQ]: https://www.contributor-covenant.org/faq
-[translations]: https://www.contributor-covenant.org/translations