Conversation
…ies (boostorg#103) * policies: add minimal_perfect_hash, two_level_hash and minimal_cover_hash Three new type_hash policies, from the research for boostorg#57. fast_perfect_hash stays the default: none of these beats it as a general v-table lookup. What they offer is a way out of its one real failure mode - its randomized search costs tens to hundreds of milliseconds on a sparse type id set and gives up outright on a large one, and the table it finds is sized by where the addresses are rather than by how many there are. minimal_perfect_hash (boostorg#56) is hash-and-displace: one slot per type id whatever the addresses are, a search whose cost depends only on the class count, and no instruction-set requirement. It pays with a second dependent load on the dispatch path. It is the one to reach for in a program that dlopens modules registering classes of their own. two_level_hash is the same family with the final reduction replaced by a shift into a power-of-two table: cheaper per dispatch where the compiler hoists the shift amount, at the cost of a table that is a sawtooth between 1.0 and 2.0 slots per type id rather than a flat figure. minimal_cover_hash picks the smallest set of bit positions that still separates the type ids and extracts them with pext. It dispatches as fast as the default and finds its table deterministically, but BMI2 is not a portable requirement, so the header always compiles and naming the policy in a registry is what fails when the instruction is unavailable - with a diagnostic that names both the flag and the portable alternative. Four changes from the prototypes, beyond namespace and naming: - detail::uintptr moves from fast_perfect_hash.hpp to preamble.hpp. Every type_hash policy needs it; only one of them had it. - minimal_perfect_hash and two_level_hash hash `x + 1`. Zero is a fixed point of a multiply, so a type id of 0 would be pinned to slot 0 for every seed and every pilot and the search could fail spuriously. One increment on the dispatch path buys a policy that works for any type id, including the small integers a custom rtti policy may hand out. - two_level_hash drops the M1Candidates knob: scoring first-level multipliers for even buckets was measured and does not pay, because the placement cost is set by the tail, where every remaining bucket faces an almost full table. Its table cap is now relative to the class count rather than an absolute 2^26, which could ask for half a gigabyte. - aux_bytes() is gone from both. It is not part of the TypeHashFn contract; it existed so a benchmark could report the pilot array size. finalize() now releases that array, which the prototypes leaked until the registry died. Docs and tests follow. * policies: rule a zero type id out rather than hashing around it minimal_perfect_hash and two_level_hash hashed `x + 1` so that a type id of zero could not be pinned to slot 0. That put an increment on every dispatch to buy something no caller needs: addresses are never zero, so std_rtti and static_rtti could never hit it, and a custom rtti policy handing out small integers can simply not start at zero. So make it a precondition instead. Both policies hash the type id directly again, both document zero as outside their domain, and `initialize` asserts that none of the registered ids is zero when the registry has runtime_checks - one comparison, since the ids are sorted by then, and compiled out entirely otherwise. The dispatch path is back to imul/shr/load/imul/mul/load, with nothing in front of the first multiply. * test: cover the three new type_hash policies Four new files, and the first tests in the suite to drive a type_hash policy directly rather than through dispatch. test_hash_policies.cpp feeds each policy a fabricated InitializeContext over chosen type ids, which is the only way to present a distribution deliberately instead of taking whatever this program's own classes happen to get. Four distributions: one packed module, one diluted module (v-tables emitted between the records, which is what a real one looks like), a program with implicitly linked libraries, and a program plus dlopened modules tens of terabytes apart. It asserts injectivity and that hash_range brackets every value on all of them, that the table size is identical for the packed and the dlopened sets - the property this family of policies exists for - that minimal_perfect_hash<2, 100> is exactly minimal and the default is ceil(n / 0.95), that two_level_hash's table is a power of two between n and 2n, that a type id registered by several modules is not a collision, and that initialize works again after finalize. The generators keep a per-module cursor so the ids are distinct by construction, and a test case asserts that much: a repeated id would exercise the policies' deduplication rather than their hashing, and would make every injectivity count come out short for no fault of the policy. Getting that wrong the first time is what caught it. test_dispatch_{minimal_perfect,two_level,minimal_cover}_hash.cpp run each policy end to end - single and multiple dispatch over a five-class hierarchy - with runtime_checks on unconditionally rather than only in a Debug build, so the control table that `hash` consults is exercised in both configurations, and with throw_error_handler so that a call passing an unregistered class is observable as missing_class instead of aborting. The minimal_cover_hash test needs BMI2 for the whole translation unit, which the CMake build adds for that one target on x86, and which b2 gets from a new config//has_bmi2 probe - the same shape as the existing has_reflection one. Probing beats naming an architecture: an <architecture>x86 conditional does not match every toolset spelling. Where the instruction is absent the test still builds, as one case that records why it did nothing. test_policies.cpp gains static_asserts that each new policy satisfies the TypeHashFn blueprint, and that `with` replaces a type_hash policy in place rather than appending a second - which would leave vptr_vector reading the wrong state. * doc: document the three policies, and the dlopen situation they address The tutorial explained dlopen without ever saying what is different about it for type ids, which is the thing that decides whether the default hash policy copes. A new section of shared_libraries.adoc, "Type Ids Across Modules", fills that in: that a type id is `&typeid(X)`; that the Itanium ABI requires pointer identity across modules and the linker delivers it for an implicitly linked library with a copy relocation, so a program and the libraries it links against present one compact set of ids; that dlopen gets none of that, because nothing names a plugin's classes, so its records stay in its own mapping wherever the loader put it; and that RTTI has to keep default visibility for any of it to work, which is why the library's own tests mark their classes BOOST_SYMBOL_VISIBLE. None of that was written down anywhere outside a comment in test/dynamic_loading/classes.hpp. Then what it costs - fast_perfect_hash searching over several far-apart clusters, and vptr_vector sizing its table from the result - and the four ways out, as a table: the three new policies and vptr_map, which sidesteps the question by not hashing at all. Each with the one declaration that selects it, and a note that `with` replaces by category in place, so the ordering rule elsewhere on the page is not something a caller has to think about. Also: three entries in ref_headers.adoc; a paragraph in registries_and_policies.adoc saying there are four type_hash policies and what the other three are for; a forward reference in performance.adoc, whose figures are fast_perfect_hash's specifically; and three tagged snippets in snippets/policies.cpp, which is compiled and run as a test, so the examples in the reference cannot rot. Two fixes the rendered output turned up, neither visible in the source: - `@ref minimal_perfect_hash:` had its colon absorbed into the reference name, so the sentence rendered as "...as in `minimal_perfect_hash` zero is a fixed point...". A colon is valid in a qualified name, so the parser takes it. Reworded to end the sentence with a period instead. Note that five shipped headers have the same construct and lose their colons the same way - initialize.hpp's `@li @ref missing_class:` among them - which is left alone here. - BOOST_OPENMETHOD_HAS_PEXT got no reference page, because its doc comment was separated from both `#define` directives by the `#if` that chooses between them, and a comment on the far side of a directive is not attached. Every @ref to it therefore rendered as plain text. The detection now sets an internal macro and the documented one is a single unconditional `#define` with the comment attached to it. Verified by rendering, not by reading: every @ref in the three new headers resolves to a link, the new section's table and both code blocks render, the three cross-references into its anchor resolve, no page leaks MRDOCS, and no stray backticks survive on any of the four edited pages. * fix: two things CI found that a 64-bit build could not **minimal_cover_hash's static_assert fired at parse time on GCC 11 and 12, and Clang 13 through 15.** A static_assert whose condition does not depend on the enclosing template may be diagnosed as soon as the template is *defined* rather than when it is instantiated - the standard calls such a template ill-formed, no diagnostic required, and compilers differ on when they report it. The condition was BOOST_OPENMETHOD_HAS_PEXT, a plain 0 or 1, so on those compilers merely *including* the header was an error when the instruction was unavailable, which is the one thing the header promises not to do. It now goes through detail::has_pext<Registry>, a variable template, so the condition is dependent and the check happens on use. Not reproducible here: the oldest local compiler is GCC 13, which defers, and no container runtime is available. Verified instead that including the header is clean on GCC 13, 15 and 16 and Clang 22, that naming the policy in a registry still fails with the same diagnostic, and that it still works under -mbmi2. **test_hash_policies fabricated 64-bit addresses**, so on a 32-bit target reinterpret_cast to type_id truncated them. The multi_module bases differ only in their high bits, so all four collapsed onto one another and the generator emitted duplicates - 988 distinct ids out of 1000. The bases are now derived from sizeof(uintptr_t), with a `spread` parameter saying how far apart the modules sit, so the same layout holds at either width. The fixture's own generators_produce_distinct_ids case caught this first in CI and pointed straight at the cause, which is what it is there for. Reproduced locally with -m32 - the old file fails with exactly CI's [16 != 17] and [988 != 1000], the new one passes at both widths. 164 tests pass in Release and Debug. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JqH1U2Ky7ubqKzqSvgxY9y * fix: the two Windows failures, both verified on the compilers that found them **_pext_u64 does not exist in 32-bit mode.** The feature test accepted any x86 target - `_M_IX86` on MSVC, or `__BMI2__` on a `-m32` GCC build - so on 32-bit x86 the header set BOOST_OPENMETHOD_HAS_PEXT to 1 and then reached for an intrinsic that is not declared there: `_pext_u32` is the widest one 32-bit mode has. That took out MSVC x86_32, MINGW32 and the 32-bit half of clang-win. The guard now requires x86-*64* on both compilers, and the documentation, the CMake matcher and the warning in the policy's docs say 64-bit where they said x86. **two_level_hash used std::partial_sum and std::iota without <numeric>.** It built everywhere I had tried because libstdc++ and libc++ pull the header in transitively; MSVC's STL at /std:c++latest does not, so the failure appeared only in that column - on ARM64 as well as x86, which is what made it look like a second architecture problem rather than a missing include. An audit of all three new headers for the same class of defect turned up nothing else. Both reproduced before fixing and re-checked after, on the toolchains that reported them rather than by inference: - 32-bit: the old header gives `_pext_u64 was not declared in this scope` under `g++ -m32 -mbmi2`; the new one compiles, with HAS_PEXT 0 at 32 bits and 1 at 64. - MSVC 18 at /std:c++latest: the old header gives exactly CI's C2039 pair, `'partial_sum': is not a member of 'std'` at line 235 and `'iota'` at 246; the new one compiles. minimal_cover_hash and two_level_hash now both compile under vcvars64 and vcvars32. 164 tests pass in Release and Debug, and the new tests still pass on gcc 11.5. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JqH1U2Ky7ubqKzqSvgxY9y * fix: MSVC's unreachable-code warning, and clang-cl's pext guard MSVC C4702 in the three new policy headers. The `abort()` after a call to the error handler is dead code when the handler is [[noreturn]], as throw_error_handler is, and /W4 /WX turns that into an error. The library already answers this with a per-header `#pragma warning(push/disable: 4702/pop)` - preamble.hpp, core.hpp and initialize.hpp all carry one - and these three were missing it. Only the cover-hash test failed, which made the warning look specific to that policy. It is not: fast_perfect_hash.hpp pushes the same disable and never pops it, so from the first include of <boost/openmethod.hpp> the warning is off for the rest of the translation unit. The cover-hash test has to include its policy header *before* that, to read BOOST_OPENMETHOD_HAS_PEXT before the registry override; the other two include theirs after, and were covered by the leak. A push/pop pair in each header makes it self-sufficient whatever the include order. clang-cl and `_pext_u64`. clang-cl defines _MSC_VER and _M_X64, so the MSVC arm of the BMI2 guard claimed the intrinsic on a compiler that gates it on the `bmi2` target feature - "always_inline function '_pext_u64' requires target feature 'bmi2'", which is exactly the error the guard exists to prevent. It now excludes clang, so clang-cl falls to the __BMI2__ arm where it belongs. test_hash_policies.cpp names the policy too, and was getting no BMI2 flag from either build file - the reason clang-win was the job that found this. It now gets the same treatment as test_dispatch_minimal_cover_hash.cpp. Which also means its cover-hash cases, compiled out everywhere but MSVC until now, run on gcc and clang as well. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NTCobjuUoBUHHPb1jVShyq * fix: keep the BMI2 tests off the shared PCH test_hash_policies.cpp does not override the default registry, so it was reusing the shared PCH - which is compiled without the BMI2 flag. GCC warns for every such file ("created and used with differing settings of '-mbmi2'", -Winvalid-pch) and MSVC rejects a PCH built with a different /arch outright. test_dispatch_minimal_cover_hash.cpp never hit this: it overrides the registry, which already excludes it from the PCH. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NTCobjuUoBUHHPb1jVShyq * fix: balance fast_perfect_hash's warning push, and give the vptr policies theirs fast_perfect_hash.hpp has pushed a `disable: 4702` since it was written and never popped it, so on MSVC the warning stays off for everything included after it - which, since default_registry names the policy, is most of a translation unit. That is what hid the missing pragma in the three new hash policy headers until a test that had to include one *before* <boost/openmethod.hpp> found it. With the pop in place the warning comes back where it always applied, at vptr_map.hpp's `abort()`; vptr_vector.hpp has the same construct and gets the same treatment, so that neither depends on who was included first. Verified with MSVC 14.5: all 63 test_*.cpp compile clean at /W4 /WX, as do two throwaway sources that instantiate every one of these policies against throw_error_handler - which is the [[noreturn]] handler that makes the `abort()` dead code in the first place. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NTCobjuUoBUHHPb1jVShyq --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…oostorg#110) * interop: add weak_virtual_ptr for std::weak_ptr Closes boostorg#73. Add <boost/openmethod/interop/std_weak_ptr.hpp>, providing weak_virtual_ptr<Class>, an alias for virtual_ptr<std::weak_ptr<Class>>. It tracks an object with a std::weak_ptr and remembers its v-table pointer, so that lock() returns a shared_virtual_ptr without a hash table lookup. Remembering the vptr is safe: the weak pointer keeps the control block alive, so once the object is destroyed it stays expired for good. It is a storage facility only. It is constructed from a shared_virtual_ptr (or a std::shared_ptr or std::weak_ptr), converts to a weak_virtual_ptr to a base class, and offers lock(), expired(), use_count(), reset(), pointer() and vptr(). It cannot be dereferenced, and it cannot be used as a virtual parameter - neither as virtual_<std::weak_ptr<T>> nor as weak_virtual_ptr<T> - because the object may no longer exist; validate_method_parameter specializations reject both with "a weak pointer cannot be a virtual parameter; call lock() first". std::weak_ptr does not fit the generic smart-pointer specialization of virtual_ptr, which needs get(), operator* and a conversion to bool, so the specialization is written by hand. virtual_traits is deliberately not specialized for std::weak_ptr: that keeps IsSmartPtr false, which is what lets the hand-written specialization win. In core.hpp, the plain virtual_ptr's converting constructor and assignment from another virtual_ptr now also require the source to have get() (detail::has_get), so a weak source is a clean substitution failure instead of a hard error in the body, and is_constructible reports it correctly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test: use namespace-scope overriders in the weak_virtual_ptr dispatch test The dispatch test registered the static member functions of a local class as override<> template arguments. That is valid C++17, but gcc before 13 rejects it ("has no linkage"), failing the gcc-10/11/12 and Cygwin 32-bit jobs. Use namespace-scope function templates instead, as test_util.hpp's poke_bear does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * interop: make weak_virtual_ptr a class of its own As a partial specialization of virtual_ptr, weak_virtual_ptr matched everything written for virtual_ptr: is_virtual, so it could not be an ordinary non-virtual method parameter; the converting constructors of the plain virtual_ptr, hence the has_get gate in core.hpp; the free operator==, which then failed inside core.hpp; final_virtual_ptr; and a user virtual_traits<std::weak_ptr> made it ambiguous. A weak pointer is not a virtual_ptr - it cannot be dereferenced or dispatched on - so model it as a class of its own, with the same members. What it needs from a shared virtual_ptr has no public route: the boxed v-table pointer, which under indirect_vptr is the address of the cell that initialize() rewrites and which vptr() unboxes away, and the constructor that takes a v-table pointer, so that lock() skips the lookup. core.hpp therefore gains detail::virtual_ptr_access, a generic door to those two things, befriended by both virtual_ptr specializations; weak_virtual_ptr uses it to copy the pointer from a shared virtual_ptr and hand it back in lock(). core names no client class: the next adaptor - boost::weak_ptr - uses the same door. Fold in the review's findings on the way. Move constructors and assignments are noexcept, so containers relocate by moving. Construction from a std::weak_ptr to another class locks it once, not twice, and an expired source is copied as is, so that it keeps its control block as far as the standard library allows - libstdc++ shares ownership with a source that is expired but not empty, as [util.smartptr.weak.const] requires; libc++ locks first, so there an expired source of a different class yields an empty weak pointer. owner_before and swap support the owner-keyed containers a cache of weak pointers is built on - with a comparator of one's own, since std::owner_less<void> is generic only in libstdc++; MSVC's and libc++'s accept std::shared_ptr and std::weak_ptr alone. The "call lock() first" diagnostic now fires for every form of a weak virtual parameter - value, &, const& and && - and for virtual_<weak_virtual_ptr<T>>; a bare weak_virtual_ptr<T> parameter is valid. A virtual_ptr<std::weak_ptr<T>>, which is what final_virtual_ptr(std::weak_ptr) would build, is rejected with "use weak_virtual_ptr", unless virtual_traits is specialized for std::weak_ptr. The doc comment says what a remembered v-table pointer is safe against, and what it is not: a second initialize(), unless the registry uses indirect_vptr. Like the smart pointer aliases, weak_virtual_ptr defaults its registry to the affinity its class declares, so that it agrees with the shared_virtual_ptr it converts to and from. The compile-fail markers no longer contain a `;`: PASS_REGULAR_EXPRESSION is a CMake list, so it split each regex into two alternatives, and a test passed on either half. The CMake loop now refuses such a marker. Docs: the Weak Pointers section no longer swallows the unique_ptr AST example, describes a class rather than an alias, and ref_headers.adoc no longer lists the header under "use in virtual parameters". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018FzFtVWNk6d4Wut5SboCZC --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…g#116) boostorg#113 gave `virtual_` a registry parameter, so that a method can be declared without naming a registry and a parameter can name one. The `validate_method_parameter` specializations in the `any` and type_erasure interop headers were left spelling `virtual_<T>`, which after the change matches only the defaulted second argument. A method declared `virtual_<const std::any&, R>` - valid, and what the registry affinity machinery produces when a parameter names its registry - fell through to the primary template instead: error: virtual_<> parameter is not a polymorphic class and no boost_openmethod_vptr is applicable Give the registry `virtual_` carries its own template parameter, as the specializations in core.hpp do. The rejecting one, for an owning `type_erasure::any` passed by value, is fixed the same way, so that it keeps reporting "an owning type_erasure::any must be passed by reference" rather than the vague message above. The three dispatch tests assert the accepting spellings, in each form the header covers. Claude-Session: https://claude.ai/code/session_018FzFtVWNk6d4Wut5SboCZC Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both were falsified by changes that did not update the prose around them. boostorg#113 collapsed the "Two things deliberately do not participate" bullets into one sentence, because `use_classes` had just started participating - but then named two things under "One thing": the interop headers and the C++26 `register_classes`. Restore the bullet form for the two that are left. The same sentence says the `any` and `type_erasure` interop headers "are untouched". boostorg#116 touched all three of them, and had to: boostorg#113 gave `virtual_` a registry parameter, and their `validate_method_parameter` specializations still spelled `virtual_<T>`, which after the change matches only the defaulted argument. What survives is the affinity claim, which is the point of the paragraph - a `virtual_any` contributes none. Say that, and record why a specialization there cannot go back to the bare spelling. The PCH paragraph names `test_capture_errors.hpp` as the only header that carries the override on a test's behalf. `test/CMakeLists.txt` has scanned for `test_checked_registry.hpp` as well since boostorg#93; the sentence three lines above, "do not add a fourth marker", already counts three. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
An automated preview of the documentation is available at https://118.openmethod.prtest3.cppalliance.org/libs/openmethod/doc/html/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-09-17 23:47:42 UTC |
boostorg#103 merged 415 files of b2 output - 613 MiB expanded, 94 MiB in the pack, on a repository of about 3 MB - days after boostorg#108 added the `bin/` ignore rule intended to prevent it. The branch was cut before that rule landed, and an ignore rule does not apply to a path that is already tracked, so the merge carried them in. Nothing in the build or the review catches this, and boostorg#117 could only untrack them: the superproject pins this library by SHA and its bot bumps the pin within minutes of every merge, so rewriting `develop` orphans commits `boostorg/boost` already points at - and would not even remove the blobs, which stay reachable through `refs/pull/<n>/head`. Write the rule down where the workflow is: stage named paths, never `git add <dir>`, and ask before committing a build artefact or any file over 1MB. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
jll63
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(Written by Claude Code, on behalf of @jll63.)
CLAUDE.mdonly; no code, no tests.A rule against committing build output
#103 merged 415 files of b2 output - 613 MiB expanded, 94 MiB in the pack, on a
repository of about 3 MB - days after #108 added the
bin/ignore rule intendedto prevent it. The branch was cut before that rule landed, and an ignore rule has
no effect on a path that is already tracked, so the merge carried them in.
Nothing in the build or in review catches this, and #117 can only untrack them.
A rewrite of
developis not available as a remedy: the superproject pins thislibrary by SHA and its bot bumps the pin within minutes of every merge, so
rewriting orphans commits
boostorg/boostalready points at; and the blobs stayreachable through
refs/pull/<n>/head, which a maintainer cannot delete. So therule goes next to the workflow it belongs to - stage named paths, never
git add <dir>, and ask before committing a build artefact or any file over 1MB.Two stale notes in the registry-affinity section
"One thing deliberately does not participate", followed by two things. #113
collapsed the original
Two things ... and both are documented as such:bulletsinto a single sentence, because
use_classeshad just started participating - butthe sentence goes on to name both the interop headers and the C++26
register_classes. Restored to bullets for the two that are left."the
anyandtype_erasureinterop headers are untouched". #116 touched allthree of them, and had to: #113 gave
virtual_a registry parameter, and theirvalidate_method_parameterspecializations still spelledvirtual_<T>, whichafter that change matches only the defaulted argument. The affinity claim - the
actual point of the paragraph - does survive, so the note now says that a
virtual_anycontributes no affinity, separates it from a parameter spelling aregistry, and records why a specialization there cannot go back to the bare
spelling.
The PCH paragraph names one override-carrying header; the scan looks for two.
test/CMakeLists.txthas scanned fortest_checked_registry.hppalongsidetest_capture_errors.hppsince #93. The sentence three lines above it, "do not adda fourth marker", already counts three markers, so only the enumeration was stale.
🤖 Generated with Claude Code