Context: aggregate sharded sources by kind so they surface to the agent (0.5.5)#51
Merged
Merged
Conversation
A "kind" (bug_registry, anti_patterns, db_impact_map, …) can be backed
by more than one doc. Large projects keep the canonical entry as a thin
index stub and put the real content in per-domain shards registered
under sources.extra with the same kind (bug-registry-{agents,infra,
orchestrator}.md, db-impact-map-{master,tenant,vector}.md, etc.).
The Context accessors read only the single canonically-named source
(self.sources.get("bug_registry")), so every shard's parsed content sat
in the cache + pointer cards but never reached the context the agent
reads. Measured on a real sharded project: top_anti_patterns surfaced
0 (the stub parsed to "no entries"), top_bugs surfaced 2 — while the
backend shards held 242 anti-patterns and 534 bugs that were completely
invisible to the agent.
Fix: add _iter_kind()/_entries_for_kind() that aggregate across every
source whose .kind matches (canonical + same-kind extras), deduped by
(id, title). top_bugs / top_anti_patterns / redis_keys / db_impact /
dependency_map / architecture_sections / hotspots_for_files /
detect_conflicts all switch to it. No config change needed for projects
that already register shards under sources.extra; on the real project
this turned top_bugs 2->533 and top_anti_patterns 0->242.
New test_kind_aggregates_across_extra_shards pins the behavior. All
context/sources/conflicts/adapters/layered suites green (55 tests).
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.
Summary
Real bug fix surfaced from a sharded-docs project: the Context's accessors (
top_bugs,top_anti_patterns, etc.) only read the single canonically-named source. Projects that follow the hand-maintained docs convention with sharded files (bug-registry-{infra,agents,orchestrator}.md,db-impact-map-{master,tenant,vector}.md, etc.) had their content invisible to the agent — the canonical-named entry parsed to a thin stub, while the shards sat in the cache but were never aggregated into Context.Measured impact (real project)
top_bugstop_anti_patternsAgent reads went from "this project has 2 known bugs" to "this project has 533 known bugs across 3 shards."
Fix
context.pygains_iter_kind()/_entries_for_kind()helpers that walk every source whose.kindmatches (canonical + same-kind extras), deduped by(id, title). Eight accessors switch to the kind-aggregator:top_bugstop_anti_patternsredis_keysdb_impactdependency_maparchitecture_sectionshotspots_for_filesdetect_conflictsNo config change required for projects that already register shards under
sources.extrawith the rightkind. Single-canonical-source projects are unchanged — the helper falls through when no extras share the kind.Test plan
test_kind_aggregates_across_extra_shardspins the behaviourVersion
0.5.4 → 0.5.5(Bug-fix release. The fix is the work of
26d1bf9; this PR also bumps version + adds CHANGELOG entry in a separate commit so the release-note artefact is on main.)Generated by Claude Code