Bump rails-ai-context from 5.24.0 to 5.26.0

[dependabot]

Bumps rails-ai-context from 5.24.0 to 5.26.0.

Release notes

Sourced from rails-ai-context's releases.

v5.26.0

Added

• docs/RELEASING.md. Every release rediscovered the same list by reading the release workflow: the changelog heading the notes are extracted from, the two files carrying the version, and the end-to-end run the gate wants against the exact commit before a tag will publish. Its first step picks the version from the Changed section, which nothing downstream checks. CONTRIBUTING.md points at it.

Fixed

Defects found by a ninth QA round of v5.25.0 against Mastodon (issues #160 to #181), the sibling defects behind them, and what nine review rounds and repeated from-scratch verification found in the fixes themselves. Most of the entries below are older than the twenty-two reports; the reports are where the looking started. One entry is a consumer-visible key rename and is under Changed.

• excluded_association_names was ignored everywhere except the booted ActiveRecord path. The key had one call site, inside the reflection-only association extractor, so a --no-boot answer and every Mongoid answer listed the associations the config asked to hide, with nothing saying the key had been skipped. One predicate now reads the key for all three builders, comparing the name as text because the listener names an association with a Symbol and reflection with a String.
• The static model builder dropped every attribute macro it parsed. static_model_details assembled its hash by hand and passed the listener's raw records straight through, so encrypts, normalizes, serialize, store, attachments and delegations vanished from get_env, get_schema, onboard and get_model_details with no marker, and the enums key carried records where consumers destructure an attribute-to-values Hash. It merges the same two mappers the booted builder merges, builds enums in the booted shape with String keys on both levels, and derives custom_validates. The encryption and normalizes renderers read keys the builder never emitted and printed - **** ...; they read field and transformation now, and a transformation the parser could not resolve is marked rather than named. Options are spelled as key: value pairs, so the line reads the same on every Ruby, and a plain encrypts with no options prints the attribute alone.
• A callback declared as an anonymous block was listed as a callback named do, and the two tools that list one did not agree. The word the declaration line is composed from was reused wherever the tools print a comma list of callback target names, so after_create do ... end read as a method called do in the callbacks listing, in the model details and in the feature analysis. A block is listed by the payload's own [inline_block] marker now, the same marker in all three. The concern declaration lines still read after_create do, because that is what the file says, and generate_test names one "runs its inline block" rather than writing the marker into an

... (truncated)

Changelog

Sourced from rails-ai-context's changelog.

[5.26.0] - 2026-09-11

Added

• docs/RELEASING.md. Every release rediscovered the same list by reading the release workflow: the changelog heading the notes are extracted from, the two files carrying the version, and the end-to-end run the gate wants against the exact commit before a tag will publish. Its first step picks the version from the Changed section, which nothing downstream checks. CONTRIBUTING.md points at it.

Fixed

Defects found by a ninth QA round of v5.25.0 against Mastodon (issues #160 to #181), the sibling defects behind them, and what nine review rounds and repeated from-scratch verification found in the fixes themselves. Most of the entries below are older than the twenty-two reports; the reports are where the looking started. One entry is a consumer-visible key rename and is under Changed.

• excluded_association_names was ignored everywhere except the booted ActiveRecord path. The key had one call site, inside the reflection-only association extractor, so a --no-boot answer and every Mongoid answer listed the associations the config asked to hide, with nothing saying the key had been skipped. One predicate now reads the key for all three builders, comparing the name as text because the listener names an association with a Symbol and reflection with a String.
• The static model builder dropped every attribute macro it parsed. static_model_details assembled its hash by hand and passed the listener's raw records straight through, so encrypts, normalizes, serialize, store, attachments and delegations vanished from get_env, get_schema, onboard and get_model_details with no marker, and the enums key carried records where consumers destructure an attribute-to-values Hash. It merges the same two mappers the booted builder merges, builds enums in the booted shape with String keys on both levels, and derives custom_validates. The encryption and normalizes renderers read keys the builder never emitted and printed - **** ...; they read field and transformation now, and a transformation the parser could not resolve is marked rather than named. Options are spelled as key: value pairs, so the line reads the same on every Ruby, and a plain encrypts with no options prints the attribute alone.
• A callback declared as an anonymous block was listed as a callback named do, and the two tools that list one did not agree. The word the declaration line is composed from was reused wherever the tools print a comma list of callback target names, so after_create do ... end read as a method called do in the callbacks listing, in the model details and in the feature analysis. A block is listed by the payload's own [inline_block] marker now, the same marker in all three. The concern declaration lines still read after_create do, because that is what the file says, and generate_test names one "runs its inline block" rather than writing the marker into an

... (truncated)

Commits

• 9eabf16 Merge pull request #182 from crisnahine/worktree-qa-round-nine
• 416d354 the test bundle pins json below 3 where Rails cannot encode against it
• cc8bfae release: v5.26.0 - twenty-two Mastodon defects, and what twelve review rounds...
• c9733fa the abstract check and the parity example say what they pin
• 0c1ae8e one source line read twice is one declaration
• 09fd110 the order of the base chain is pinned, and the parity example names its answer
• 95f1c2a what the twelfth round found in the wider walk
• c6f3f94 a base the walk could not read is a gap its children state
• 423d43d a model inherits what its superclasses declare, abstract ones included
• 9a1089f what the eleventh round found in the tenth round's fixes
• Additional commits viewable in compare view

[mmeest]

@dependabot recreate

[mmeest]

This PR does more than bump mission_control-jobs 1.2.0 → 1.3.1. The lockfile also upgrades json from 2.21.2 to 3.0.2 (a major). Rails 8.1 still calls JSON.parse / JSON.generate with a second options argument, and json 3.0 rejects that (ArgumentError: wrong number of arguments (given 2, expected 1)).

That shows up anywhere JSON is used: jsonb columns (TestAttempt#vars, PracticalTask#validator), create!, and even flash[:alert] = …. CI currently reports 222 failures from that, not from mission_control-jobs itself.

Next step is either pinning json to ~> 2.21 and re-resolving, or bumping mission_control-jobs without taking json 3. We can merge once tests pass without the JSON 3 major.

Same as PR: #201