Rule is a mutable dataclass, so an already-registered rule's priority
could change after being added; the dedup early-return skipped the
priority re-sort, so re-adding a rule after mutating its priority
left self.rules stale relative to that change. The duplicate branch
now re-sorts before returning, matching the append path.
- add_rule()'s duplicate-skip path now logs at warning level instead
of debug, so a skipped duplicate is visible by default rather than
silent in typical logging configs
- The duplicate-rule log message now stringifies conditions via
map(str, ...) before joining, since Rule.conditions is List[Any]
and non-string entries would otherwise raise TypeError
add_rule() unconditionally appended to self.rules, so re-running the
same setup code on an existing Reasoner instance (e.g. re-executing a
Jupyter cell) duplicated every rule; forward_chain() would then match
the duplicated rules but silently return no new results since the
conclusions were already in self.facts, with no error or warning.
add_rule() now compares an incoming rule's rule_type, conditions, and
conclusion against existing rules and returns the existing Rule
instead of appending a duplicate, keeping repeated add_rule() calls
with the same definition idempotent.
Bug 1 — _parse_relation_result (methods.py):
Relations whose subject/object weren't in the pre-extracted NER list were
silently dropped because match_entity() returned None and the old code
gated on `if subject_entity and object_entity`. Now unmatched names
produce a synthetic UNKNOWN Entity so every LLM-returned relation is
preserved (all three Apple co-founders are now returned).
Bug 2 — _match_pattern (reasoner.py):
Rewrote the regex builder to split on ?var placeholders first, then
apply re.escape() only to the surrounding literal segments. The old
approach (escape-then-sub) left edge cases where pre-bound variables
and multi-word values with spaces could fail to unify. The new
implementation also handles repeated variables via backreferences and
uses non-greedy .+? to avoid over-consuming literal separators.
Closes#354
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sameer6305