Skip to content

analyze facade: workspace scoping for the remaining legacy-alias kinds (run_inspections, get_communities, get_processes, get_recent_changes) #397

Description

@tydude001

Summary

#395 (merged 2026-07-28) fixed the workspace-scoping bug from #349 for the analyze facade's health and clones aliases: both were shadowed by a legacy alias table that forwarded them straight to audit_health/find_clones before the dispatcher's resolveScope ever ran, so neither got the workspace clamp.

The PR's own description flags that the same alias-shadowing pattern applies to other entries in that table, and names several handlers that are also globally unscoped:

  • run_inspections
  • get_communities
  • get_processes
  • get_recent_changes
  • audit_agent_config (noted as root-pinned by design, possibly correct as-is)

Quoting #395: "Each needs its own scoping decision (community detection runs one partition over the whole index and already has a dedicated clamp helper; agent_config is arguably correct as-is), so folding them in would mean several unrelated design calls in one change. Worth a follow-up issue."

This is that issue.

Ask

For each of run_inspections / get_communities / get_processes / get_recent_changes: decide whether it should be workspace-clamped like health_score/dead_code/hotspots now are, or is legitimately global/root-scoped like audit_agent_config, and apply the same resolveScope + scope_applied treatment #395 used where a clamp is the right call.

Environment

Same daemon family as #349/#395v0.61.1+89263194 at report time, default one-workspace-per-repo layout.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions