Stabilizing Dependency Management and Dashboard Clarity (VIPC authority, rebuild flow, and UX fixes)

[elijah286]

I wanted to share a consolidated update on the dependency-management work we’ve been doing, why it was necessary, what changed, and where I’d like feedback from the community.

Why this work was needed

We were seeing recurring confusion and fragility in dependency handling, especially around:

1. Dependency source-of-truth drift.
2. Corrupted or ambiguous VIPC content.
3. Dashboard/UI signals that were technically correct but hard to interpret quickly.
4. Update flows that were functional but lacked a strong final “are you sure?” review step.
5. Reconfigure workflow failures caused by repository Actions permissions.

What we changed

1) Moved to VIPC-first authority

The committed VIPC files are now authoritative for what should be baked into worker containers. JSON sidecars remain useful for metadata/tooling assistance, but they are no longer treated as authoritative install intent.

2) Repaired and normalized dependency artifacts

We replaced damaged VIPC inputs with repaired equivalents, validated parseability, and then removed duplicate repaired artifacts so only canonical files remain.

3) Improved dependency delta and pending behavior

The dashboard dependency logic was updated to better reflect actual pending state and platform/container context, including dragon + VIPC signal handling.

4) Restored and improved rebuild/update controls

The dependencies page now has working rebuild/update controls again, plus improved update progress and dispatch behavior.

5) Added explicit final approval before update

Before starting a container update, the UI now shows a final approval dialog with per-container diff summary (add/upgrade/remove), so the impact is visible before dispatch.

6) Improved readability of VIPC/package hierarchy

The dependencies table now visually nests package rows under their VIPC parent row, making it much clearer which packages belong to which file.

7) Hardened reconfigure PR behavior

We addressed reconfigure-run fragility when Actions cannot auto-create PRs by improving token/fallback behavior and avoiding hard-stop confusion where possible.

What this should improve

1. More deterministic dependency behavior in CI.
2. Fewer false assumptions about what is “declared” vs “installed”.
3. Better operator confidence when triggering dependency rebuilds.
4. Better visual comprehension of dependency ownership in the dashboard.

Known operational caveat

Repository-level GitHub Actions settings still matter (especially PR creation permissions). Tooling can reduce friction and provide fallbacks, but org/repo policy can still gate full automation.

Feedback requested

I’d love feedback on:

1. Whether the new nested VIPC/package presentation is easier to scan.
2. Whether the approval dialog shows enough diff detail before updates.
3. Any remaining ambiguity in dependency status semantics you’d like clarified in UI text.
4. Any concerns about the VIPC-first authority model for your workflows.

Next likely improvements

1. Additional legend/tooltips distinguishing “declared in source file” vs “installed in container manifest”.
2. Optional denser/sparser table density settings for large dependency sets.
3. Additional guardrails around experimental container lanes and pending signals.