Repository navigation
BUILD-CLP-001-S — Repository Governance Observability + Health Projection - #5
JaeTierce31 wants to merge 41 commits into
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 630885b5b9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| UNION ALL SELECT repository,observed_at,'SUPERSESSION',receipt_id,jsonb_build_object('superseded',superseded_assertion_id,'superseding',superseding_assertion_id) FROM edopsys_observability.governance_supersession_receipts | ||
| UNION ALL SELECT repository,detected_at,'DRIFT',finding_id,jsonb_build_object('type',finding_type,'severity',severity,'resolution',resolution_status) FROM edopsys_observability.governance_drift_findings; | ||
| CREATE VIEW edopsys_observability.v_repository_health AS | ||
| WITH b AS(SELECT DISTINCT ON(repository)* FROM edopsys_observability.repository_baseline ORDER BY repository,observed_at DESC,id DESC),bu AS(SELECT DISTINCT ON(repository) repository,health FROM edopsys_observability.v_build_health WHERE canonical ORDER BY repository,observed_at DESC),ci AS(SELECT DISTINCT ON(repository) repository,ci_health FROM edopsys_observability.v_ci_health ORDER BY repository,observed_at DESC),i AS(SELECT * FROM edopsys_observability.v_integrity_health),rv AS(SELECT * FROM edopsys_observability.v_review_health),a AS(SELECT * FROM edopsys_observability.v_authority_health),d AS(SELECT * FROM edopsys_observability.v_governance_drift) |
There was a problem hiding this comment.
When the repository contains CI observations for multiple builds, this ci CTE selects the most recently observed run across the entire repository, independently of the build selected by bu or b.latest_merged_build. A newer run for a non-canonical build can therefore hide a failed canonical run—or falsely block a healthy canonical build—so select CI for the canonical build ID rather than ordering all repository runs together.
Useful? React with 👍 / 👎.
| SELECT r.repository,count(p.*) FILTER(WHERE severity='P0' AND NOT resolved AND NOT superseded) p0,count(p.*) FILTER(WHERE severity='P1' AND NOT resolved AND NOT superseded) p1,count(p.*) FILTER(WHERE severity='P2' AND NOT resolved AND NOT superseded) p2, | ||
| CASE WHEN count(p.*)=0 THEN 'UNKNOWN' WHEN count(p.*) FILTER(WHERE severity IN('P0','P1') AND NOT resolved AND NOT superseded)>0 THEN 'BLOCKED' WHEN count(p.*) FILTER(WHERE severity='P2' AND NOT resolved AND NOT superseded)>0 THEN 'DEGRADED' WHEN count(p.*) FILTER(WHERE reviewed_sha=expected_head_sha AND finding_status IN('APPROVED','CLEAN'))>0 THEN 'HEALTHY' ELSE 'UNKNOWN' END health |
There was a problem hiding this comment.
When an open P0/P1 finding is later resolved through a new immutable observation, the original row still satisfies NOT resolved AND NOT superseded, so v_review_health remains BLOCKED forever. The append-only trigger prevents correcting that original row, and pr_reviews has no stable finding key or supersession relationship for selecting the latest state; the view needs to collapse snapshots per logical finding before counting unresolved severities.
Useful? React with 👍 / 👎.
| CASE WHEN count(p.*)=0 THEN 'UNKNOWN' WHEN count(p.*) FILTER(WHERE severity IN('P0','P1') AND NOT resolved AND NOT superseded)>0 THEN 'BLOCKED' WHEN count(p.*) FILTER(WHERE severity='P2' AND NOT resolved AND NOT superseded)>0 THEN 'DEGRADED' WHEN count(p.*) FILTER(WHERE reviewed_sha=expected_head_sha AND finding_status IN('APPROVED','CLEAN'))>0 THEN 'HEALTHY' ELSE 'UNKNOWN' END health | ||
| FROM (SELECT DISTINCT repository FROM edopsys_observability.repository_baseline) r LEFT JOIN edopsys_observability.pr_reviews p USING(repository) GROUP BY r.repository; | ||
| CREATE VIEW edopsys_observability.v_authority_health AS | ||
| SELECT r.repository,CASE WHEN count(a.*)=0 OR count(a.*) FILTER(WHERE freshness_status='UNKNOWN')>0 THEN 'UNKNOWN' WHEN count(a.*) FILTER(WHERE freshness_status='CONFLICT' AND execution_blocking)>0 THEN 'BLOCKED' WHEN count(a.*) FILTER(WHERE freshness_status='FRESHNESS_REVIEW_DUE')>0 THEN 'DEGRADED' ELSE 'HEALTHY' END health |
There was a problem hiding this comment.
When a repository has both an UNKNOWN authority record and a CONFLICT record with execution_blocking=true, the first WHEN returns UNKNOWN before the blocking-conflict predicate is evaluated. This violates the fail-closed rule that a known execution-blocking authority conflict produces BLOCKED; evaluate that predicate before the unknown-state branch.
Useful? React with 👍 / 👎.
| CREATE VIEW edopsys_observability.v_repository_health AS | ||
| WITH b AS(SELECT DISTINCT ON(repository)* FROM edopsys_observability.repository_baseline ORDER BY repository,observed_at DESC,id DESC),bu AS(SELECT DISTINCT ON(repository) repository,health FROM edopsys_observability.v_build_health WHERE canonical ORDER BY repository,observed_at DESC),ci AS(SELECT DISTINCT ON(repository) repository,ci_health FROM edopsys_observability.v_ci_health ORDER BY repository,observed_at DESC),i AS(SELECT * FROM edopsys_observability.v_integrity_health),rv AS(SELECT * FROM edopsys_observability.v_review_health),a AS(SELECT * FROM edopsys_observability.v_authority_health),d AS(SELECT * FROM edopsys_observability.v_governance_drift) | ||
| SELECT b.repository,b.canonical_head,b.latest_merged_build,COALESCE(bu.health,'UNKNOWN') build_status,COALESCE(ci.ci_health,'NO_RUN') ci_status,COALESCE(i.health,'UNKNOWN') integrity_status,COALESCE(rv.health,'UNKNOWN') review_status,COALESCE(a.health,'UNKNOWN') authority_status,COALESCE(d.health,'HEALTHY') drift_status, | ||
| (COALESCE(rv.p0,0)+COALESCE(rv.p1,0)+CASE WHEN COALESCE(i.health,'UNKNOWN')='BLOCKED' THEN 1 ELSE 0 END+CASE WHEN COALESCE(ci.ci_health,'NO_RUN')='FAIL' THEN 1 ELSE 0 END+CASE WHEN COALESCE(a.health,'UNKNOWN')='BLOCKED' THEN 1 ELSE 0 END+CASE WHEN COALESCE(d.health,'HEALTHY')='BLOCKED' THEN 1 ELSE 0 END) blocking_reason_count, |
There was a problem hiding this comment.
When the canonical build is blocked solely because it is unauthorized or carries blocking_findings, overall_health becomes BLOCKED but this expression still reports blocking_reason_count = 0 because it never includes bu.health. Dashboard consumers therefore receive a contradictory blocked state with no blocking reasons; include the blocked build gate in the count.
Useful? React with 👍 / 👎.
| CASE WHEN count(d.*) FILTER(WHERE resolution_status='OPEN' AND severity IN('P0','P1'))>0 THEN 'BLOCKED' WHEN count(d.*) FILTER(WHERE resolution_status='OPEN' AND severity IN('P2','P3'))>0 THEN 'DEGRADED' ELSE 'HEALTHY' END health | ||
| FROM (SELECT DISTINCT repository FROM edopsys_observability.repository_baseline) r LEFT JOIN edopsys_observability.governance_drift_findings d USING(repository) GROUP BY r.repository; |
There was a problem hiding this comment.
When no drift observations have been ingested for a repository, the left join produces zero open findings and this view returns HEALTHY, making an unobserved drift gate indistinguishable from a completed clean assessment. This can let a repository with all other observations present become globally HEALTHY despite the stated requirement that missing observation sets remain UNKNOWN; record/select an explicit clean drift assessment or return UNKNOWN when the set is absent.
Useful? React with 👍 / 👎.
|
@codex review Please perform a fresh independent review of exact head |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 80851d8902
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| source_path text NOT NULL,source_commit text,observed_at timestamptz NOT NULL,valid_to timestamptz, | ||
| superseded_by text REFERENCES edopsys_observability.governance_status_assertions(assertion_id),authority_rank int NOT NULL, | ||
| status text NOT NULL CHECK(status IN('CURRENT','HISTORICAL','SUPERSEDED','CONFLICT','UNKNOWN'))); |
There was a problem hiding this comment.
When a CURRENT assertion is ingested before its eventual replacement, this row cannot later acquire valid_to, superseded_by, or SUPERSEDED because the append-only trigger rejects updates. Inserting a supersession receipt alone does not affect v_governance_assertion_current, so the old assertion remains current; the G0 fixture passes only because it backfills both assertions with the old row already marked superseded. Model the later state as a new immutable observation and derive currentness from the supersession relationship.
Useful? React with 👍 / 👎.
| CREATE TABLE edopsys_observability.governance_drift_findings( | ||
| finding_id text PRIMARY KEY,repository text NOT NULL,finding_type text NOT NULL,subject text NOT NULL,severity text NOT NULL CHECK(severity IN('P0','P1','P2','P3')), | ||
| resolution_status text NOT NULL CHECK(resolution_status IN('OPEN','RESOLVED','SUPERSEDED','ACCEPTED_RISK')),resolution_receipt text REFERENCES edopsys_observability.governance_supersession_receipts(receipt_id),detected_at timestamptz NOT NULL); |
There was a problem hiding this comment.
Once a drift finding is inserted as OPEN, its primary key prevents inserting a later state with the same finding ID and the append-only trigger prevents changing resolution_status or attaching a resolution receipt. The original row therefore remains counted by v_governance_drift forever, permanently blocking or degrading the repository even after the drift is resolved. Store immutable drift-state observations under separate IDs and project the latest state per logical finding.
Useful? React with 👍 / 👎.
| CASE WHEN count(p.*)=0 THEN 'UNKNOWN' WHEN count(p.*) FILTER(WHERE severity IN('P0','P1') AND NOT resolved AND NOT superseded)>0 THEN 'BLOCKED' WHEN count(p.*) FILTER(WHERE severity='P2' AND NOT resolved AND NOT superseded)>0 THEN 'DEGRADED' WHEN count(p.*) FILTER(WHERE reviewed_sha=expected_head_sha AND finding_status IN('APPROVED','CLEAN'))>0 THEN 'HEALTHY' ELSE 'UNKNOWN' END health | ||
| FROM (SELECT DISTINCT repository FROM edopsys_observability.repository_baseline) r LEFT JOIN edopsys_observability.pr_reviews p USING(repository) GROUP BY r.repository; |
There was a problem hiding this comment.
After repository_baseline advances to a new head, an old approval still satisfies reviewed_sha=expected_head_sha because both values come from that historical review row; the comparison is never made against the active baseline or canonical build. With no findings for the new head, this causes v_review_health to remain HEALTHY instead of UNKNOWN, allowing repository health to claim that an unreviewed head passed review.
Useful? React with 👍 / 👎.
| CREATE VIEW edopsys_observability.v_integrity_health AS | ||
| SELECT r.repository,CASE WHEN count(a.*) FILTER(WHERE a.required AND a.status IN('MISSING','HASH_MISMATCH','SIZE_MISMATCH'))>0 THEN 'BLOCKED' WHEN count(a.*) FILTER(WHERE a.required)=0 OR count(a.*) FILTER(WHERE a.required AND a.status='UNVERIFIED')>0 THEN 'UNKNOWN' ELSE 'HEALTHY' END health | ||
| FROM (SELECT DISTINCT repository FROM edopsys_observability.repository_baseline) r LEFT JOIN edopsys_observability.artifact_integrity a USING(repository) GROUP BY r.repository; |
There was a problem hiding this comment.
When a new baseline/build is appended without its own integrity evidence, any required PASS row from the preceding build keeps this aggregate HEALTHY, because integrity records are grouped only by repository and have no current-build filter. This collapses a missing integrity observation for the new build into success; conversely, a historical mismatch also blocks forever after a later successful verification. Associate observations with the relevant head/build and project only the current integrity set.
Useful? React with 👍 / 👎.
|
@codex review Please perform a fresh independent review of BUILD-CLP-001-S on exact head Review focus:
Do not reuse conclusions from any earlier S head. Classify findings P0/P1/P2/P3; any P0/P1 blocks merge. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9daa6fad70
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ), bu AS ( | ||
| SELECT DISTINCT ON(repository) repository,build_id,health FROM v_build_health WHERE canonical ORDER BY repository,observed_at DESC | ||
| ), i AS (SELECT * FROM v_integrity_health), |
There was a problem hiding this comment.
When a new baseline is appended without a corresponding build_status observation, this CTE still selects the newest historical row having canonical=true, even if its build_id differs from b.latest_merged_build. If CI and the other observations for the new build are present, repository health can reuse the old build's authorization/findings state rather than fail closed on the missing build observation; join the build projection by the baseline's latest_merged_build, as the CI projection already does.
Useful? React with 👍 / 👎.
| CREATE VIEW v_authority_health AS | ||
| SELECT r.repository,CASE | ||
| WHEN count(a.*) FILTER(WHERE freshness_status='CONFLICT' AND execution_blocking)>0 THEN 'BLOCKED' | ||
| WHEN count(a.*)=0 OR count(a.*) FILTER(WHERE freshness_status='UNKNOWN')>0 THEN 'UNKNOWN' | ||
| WHEN count(a.*) FILTER(WHERE freshness_status='FRESHNESS_REVIEW_DUE')>0 THEN 'DEGRADED' | ||
| ELSE 'HEALTHY' END health |
There was a problem hiding this comment.
Because this aggregate evaluates every immutable authority_records row, a blocking conflict can never be cleared by appending a later CURRENT observation for the same authority: the historical conflict continues to satisfy this predicate and permanently blocks the repository. Conversely, a repository containing only SUPERSEDED or HISTORICAL_ONLY authority rows falls through to HEALTHY; collapse observations to the current state per logical authority before evaluating freshness and conflicts.
Useful? React with 👍 / 👎.
| root = pathlib.Path('governance/clp-001/builds/BUILD-CLP-001-S') | ||
| manifest = json.loads((root / 'receipts/S-source-manifest.json').read_text()) | ||
| failures = [] | ||
| for item in manifest['files']: |
There was a problem hiding this comment.
The integrity step reads the manifest from the same checkout it is validating but never compares that file's digest with the source_manifest_sha256 recorded in the verification receipt. A change can therefore modify a migration or test and update—or empty—the manifest in the same commit, and this gate still prints S_SOURCE_MANIFEST_PASS; validate the manifest itself against the frozen expected digest and reject incomplete inventories before trusting its file list.
Useful? React with 👍 / 👎.
| actual=$(psql -Atc "SELECT overall_health FROM edopsys_observability.v_repository_health WHERE repository='JaeTierce31/EdOpSys'") | ||
| blockers=$(psql -Atc "SELECT blocking_reason_count FROM edopsys_observability.v_repository_health WHERE repository='JaeTierce31/EdOpSys'") | ||
| test "$actual" = "DEGRADED" | ||
| test "$blockers" = "0" |
There was a problem hiding this comment.
The live-projection gate checks only aggregate DEGRADED health and a zero blocker count. A regression that makes authority health HEALTHY while making review, CI, or drift DEGRADED would still pass, even though the required live projection is specifically authority-freshness debt with every other gate passing; assert the individual gate values (or the expected dashboard JSON) here.
Useful? React with 👍 / 👎.
|
@codex review Please perform a fresh independent review of BUILD-CLP-001-S v1.0.1 on exact head Do not reuse or carry forward conclusions from reviews of Required focus:
Exact-head PostgreSQL 16 evidence: run Please classify every finding P0/P1/P2/P3. Any P0/P1 blocks merge. If no findings remain, indicate the exact reviewed commit explicitly. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 544b694f69
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ELSE 'HEALTHY' END overall_health | ||
| FROM b | ||
| LEFT JOIN bu ON bu.repository=b.repository AND bu.build_id=b.latest_merged_build | ||
| LEFT JOIN v_ci_health ci ON ci.repository=b.repository AND ci.build_id=b.latest_merged_build |
There was a problem hiding this comment.
When a later build_status snapshot changes implementation_sha while retaining the active build_id—a transition the fixture itself demonstrates for BUILD-X in tests/s-health.sql—this build-ID-only join can reuse an earlier successful CI run for the old implementation. A clean review for the new SHA plus the existing build-scoped integrity evidence can then make the repository HEALTHY even though the active implementation never ran CI. The fresh evidence in this head is migration 005's new join, which binds CI to the baseline build but not to bu's active implementation SHA.
Useful? React with 👍 / 👎.
| count(a.*) FILTER(WHERE a.required) required_count, | ||
| count(a.*) FILTER(WHERE a.required AND a.status IN('MISSING','HASH_MISMATCH','SIZE_MISMATCH')) blocked_count, | ||
| count(a.*) FILTER(WHERE a.required AND a.status='UNVERIFIED') unverified_count |
There was a problem hiding this comment.
For a required artifact recorded as status='PASS' while expected_sha256 <> observed_sha256, expected_bytes <> observed_bytes, or an observed value is absent, these counters classify the active build as HEALTHY because they inspect only the caller-supplied status. Since the table has no constraint enforcing consistency between that status and the recorded measurements, a malformed or buggy ingestion violates the required fail-closed hash/size semantics; either validate the measurements here or reject inconsistent rows on insert.
Useful? React with 👍 / 👎.
Implements BUILD-CLP-001-S v1.0.1 as an observability-only successor to merged R.
Parent baseline:
b0f19f2d0ce8a086604ed1f08d1202cd5650dae8Exact current review head:
544b694f69796631ed17a5cdfa4184a88b33f2f4Scope:
edopsys_observabilityPostgreSQL schemav_dashboard_summary_jsonfor future dashboard consumersG0-STATUS.jsonAuthority boundary:
Observability projections are descriptive and MUST NOT authorize CLP state transitions, worker eligibility, verification, payout, or policy execution.
Frozen source integrity:
1.0.11f108d86ca0166c2c6ec018ca46bf589428b60969027ac2e35e8bfaccff9e68a3a4f1fffb11d48ed4207e348172337674b1eb961a1dae9af347c40632985f55eIndependent-review remediation history:
9daa6fad704f0a20eceb2ff0fa627249cc0d86745407624020Final exact-head PostgreSQL 16 evidence:
37226447568544b694f69796631ed17a5cdfa4184a88b33f2f4S_T1_T14_CANONICAL_BINDING_PASS)DEGRADED|0|CURRENT|HEALTHY|PASS|HEALTHY|HEALTHY|DEGRADED|HEALTHYFinal merge gates:
37226447568.544b694f69796631ed17a5cdfa4184a88b33f2f4with no unresolved P0/P1: PENDING.Explicit exclusions remain unchanged: resident UI, worker UI, marketplace, payments, social/community, gamification, production identity federation, and expanded AI authority.
Do not merge until gates 2 and 3 are satisfied.