[Governance] Fail closed before protected merges on non-qualifying review/source/coverage evidence

[seonghobae]

Governance incident

Fresh protected-state evidence shows that develop@942d164ceb7af497bb28a95f842db96429d1bdc4 was produced by merged PR #245 even though the final PR source did not satisfy mightyETL's stated protected-integration evidence contract.

Exact incident identities:

• merged PR: fix(config): apply aliases after ConfigData #245, fix(config): apply aliases after ConfigData;
• final source head: 29c0deb678651c3cae75e9a8bd8c33c63631da8e;
• then-live base: develop@c2511f6b9d716ef9ab8de60a91fffd826714a4c5;
• GitHub synthetic PR merge actually checked out by CI: edd9d3daa4581cd7fc14efcf24e56a847a7c542e (Merge 29c0deb... into c2511f6...);
• protected merge result/current-at-incident develop: 942d164ceb7af497bb28a95f842db96429d1bdc4;
• formal pull-request reviews on fix(config): apply aliases after ConfigData #245 at fresh re-read: zero;
• final-head workflow aggregates: CI, Dependency Review, SBOM, Semgrep, and Security Scan all terminal-success;
• CI's JaCoCo output on the admitted tree: Analyzed bundle 'etl-service' with 0 classes followed by All coverage checks have been met.

This issue does not claim the ConfigData behavior itself is defective. It records that the protected merge-admission boundary accepted evidence that repository policy explicitly classifies as non-qualifying: no independent non-author formal approval, synthetic-merge-only source execution, and vacuous zero-production-class coverage.

Fresh live enforcement evidence — 2026-08-13

The repository connector can now read the active repository rulesets even though direct classic branch-protection detail remains restricted. Fresh state was resolved against protected develop@4408b6086fd725ff1629d8f048cf28f3a2b40b1b.

• Ruleset 11709659 (PR) is active on ~DEFAULT_BRANCH. It blocks deletion/non-fast-forward updates and requires pull requests plus review-thread resolution, but required_approving_review_count is 0, required_reviewers is empty, require_code_owner_review=false, require_last_push_approval=false, and it declares no bypass actors.
• Ruleset 11709665 (Review) is active on ~ALL. It blocks deletion/non-fast-forward updates and enables Copilot code review on push/draft PRs, but it does not establish qualifying independent formal approval as a merge requirement.
• The branch endpoint reports develop as protected: true while its summarized classic-protection payload has protection.enabled=false and required status-check enforcement off with no contexts/checks. Direct GET /branches/develop/protection returns 403 Resource not accessible by integration, so administrator restrictions and any classic-protection detail not represented by the branch summary remain unproven.
• Both readable rulesets report bypass_actors: [] and current_user_can_bypass: never; this disproves the earlier need to guess whether the observed ordinary-path gap is caused by an explicit ruleset bypass actor. It does not prove there are no other organization/enterprise/classic protection mechanisms invisible to this integration.

The first demonstrated failing boundary is therefore concrete: the active PR ruleset itself permits zero approving reviews, and the readable branch summary does not enforce required status checks. That is sufficient to explain why the repository-level documented policy is stronger than the currently observable default-branch admission controls without inventing an administrator bypass.

RCA

• Immediate cause: GitHub permitted the merge while the evidence set lacked a qualifying formal approval and still contained known non-qualifying source-identity/coverage semantics.
• Technical root cause: the repository's documented merge policy is stronger than the currently observable enforced controls. The active default-branch PR ruleset requires zero approving reviews, while the readable branch summary exposes no required status-check contexts. Current hosted PR CI also checks the synthetic merge ref, and the current protected JaCoCo selector can pass an empty production bundle.
• Systemic cause: exact-source control (ci: schedule NVIDIA OpenCode maintenance agent #121), non-vacuous coverage ([Quality gate] Make JaCoCo fail closed when production class selection is empty #162/fix(coverage): make JaCoCo production gate non-vacuous #164), complete coverage authority ([Quality evidence] Extend non-vacuous 100% coverage to every owned production module #205), and vulnerability-graph completeness ([Security evidence] Fail closed when Trivy cannot resolve Maven BOM-managed dependency versions #196) are tracked as work items, but protected merge admission can currently occur before those controls become accepted required evidence.
• Residual observability limit: direct classic branch-protection detail is inaccessible to this integration. Do not infer administrator restrictions or other organization/enterprise controls beyond the rulesets and branch summary actually returned.

Distinct remedies / feasibility

1. Preferred — enforce qualifying evidence at the protected branch/ruleset boundary. After ci: schedule NVIDIA OpenCode maintenance agent #121 and fix(coverage): make JaCoCo production gate non-vacuous #164 (or accepted equivalents) are integrated, configure the protected default-branch admission policy to require at least one qualifying independent non-author formal approval plus the accepted exact-source, non-vacuous coverage, security, dependency, SBOM/SAST and other required checks. The current connector can verify rulesets but exposes no safe ruleset-mutation action, so this setting change is external_only from this automation rather than a reason to weaken repository-local policy.
2. Repository-local admission control. Add a deterministic governance check that classifies source identity, coverage non-vacuity, stale-head reviews, and independent approval fail-closed. This is useful only if the protected branch actually requires the resulting check; do not create a decorative workflow that can be bypassed.
3. Bypass governance. Inspect any remaining classic/organization/enterprise bypass or administrator authority with suitable repository-administration access, constrain it according to the accepted emergency policy, and retain auditable evidence for exceptional protected merges. Do not infer that administrator capability itself is an accepted bypass policy.
4. Reject — retroactive evidence repair. A review submitted after merge, checks from another head/base, self-approval, a CodeRabbit status, or a synthetic merge success cannot be used to rewrite the historical admission decision as compliant.
5. Reject — weakening the policy. Do not remove the independent-review, exact-source, non-vacuous coverage, scanner-completeness, or security gates merely because current settings do not enforce them.

Acceptance

Close only after fresh evidence proves all applicable protected-integration controls are actually enforced, not merely documented:

1. live develop branch protection/ruleset and bypass authority are inspected and recorded without secrets;
2. a PR with zero qualifying independent formal approvals cannot be merged through the ordinary protected path;
3. head movement invalidates/requires regeneration of source-bound review/check evidence according to the accepted governance policy;
4. the required CI source identity is the accepted literal source identity, or another explicitly reviewed equivalent whose identity semantics cannot be confused with GitHub's mutable synthetic PR merge ref;
5. a JaCoCo run selecting zero governed production classes is hard non-green;
6. applicable owned-production coverage is non-vacuous and the complete scope tracked by [Quality evidence] Extend non-vacuous 100% coverage to every owned production module #205 cannot silently omit a production module/class;
7. scanner incompleteness such as [Security evidence] Fail closed when Trivy cannot resolve Maven BOM-managed dependency versions #196 is non-passing even when the aggregate vulnerability count is zero;
8. current dependency review, SBOM, SAST, security, migration/compatibility and other repository-required checks are bound to the same unchanged candidate identity;
9. ordinary maintainer/admin merge tooling cannot silently bypass the required evidence; any deliberately retained emergency bypass is narrowly authorized and auditable;
10. a negative acceptance probe demonstrates that missing review/source/coverage evidence blocks a protected merge before this issue is closed;
11. canonical Test Strategy, Security/Operability/Release governance and Traceability point to the executable controls without promoting active-PR behavior to shipped truth.

Sequencing / writer safety

Do not race #121 or #164 merely to react to this incident. Those branches own the current exact-source and coverage-control implementations. This issue owns the protected admission-enforcement gap and the historical #245 evidence. Waiting for those specific control branches never blocks independent mightyETL product/security/reliability work.

Relationships: #121 exact-source execution; #162/#164 non-vacuous coverage; #205 repository-wide coverage completeness; #196 vulnerability-evidence completeness; #159 canonical governance traceability; #165 release/provenance.

[seonghobae]

Fresh governance probe adds two current facts relevant to the protected-admission acceptance criteria.

1. The live ci: schedule NVIDIA OpenCode maintenance agent #121 ref is now 2a4053c58c461de94bed61278abfa967b7a363ad, while its PR body still names predecessor source head 75265fae9fcf5faac6f8b9cab63247ac86f23dd4. This is concrete proof that PR-body identity claims are historical evidence and cannot substitute for live ref/check/review binding.
2. On live ci: schedule NVIDIA OpenCode maintenance agent #121, formal reviews are still COMMENTED-only: there is no independent non-author APPROVED review. The current exact-head CodeRabbit review also has unresolved, non-outdated findings, including a major duplicate workflow-run approval failure mode in authorize-exact-head-checks and a Dockerfile pinning-test bypass for indented FROM instructions. Therefore an aggregate-green check set must not be interpreted as gate-clean when valid exact-head review findings remain unresolved.

The live protected tip remains develop@942d164ceb7af497bb28a95f842db96429d1bdc4. The connector still exposes no branch-protection/ruleset/bypass read API, so the enforcement mechanism remains an external/read_only_dependency rather than a guessed repository-local fact. No attempt was made to weaken protection, self-approve, or mutate the actively moving #121 branch.

[seonghobae]

Fresh recurrence evidence from protected history: current develop is now 106add38465937f6eb4e4accc185fd30aab4446f, reached through merged PRs #275 (d7054ae0ac579b8ce27fe559f937e99be3459a40), #273 (8dbea18c...), #271 (58667621...), and #269 (106add384...). Fresh formal-review queries for #269, #271, #273, and #275 each return zero pull-request reviews. This independently reproduces the core #252 admission defect after the original #245 incident: protected develop can continue advancing through ordinary merged PRs without a qualifying independent non-author formal approval. Do not retroactively treat those merges as compliant; no later review can repair the historical admission evidence. Branch-protection/ruleset/bypass configuration remains unobservable through the current GitHub connector, so the enforcement-path cause is still not guessed. The negative acceptance requirement in this issue remains mandatory: once #121/#164 (or accepted equivalents) are integrated, prove at the protected admission boundary that zero-approval candidates cannot merge and that exact-source/non-vacuous/scanner-complete gates are actually required.

[seonghobae]

Fresh protected-operability probe on exact current develop@106add38465937f6eb4e4accc185fd30aab4446f: the GitHub connector's commit-bound workflow-run query returns zero pull-request-associated workflow runs for the protected merge commit itself. This does not prove that no workflow of any event type ever ran, because the connector wrapper currently filters this query to pull-request-triggered runs; it does prove that the current exposed evidence set contains no direct protected-head PR-run acceptance that can be substituted for the candidate-head/synthetic-merge evidence already discussed here. Keep post-merge operational acceptance and source identity separate: a green pre-merge synthetic ref plus a protected merge commit with no exposed same-identity PR run is not same-revision protected-head proof. Branch-protection/ruleset/bypass settings remain unobservable through this connector, so no enforcement mechanism is inferred from this absence.

[seonghobae]

Fresh live governance evidence narrows the #252 RCA materially.

• Protected develop is currently 106add38465937f6eb4e4accc185fd30aab4446f.
• Repository ruleset 11709659 (PR) is active on the default branch and requires a pull request plus review-thread resolution, but required_approving_review_count is 0 and require_last_push_approval is false.
• Organization ruleset 18156473 (CWL Central required workflows) is also active on the default branch. Its PR rule likewise has required_approving_review_count 0; it requires the central review/security workflows including .github/workflows/pr-review-merge-scheduler.yml.
• Read-only inspection of the exact central .github main@6eb06cdd08c79a06f7b390069d4ffa49e2eb7dba shows scripts/ci/pr_review_merge_scheduler.py defines has_current_head_approval() specifically as an exact-current-head OpenCode APPROVED review, where the recognized review author is opencode-agent / opencode-agent[bot], and uses that automated approval as a merge/auto-merge prerequisite.

Therefore the earlier governance-control uncertainty is no longer accurately described as “ruleset state unavailable.” The observable enforcement path does not itself require a qualifying independent non-author human/formal approval: both live pull-request rules require zero approvals, while the central required scheduler treats an OpenCode bot approval as its current-head approval gate. That is weaker than mightyETL's documented protected-integration contract and is consistent with the historical #245 zero-formal-review incident.

This writer remains read-only for ContextualWisdomLab/.github, and the available GitHub connector exposes ruleset reads but no safe ruleset mutation action. Classify the direct enforcement repair as read_only_dependency / external_only for this loop rather than weakening mightyETL policy or manufacturing an approval.

Acceptance should retain a falsifiable negative probe after the control-plane repair: an otherwise gate-clean exact-head PR with zero qualifying independent non-author formal approvals must be demonstrably blocked from ordinary protected integration, and OpenCode/status-only evidence alone must not satisfy that requirement. Exact-source (#121), non-vacuous coverage (#162/#164/#205), scanner completeness (#196), review-thread, security and other same-head gates remain independent dimensions.

[seonghobae]

Fresh protected-governance reinspection on develop@ae4efe6b2c65fb6353bb81ace618bb03c42d3081 resolves the ruleset uncertainty recorded in this issue.

Observed active rulesets:

• repository ruleset PR (11709659) applies to the default branch and requires PR use + review-thread resolution, but required_approving_review_count is 0, require_code_owner_review=false, and require_last_push_approval=false; no bypass actors are configured there and the current user cannot bypass that repository ruleset;
• repository ruleset Review (11709665) requires Copilot code review on pushes/draft PRs, but it does not impose a qualifying independent formal approval gate;
• organization ruleset CWL Central required workflows (18156473) applies to the default branch and requires the central workflow set plus PR/thread resolution, but again has required_approving_review_count=0; it also configures OrganizationAdmin with bypass_mode=always, and the current authenticated admin reports current_user_can_bypass=always for this organization ruleset;
• the legacy branch-protection payload remains disabled/empty, so the active enforcement authority is the ruleset set above.

This makes the governance root cause concrete: current executable protected-branch policy does not enforce the repository's stated qualifying independent non-author APPROVED requirement, and an organization-admin bypass path exists. This is not evidence that the bypass was used for any particular historical merge; it is evidence that ordinary ruleset configuration currently permits zero-approval PR admission and that an always-bypass actor class exists.

Acceptance item 1 is now evidenced. Items 2/9 remain non-passing under the current rule configuration. Do not close until a negative probe shows zero-approval admission is blocked by the accepted protected path, the intended review/source/coverage/security controls are actually required, and any retained emergency bypass is narrowly governed/auditable.