config-check.ts File Reference

The config-view panel for cross-chunk checks (Phase 29). More...

import st;

Include dependency graph for config-check.ts:

Functions
function export	vaultNames ()
	Entry names a ${…} reference may point at: provider, and provider_keyid.
function export	elsewhereServices ()
	Compose service names (and container names) of every project, lowercased: what unv check --all-projects resolves a proxy_pass host against.

Variables
export interface	ConfigFinding
severity	__pad0__
chunk_id	__pad1__
chunk	__pad2__
chunk_type	__pad3__
field	__pad4__
message	__pad5__
related	__pad6__

Detailed Description

The config-view panel for cross-chunk checks (Phase 29).

@description Asks Rust (vault_core::config_check, the same code unv check runs) and paints the answer. There is deliberately no rule here: a second implementation is a second opinion about what a project means, and these rules exist to remove exactly that.

The panel is silent when the project is clean and when the app is running in a plain browser (no IPC bridge); a "✓ all good" line on every config view is noise, and a message that the check could not run would be shown to everyone who develops in npm run dev.

Function Documentation

vaultNames()

function export vaultNames

(

)

Entry names a ${…} reference may point at: provider, and provider_keyid.

elsewhereServices()

function export elsewhereServices

(

)

Compose service names (and container names) of every project, lowercased: what unv check --all-projects resolves a proxy_pass host against.

Variable Documentation

ConfigFinding

export interface ConfigFinding

Initial value:

{
  rule: string

__pad0__

severity __pad0__

__pad1__

chunk_id __pad1__

__pad2__

chunk __pad2__

__pad3__

chunk_type __pad3__

__pad4__

field __pad4__

__pad5__

message __pad5__

__pad6__

related __pad6__