You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
# [SCHEMA] Expand SQLite and Output Recorders for Class-Level Risk Vectors #110
Ensure the newly calculated Class-level risk vectors are successfully persisted in the data translation layer.
🛠️ Implementation
record_keeper.py: Update the class_data table schema to include the 14 relevant metrics from RISK_SCHEMA (currently it only holds basic physics like method_count, state_entanglement, and lcom_score).
gpu_recorder.py & audit_recorder.py: Ensure the classes array inside the file payload retains its calculated risk vectors so the WebGL UI and forensic JSON can render them accurately.
Verified the "14 relevant metrics" against `08-01-methodology.md`'s hierarchy table and `RISK_SCHEMA` (`gitgalaxy/standards/analysis_lens.py:1047`). The number's exactly right, and here's the concrete list so schema work doesn't have to re-derive it:
Stays File-level only, N/A at Class (the other 5): `dead_code` (Graveyard), `stability` (File Stability/Heat), `churn` (Deep Churn), `tabs_vs_spaces` (Civil War), `secrets_risk` (Hardcoded Secrets). These are explicitly marked N/A at Class/Function in the doc table -- not an oversight, don't add columns for these.
Also confirmed the current `class_data` table description is accurate: `detector.py`'s class extractor (~line 466-522) only writes `method_count`, `state_entanglement`, and `lcom_score` today.
One thing worth deciding before the schema is finalized (see discussion on #109): per the methodology doc, Class-level values are "count based, 0-∞", not the 0-100 sigmoid-normalized scale File-level uses. Worth making sure the 14 new columns are typed/labeled to make that distinction obvious (e.g. not reusing the same column names/scale as the file-level risk vector), so downstream consumers don't accidentally treat a class's raw count as a percentage.
Activity
squid-protocol commentedon Jul 25, 2026
Verified the "14 relevant metrics" against `08-01-methodology.md`'s hierarchy table and `RISK_SCHEMA` (`gitgalaxy/standards/analysis_lens.py:1047`). The number's exactly right, and here's the concrete list so schema work doesn't have to re-derive it:
Needs Class-level rollup (14): `cognitive_load`, `safety_score`, `tech_debt`, `verification`, `api_exposure`, `concurrency`, `state_flux`, `spec_match`, `documentation`, `algorithmic_dos`, `obscured_payload`, `logic_bomb`, `injection_surface`, `memory_corruption`.
Stays File-level only, N/A at Class (the other 5): `dead_code` (Graveyard), `stability` (File Stability/Heat), `churn` (Deep Churn), `tabs_vs_spaces` (Civil War), `secrets_risk` (Hardcoded Secrets). These are explicitly marked N/A at Class/Function in the doc table -- not an oversight, don't add columns for these.
Also confirmed the current `class_data` table description is accurate: `detector.py`'s class extractor (~line 466-522) only writes `method_count`, `state_entanglement`, and `lcom_score` today.
One thing worth deciding before the schema is finalized (see discussion on #109): per the methodology doc, Class-level values are "count based, 0-∞", not the 0-100 sigmoid-normalized scale File-level uses. Worth making sure the 14 new columns are typed/labeled to make that distinction obvious (e.g. not reusing the same column names/scale as the file-level risk vector), so downstream consumers don't accidentally treat a class's raw count as a percentage.