Confirmed while building Episode 14 ("Agent Coordination") demo material.
Data-integrity-adjacent: not a correctness bug in stored data, but a
silently-wrong risk assessment that agent coordination workflows would
actually rely on.
qualified_name for an import symbol is ::-separated
(e.g. "import::auth::login" for from auth import login,
confirmed via muse code deps app.py --json -> "imports": ["import::auth::login", "import::billing::charge"]). Calling
.split(".") on a string with zero . characters is a no-op — it
returns the whole string unchanged as a single-element list, so [-1]
is the original string. .replace("import::", "") then only strips the
fixed prefix, leaving "auth::login" — which can never match a bare
file stem key like "auth" in stem_to_file. Every from X import Y
statement (the dominant Python import style) fails to resolve to an
edge. Only bare import x statements (qualified_name "import::x",
no further :: segments) happen to work, because in that one case the
leftover after .replace() really is just the stem.
Confirmed reproducible: built a real 4-file codebase with genuine
import chains (app.py -> auth.py -> db.py, app.py -> billing.py ->
db.py, all via from X import Y). muse code impact/muse code deps
correctly show the real call graph. muse coord shard --agents 2 --json
reports cross_shard_edges: 0 and coupling_score: 0 for every shard
regardless of partition, even when app.py and its two direct dependents
land in different shards — the tool believes the codebase has zero
cross-file coupling when it demonstrably does not.
Suggested fix: split on "::" and take the segment right after
"import", e.g. rec["qualified_name"].split("::")[1], not a
dot-split combined with a fixed-prefix strip.
Impact:muse coord shard's entire value proposition is
recommending low-coupling partitions for parallel agents to work in
without colliding. With this bug, a partition it labels "coupling: 0"
between two shards can in fact be tightly coupled via ordinary
from X import Y code, meaning two agents assigned to "independent"
shards could still be editing code on either side of a real call-graph
edge the tool never told them about.
Confirmed while building Episode 14 ("Agent Coordination") demo material. Data-integrity-adjacent: not a correctness bug in stored data, but a silently-wrong risk assessment that agent coordination workflows would actually rely on.
Root cause:
muse/cli/commands/shard.py::_build_import_edges():qualified_namefor an import symbol is::-separated (e.g."import::auth::login"forfrom auth import login, confirmed viamuse code deps app.py --json->"imports": ["import::auth::login", "import::billing::charge"]). Calling.split(".")on a string with zero.characters is a no-op — it returns the whole string unchanged as a single-element list, so[-1]is the original string..replace("import::", "")then only strips the fixed prefix, leaving"auth::login"— which can never match a bare file stem key like"auth"instem_to_file. Everyfrom X import Ystatement (the dominant Python import style) fails to resolve to an edge. Only bareimport xstatements (qualified_name"import::x", no further::segments) happen to work, because in that one case the leftover after.replace()really is just the stem.Confirmed reproducible: built a real 4-file codebase with genuine import chains (app.py -> auth.py -> db.py, app.py -> billing.py -> db.py, all via
from X import Y).muse code impact/muse code depscorrectly show the real call graph.muse coord shard --agents 2 --jsonreportscross_shard_edges: 0andcoupling_score: 0for every shard regardless of partition, even when app.py and its two direct dependents land in different shards — the tool believes the codebase has zero cross-file coupling when it demonstrably does not.Suggested fix: split on
"::"and take the segment right after"import", e.g.rec["qualified_name"].split("::")[1], not a dot-split combined with a fixed-prefix strip.Impact:
muse coord shard's entire value proposition is recommending low-coupling partitions for parallel agents to work in without colliding. With this bug, a partition it labels "coupling: 0" between two shards can in fact be tightly coupled via ordinaryfrom X import Ycode, meaning two agents assigned to "independent" shards could still be editing code on either side of a real call-graph edge the tool never told them about.Deferred per usual until after the season wraps.