feat: generation-aware SCC and configured layering analysis #28

Open
opened 2026-07-20 22:38:26 +02:00 by buildagent · 1 comment
Member

Rank 7 of the 2026-07-20 index-data brainstorm (_prdoc/records/brainstorm-2026-07-20-index-data-catalog.md).

What: Tarjan SCCs over file-level edges (which files cannot be edited independently) plus a crate-layering conformance mode checked against Cargo.toml workspace deps — an "architectural conscience" an agent consults before adding an import.

Why: 5 real file-level 2-cycles exist right now: cli/main.rs↔link.rs, cli/main.rs↔doctor.rs, indexer/db.rs↔migrations.rs, daemon/access.rs↔local_index.rs, plus a ruby fixture cycle (proving cross-language detection). Crate layering is perfectly clean (0 violations across 14 boundaries) — so the conformance mode ships as a cheap enforceable CI invariant. Boundary surfaces are strikingly narrow (indexer→plugins crosses through exactly ONE symbol, all_plugins).

Cost: small — Tarjan on ~109 file nodes at query time + Cargo.toml parse; no new data.

Runtime-plugin architecture expansion

Graph analysis must operate on a declared evidence basis:

  • active generation only;
  • builtin_only vs dynamically influenced edges;
  • package/component provenance;
  • explicit cross-language bridges;
  • unresolved/degraded coverage counts.

Do not merge nodes merely because package language ids or paths resemble builtin ones. Pending generations are separately inspectable but never mixed into active SCCs.

Layering conformance for code-index itself should enforce the #75 boundary: plugin-host/ABI packages cannot depend on daemon DB/resolver/query implementation. Project layering remains explicitly configured, not inferred.

review_diff v2 (#34) consumes “new SCC vs pre-existing SCC”; context_pack v2 (#35) consumes local SCC membership. Prefer one reusable analyzer and avoid another large always-loaded MCP description unless #51 proves a top-level tool is discoverable/useful.

Rank 7 of the 2026-07-20 index-data brainstorm (`_prdoc/records/brainstorm-2026-07-20-index-data-catalog.md`). **What**: Tarjan SCCs over file-level edges (which files cannot be edited independently) plus a crate-layering conformance mode checked against Cargo.toml workspace deps — an "architectural conscience" an agent consults before adding an import. **Why**: 5 real file-level 2-cycles exist right now: `cli/main.rs↔link.rs`, `cli/main.rs↔doctor.rs`, `indexer/db.rs↔migrations.rs`, `daemon/access.rs↔local_index.rs`, plus a ruby fixture cycle (proving cross-language detection). Crate layering is perfectly clean (0 violations across 14 boundaries) — so the conformance mode ships as a cheap enforceable CI invariant. Boundary surfaces are strikingly narrow (indexer→plugins crosses through exactly ONE symbol, `all_plugins`). **Cost**: small — Tarjan on ~109 file nodes at query time + Cargo.toml parse; no new data. ## Runtime-plugin architecture expansion Graph analysis must operate on a declared evidence basis: - active generation only; - builtin_only vs dynamically influenced edges; - package/component provenance; - explicit cross-language bridges; - unresolved/degraded coverage counts. Do not merge nodes merely because package language ids or paths resemble builtin ones. Pending generations are separately inspectable but never mixed into active SCCs. Layering conformance for code-index itself should enforce the #75 boundary: plugin-host/ABI packages cannot depend on daemon DB/resolver/query implementation. Project layering remains explicitly configured, not inferred. review_diff v2 (#34) consumes “new SCC vs pre-existing SCC”; context_pack v2 (#35) consumes local SCC membership. Prefer one reusable analyzer and avoid another large always-loaded MCP description unless #51 proves a top-level tool is discoverable/useful.
Author
Member

Triage: P3 — useful analyzer, not the next milestone

Keep open, but schedule after stable handles (#37) and context_pack (#35). Implement file-level SCC detection first; layering conformance should be a separate mode with explicit configuration rather than inferred architectural policy.

Design it as a reusable analyzer consumed by review_diff (#34) and context_pack, not necessarily another frequently invoked top-level tool. Findings must distinguish newly introduced cycles from pre-existing cycles and exclude/label fixtures and generated code.

### Triage: P3 — useful analyzer, not the next milestone Keep open, but schedule after stable handles (#37) and `context_pack` (#35). Implement file-level SCC detection first; layering conformance should be a separate mode with explicit configuration rather than inferred architectural policy. Design it as a reusable analyzer consumed by `review_diff` (#34) and `context_pack`, not necessarily another frequently invoked top-level tool. Findings must distinguish newly introduced cycles from pre-existing cycles and exclude/label fixtures and generated code.
buildagent changed title from feat: detect_cycles + check_layering — file/crate SCCs and cycle-aware edit checks to feat: generation-aware SCC and configured layering analysis 2026-08-26 13:41:58 +02:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
h-dv/code-index#28
No description provided.