Grafo cactus - Lez07

[notedo]

[notedo]

def cactus(G):
    def cactus_interna(u, padre, visitati, terminali, nnc):
        visitati[u] = 1
        cc = 0

        for y in G[u]:
            if visitati[y] == 0:
                cc += cactus_interna(y, u, visitati, terminali, nnc)
            elif y!=padre and visitati[y] == 1:
                terminali[y] += 1
                cc += 1

        visitati[u] = 2
        nnc[u] += cc
        return cc - terminali[u]

    visitati = [0 for _ in range(len(G))]
    terminali = [0 for _ in range(len(G))]
    nnc = [0 for _ in range(len(G))]
    cactus_interna(0, 0, visitati, terminali, nnc)
    double_count = 0
    for i in range(len(G)):
        if nnc[i] > 1:
            double_count += 1
    if double_count > 1: return False
    return True

[Ludu-nuvai]

This is a solid direction. The shift from "3D visualizer" to "intelligence surface where signals converge" makes sense, and starting with Build Mode as the first slice is the right call — narrow path, one data source, proves the whole connector → UUID → overlay pattern.

A few things I think we should settle before jumping into connector work:

UUID stability. Everything joins on the CIG UUID, so if that breaks on renames or re-parses, every mode breaks with it. What happens when parse_file becomes parse_input — new UUID or same one? What happens when a function gets deleted — does the UUID just vanish, leaving old perf/coverage data pointing nowhere? If a function gets split into two, do we track lineage? We don't need the perfect answer right now, but we need the contract before anyone writes a connector. Otherwise each connector author makes their own assumptions and we pay for it later.

Incremental computation. "Always computing" across 10 modes sounds great, but if every file save triggers full cross-modal joins in Knuckles, it's dead on arrival for repos over 10K LOC. Build Mode should include the dirty-node model — file X changes, which CIG nodes get invalidated, what recomputes? If it works for one mode, it scales. If we skip this, the insight bar ships as a slow polling loop and nobody keeps it open.

The inference rules are the actual product. Connectors are plumbing. Rendering is design work. But the rules that decide what's worth surfacing — that's where it succeeds or fails. The "parse_payment() has 12% coverage, changed 4 times, has 2 open bugs" example is great, but it's a hand-crafted story from 4 sources. Getting a machine to reliably generate those without being too noisy, too conservative, or confidently wrong is the hard part. Build Mode is safe because "build failed at line X" is unambiguous. The cross-modal insights are where the risk lives.

On the other gaps @hari-nuvai raised — auth, offline, plugins, collaboration, trends — all real, none should block Build Mode. My take: noted, defer, but don't close the door. The UUID join key and mode/zoom architecture already leave the right seams open.

TL;DR: lock the UUID contract and incremental model before connectors ship. Build Mode first. The vision tracks.