Direction check: evolving the compliance dashboard as a read-only view over existing GRC outputs

[jeftekhari]

I wanted to open a direction check before writing code.

Long term, I’m interested in helping the compliance-posture dashboard become a better read-only view over existing GRC outputs across the repo. The rough end goal would be: when the toolkit already produces or stores useful GRC information somewhere, the dashboard can help users inspect it without changing the underlying producer, schema, or storage path.

I want to be careful with that boundary. I’m not proposing that the dashboard become a source of truth, write to grc-data, move data around, or require other plugins/connectors to save data differently.

Near-term, I think the safest first step is much narrower:

The dashboard already reads saved monitor_continuous_run JSON. That object appears to contain useful detail the UI does not currently surface, especially under gap_assessment_summary:

• tier 1 / tier 2 / tier 3 control details
• failing resources
• remediation text when connector findings include it
• load/source errors that explain no_data
• per-framework evaluated / passing / failing / inconclusive counts
• metric-recording status under artifacts.metrics

Possible first PR scope:

• add a “Run Details” or “Findings” section for the latest saved run
• show top tiered gaps from the existing monitor JSON
• allow expanding a gap to see failing resources/remediation when present
• surface load/source errors in a small diagnostics area
• keep quiet empty states for older/demo runs that lack these fields

Explicit non-goals for the first PR:

• no schema changes
• no connector changes
• no changes to monitor-continuous
• no changes to where anything is written
• no writes to grc-data
• no new dashboard-owned state file
• no aggregation of risks/exceptions/vendors/policies yet

If that direction seems acceptable, I’d treat this as an incremental path:

1. First, make the dashboard better at rendering the monitor output it already consumes.
2. Later, discuss whether other existing repo outputs should be optional read-only dashboard inputs.
3. Only add new inputs when maintainers explicitly want that boundary.
4. End game is maybe a sqlite db for persistent data/host dashboard non-local but I'm not sure that's appropriate for a claude plugin

Would maintainers be open to that direction, starting with the narrow monitor-only drill-down?