# Keep the build context small. NOTE: .git is intentionally NOT ignored —
# okf.gemspec builds spec.files from `git ls-files`, so the build stage needs it.
#
# LOAD-BEARING, and one-directional: anything excluded here from under gems/okf/
# must ALSO be rejected by the gemspec (or be gitignored). `git ls-files` reads the
# index, so a path dropped from the context is still listed in spec.files — and
# `gem build` then fails on a file that is not there.
#
# The converse is NOT true, and must not be "restored" for symmetry: the gemspec
# also rejects gems/okf/bin, gems/okf/Gemfile, gems/okf/Rakefile and
# gems/okf/.gitignore, which stay in the context deliberately. Handing the builder
# a file the gem does not carry costs nothing; the reverse breaks the build.
#
# Paths outside gems/okf/ (the ROOT .okf, plugin/, .github…) need no pairing at
# all: the gemspec runs `git ls-files` with chdir into gems/okf/ and never sees
# them. They are here only to keep the context small.
#
# Read the `.okf` entry below as exactly what it says: Docker anchors a pattern
# with no `**` at the context root, so it drops the repository's own bundle and
# leaves `gems/okf/.okf` alone. That is deliberate — the kernel's bundle ships
# inside the gem, as the three siblings' do, so excluding it here would break
# `gem build` on a file `git ls-files` still lists.
node_modules
tmp
*.gem
.ruby-lsp
.DS_Store

# Repo-level — invisible to the gemspec. `coverage` and `pkg` are the repo root's
# own: Docker patterns anchor at the context root and `*` does not cross `/`, so
# the `*.gem` above never covered `pkg/*.gem`.
.claude
.claude-plugin
.okf
.github
plugin
skills
coverage
pkg

# Under gems/okf/ — each of these is also in okf.gemspec's reject list. See above.
gems/okf/test
gems/okf/coverage
gems/okf/pkg
gems/okf/.rubocop.yml
