Repository navigation
Replay focused central improvements after #731 restores the baseline #742
Description
Purpose
Drain stale central pull requests without losing validated product and governance work. PR #731 is the sole bootstrap prerequisite: it restores CodeQL action consistency, clears Strix dependency advisories, and repairs the stale-base-lock coverage classifier. Once #731 lands, replay each item below from the new main as a small, current-head PR with no dependency-lock or unrelated workflow history.
Ordered replay queue
- fix(automation): run securely pinned review repair every hour #704 — hourly, immutable-source review-feedback repair. Preserve exact cadence, one-dispatch bound,
job.workflow_shasource binding, and focused contracts. - fix(ci): bound anonymous review provider budget #722 — bound the aggregate anonymous reviewer budget while preserving keyed fallbacks.
- fix(review): defer R coverage on any declared dependency, not only Suggests #721 — R coverage deferral for declared
Depends/Imports/LinkingTo/Suggests, still requiring a successful same-head R CMD check. - fix(security): redact sandboxed CI evidence without secret-bearing history #711 — redact sandbox verification stdout/stderr/timeouts/log tails with fail-closed shared imports.
- fix(scheduler): accept safe Unicode branch refs #696 — accept Git-valid Unicode refs while retaining control/separator/path traversal and ref-format rejections.
- fix(security): eliminate clean-scan warning output #690 — warning-free clean security scans using current upstream CLI contracts.
- fix(review): expose cross-repository dispatch failures #692 — visible exact-head review-tool failure receipts without granting approval.
- fix(strix): include search authorization context #697 — bounded Strix authorization context for search UI changes.
- fix(strix): supply sibling SQL migrations as PR-scope context #608 — sibling SQL migration context for scoped Strix analysis.
- fix(security): Strix provider 장애를 fail-closed로 유지 #587 — preserve fail-closed Strix behavior when providers are unavailable.
- ⚡ Bolt: [성능 개선] 파일 내용을 가져오는 과정의 병렬화 (N+1 API 병목 현상 완화) #684 — parallel Noema file-context collection only with deterministic ordering, bounded workers, failure equivalence, and measured latency improvement.
- docs(profile): refresh buyer-facing product catalog #705 — buyer-facing organization profile refresh.
- feat(automation): run naruon commercial readiness hourly #709 — Naruon hourly commercial-readiness loop, rebuilt as the smallest source-pinned workflow set and retaining product-code tests plus
CHANGELOG.mdrequirements. - fix(strix): retry artifact-less provider crashes without weakening exhaustion #734 — retry artifact-less Strix provider crashes through a bounded fallback chain while preserving fail-closed exhaustion and every real finding artifact.
- fix(ci): snapshot dependencies on default-branch pushes so dependency-review has a base #736 — submit dependency snapshots on protected-branch pushes with commit-specific concurrency so dependency-review has a valid base graph.
- docs(agents): record code-owner gate hold for solo maintenance #740 — record the solo-maintainer CODEOWNERS hold only in the organization-central agent policy, preserving all other approval and required-check rules.
- build(deps): bump google/osv-scanner-action/.github/workflows/osv-scanner-reusable-pr.yml from 3a7550f43ba5b58905a821ce3a0ed24c4858b3f4 to 9fd1bcce27f67e3bd819a0a7620e332803dc43bc #595 — advance the pinned OSV reusable workflow to the upstream hardening/GOTOOLCHAIN revision after revalidating its immutable nested-action contract.
- build(deps): bump huggingface-hub from 1.20.0 to 1.23.0 #551 — refresh the Strix lock to a compatible current
huggingface-hub/Click closure only after regenerating from post-fix(ci): restore central review, security, snapshots, and hourly repair #731 requirements and rerunning Python security checks. - fix(deps): protobuf를 aiplatform 호환 범위로 유지 #549 — retain the
protobuf<7Dependabot exclusion whilegoogle-cloud-aiplatformrequires that compatibility range; implement from a clean branch rather than the long-lived Dependabot history.
Acceptance contract for every replay
- branch from post-fix(ci): restore central review, security, snapshots, and hourly repair #731
main; - one coherent concern per PR;
- exact-current-head required checks and independent App review;
- 100% statement and docstring coverage for changed central Python code;
- immutable action/source pins and least-privilege permissions;
- no copied leaf-repository policy when organization-central policy is authoritative;
- no manual success status, bypassed review, or weakened security threshold.
Queue policy
Close the superseded long-lived PRs after linking them here. Their branches remain available as implementation references, but their stale check/review histories are not merge evidence. Keep only #731 as the active central bootstrap PR; clean successors such as draft #743 may remain staged without competing for merge readiness.
Activity
seonghobae commentedon Aug 17, 2026
Orgmetra consumer evidence for replay item #608 (sibling SQL migration context for scoped Strix analysis):
e3d7dffb8c74eeeb239c46953c309040953f8a9c32018419401, job/check95352732202, terminal failuredatabase/migrations/0010_validity_study_case_integrity.sql, saw its new INSERT guards for the three legacy validity-study link tables, and reported that UPDATE/DELETE remained possible. The scoped context omitted the unchanged sibling baseline migration that already owns those guards.database/migrations/0001_foundation_schema.sqlat the exact consumer head already definesvalidity_study_decision_append_only_guard,validity_study_outcome_append_only_guard, andvalidity_study_evidence_append_only_guard, eachBEFORE UPDATE OR DELETEon the corresponding legacy link table and each executingreject_append_only_mutation(). Migration 0010 does not remove or replace those triggers. The reported UPDATE/DELETE path therefore does not exist in the composed migration state.RED acceptance regression for central owner: use a PR fixture whose later SQL migration adds a new INSERT-only transition guard to an existing table while an unchanged earlier migration already supplies UPDATE/DELETE append-only triggers. Scoped Strix context must include the materially relevant sibling migration/DDL state and must not report the absent-update/delete finding. Negative control: when the trusted baseline truly lacks those triggers, the finding must remain visible/fail closed.
Smallest root-cause remedy: replay #608's bounded sibling-SQL-migration context selection from the trusted base, preserving changed-file finding attribution, exact-head/base provenance, context bounds, and fail-closed behavior. Required GREEN proof: focused/full central tests plus a fresh unchanged-head Strix run for Orgmetra#26 that sees the prior migration state; do not convert the current failed run or any status-only/predecessor evidence to passing.
seonghobae commentedon Aug 17, 2026
Fresh required-workflow bootstrap recurrence from Orgmetra consumer evidence (2026-08-17 UTC). This is a central/runner action-materialization resilience boundary, not an Orgmetra source finding.
dd43f5a2e191b2b4570433975fcc93e310d074e0: required SAST run32042712733, job95424825333, failed in Set up job before Semgrep executed because immutablestep-security/harden-runner@bf7454d06d71f1098171f2acdf0cd4708d7b5920could not be downloaded fromcodeload.github.comafter three HTTP 429 attempts. Required Security Scan run32042712705:dependency-review,scorecard, andtrivy-fspassed; only OSV job95424795205failed in Set up job becausegoogle/osv-scanner-actionimmutable action downloads hit repeated HTTP 429 and one 502 across the primary/fallback SHAs, before OSV executed.39863cd34e6398b7d8ae88841379139dab6932d9independently records the same class across Security/SAST/Strix: external immutable-action codeload 429/502 during job setup, before scanners/reviewer ran.Please treat this as acceptance evidence for a bounded central robustness replay: preserve immutable provenance and fail-closed semantics while making required workflows resilient to transient action-materialization failures without leaf churn. RED acceptance should reproduce action-download 429/502 separately from scanner/reviewer execution; GREEN should prove bounded, integrity-preserving recovery or an explicit typed infrastructure failure that is not synthesized into source findings. Consumer acceptance requires fresh unchanged-head reruns on Orgmetra after the central owner repair, with the real scanner/reviewer stages actually executing.
seonghobae commentedon Aug 17, 2026
Fresh Orgmetra consumer recurrence for the central Required Noema reviewer resilience boundary:
ContextualWisdomLab/Orgmetra#32exact head0bc367c976c79722532798e5d83e00d6b2219cfb.32049470971, exact job95445095397, trusted central workflow SHAc47afc2dc68488292c1db7c9d6f82dcd5360f181.cwl-noema-reviewGitHub App token minted successfully; target repository visibility resolved successfully; reviewer model configuration was present. The first failing boundary was inside the trusted centralscripts/ci/noema_review_gate.pypath when itsghsubprocess attempted the GitHub API and receivedHTTP 503: No server is currently available to service your requestat2026-08-17T17:24:46Z. The reviewer exited 1 before producing a verdict.RED acceptance for the central owner: deterministically inject one transient GitHub API 503 into the exact trusted Noema API-read/subprocess boundary followed by a successful response. The gate should retry only a closed set of transient transport/server failures with bounded attempts/backoff, preserve exact repository/PR/head provenance and reviewer credentials, discard failed-attempt output, and then complete the real review. Repeated transient failures must stop at the ceiling; authentication/authorization errors, malformed responses, provenance mismatches, and other non-transient failures must still fail closed without retry.
Smallest root-cause remedy: add bounded transient-retry handling around the trusted Noema GitHub API operation rather than altering consumer workflows or source. Required GREEN proof: focused/full central tests with exact coverage plus a fresh unchanged-head consumer run for Orgmetra#32 in which Required Noema reaches the actual review/verdict path successfully; do not convert this failed run or status-only/predecessor evidence to passing.
seonghobae commentedon Aug 17, 2026
Fresh Orgmetra consumer evidence for the central independent-approval delivery boundary (related to replay item #740, but this is the generic protected-branch approval gate rather than CODEOWNERS itself):
ContextualWisdomLab/Orgmetradevelopexact headd531ba0fbb0d1cb70dbaa6b5c6b0431e59cc4c22.18156473(CWL Central required workflows) targets the default branch and currently requiresrequired_approving_review_count=1, dismisses stale reviews on push, requires approval of the most recent push, requires review-thread resolution, retains all seven central required workflows, has no bypass actors, and reportscurrent_user_can_bypass=never.seonghobaewith repository administration/push rights; there is no second human collaborator to provide an independent non-author approval.6ecebbb59b4873a95d31e26cac334c4999a6dc36, is authored byseonghobae, mergeable, and has noAPPROVEDreview. Its formal review history contains only a CodeRabbitCOMMENTEDreview plus an authorCOMMENTEDreview; the CodeRabbit finding thread is already resolved. Draft PRs 🧹 [코드 건강성 개선] 파이썬 스크립트 미사용 모듈 임포트 제거 #26 (3e810900a96fd5ed78264ea16cb7c335b2e9e279) and 🧪 테스트 개선: opencode_review_normalize_output의 valid_control 로직에 대한 단위 테스트 추가 #30 (c216e3fa33bed0481e130ffcc18cb2b34b71dec1) are likewise authored byseonghobae, so the same gate will apply once their dependency/check lanes become ready.Please treat this as a central owner canary: determine whether the existing independent reviewer App/automation is intended and technically able to submit a GitHub formal
APPROVEDreview that GitHub counts under this ruleset for an unchanged exact head. If not, provision/route a genuinely independent eligible reviewer identity/team/App through the existing organization governance boundary without weakening the rule.RED acceptance: an unchanged Orgmetra test PR authored by the sole maintainer, with every required workflow green and all threads resolved, remains merge-blocked before a qualifying independent review. GREEN acceptance: the central review path requests or submits an eligible non-author
APPROVEDreview after the last push, GitHub recognizes it for that exact head, and the approval gate clears whilerequired_approving_review_count=1, last-push approval, thread resolution, all seven required workflows, and no-bypass policy remain intact. Negative controls: author/self review,COMMENTEDreviews, stale/predecessor approvals, or reviewer identities lacking eligibility must not satisfy the gate.seonghobae commentedon Aug 18, 2026
Fresh consumer evidence identifies an additional central SAST false-positive lane that should be repaired at the central scanner/policy boundary, not worked around in the leaf.
Affected consumer:
ContextualWisdomLab/context-graph-contracts#4.Exact identities at verification:
8c5653ea2d7728b6b193d99466bf7f6de6d1d0dadevelop@99cb5468ba3c15c5e79688f53dee74724fae2d13482982f745b2b580f69236b0cd9105a2c1fc04c432088517351955659095311.169.0First failing boundary: organization-provided
SAST Semgrepappliedpython.lang.compatibility.python37.python37-compatibility-importlib2four times to legitimatefrom importlib.resources import filesimports in packaged-resource modules. The repository itself contains no.github/workflows/sast-semgrep.ymlat this exact head, confirming this is not a leaf-owned workflow. Itspyproject.tomlexplicitly declaresrequires-python = ">=3.11", classifiers 3.11–3.14, and Rufftarget-version = "py311". Therefore requiring theimportlib_resourcesbackport would add an unsupported-floor compatibility dependency solely to satisfy a Python-3.7 rule and would be the wrong-layer product change.Observed findings:
src/cwl_context_contracts/conformance/__init__.py:6src/cwl_context_contracts/contracts/__init__.py:6src/cwl_context_contracts/fixtures/__init__.py:6src/cwl_context_contracts/schemas/__init__.py:6Falsifiable RCA: the central generic Semgrep policy is evaluating a Python-3.7 compatibility rule without respecting the repository's declared minimum supported interpreter. RED acceptance should include a fixture/repository with
requires-python >=3.11and stdlibimportlib.resourcesusage that currently fails this rule, plus a negative control whose declared supported floor genuinely requires the backport. Smallest safe remedy: make central compatibility-rule selection/triage honor an authoritative project Python floor (or otherwise suppress only logically inapplicable compatibility rules through a deterministic reviewed policy), while preserving all security rules and failing closed when the floor is absent/ambiguous. GREEN proof: focused central contract test + full central suite + fresh exact-head SAST on unchanged/descendantcontext-graph-contracts#4, where these four unsupported-floor findings disappear while genuine applicable Semgrep findings remain blocking.Do not ask the consumer to add
# nosemgrep, weaken its Python floor, or addimportlib_resourcesmerely to turn the required check green.seonghobae commentedon Aug 18, 2026
Context Fabric dependency evidence for the central security replay queue (do not treat as leaf-owned suppression):
ContextualWisdomLab/context-graph-contracts#4exact head8c5653ea2d7728b6b193d99466bf7f6de6d1d0da, exact PR merge candidate checkout482982f745b2b580f69236b0cd9105a2c1fc04c4, centralSAST Semgreprun32088517351/ job95565909531fails with 4 instances ofpython.lang.compatibility.python37.python37-compatibility-importlib2onimportlib.resourcesin the packaged resource loaders. The project metadata/current docs support Python 3.11-3.14, and repository-native CI32088517330is terminal success on that exact head, so the Semgrep Python-3.7 compatibility rule is inapplicable to this repository's declared runtime floor rather than evidence of a product compatibility defect.First failing boundary: central
p/defaultSemgrep policy applies a Python <3.7 compatibility rule without conditioning it on the leaf package's declaredrequires-python >=3.11; step 9 then fail-closes Medium+ findings. Reproduction is the exact run/job above; findings are insrc/cwl_context_contracts/{conformance,contracts,fixtures,schemas}/__init__.pyline 6.Requested central-owner remedy/acceptance: preserve fail-closed Medium+ gating, but make compatibility rules respect an executable/declared language-version floor (or use a narrowly justified central suppression for this rule only when the repo proves
requires-python >=3.7). RED acceptance should exercise a repo fixture declaring >=3.11 and proveimportlib.resourcesdoes not fail the gate, while an actually unsupported import relative to the declared floor remains blocking. GREEN proof must be a fresh central workflow run on the same unchanged leaf head/candidate with zero unsuppressed WARNING/ERROR findings. Context Fabric revalidation criterion: rerun/freshly dispatch the central SAST on the then-current #4 exact candidate and require terminal success; do not weaken the threshold or add leaf nosemgrep comments merely to silence this false-positive.seonghobae commentedon Aug 18, 2026
Context Fabric downstream evidence for the queued central security-scan cleanup lane (#690):
ContextualWisdomLab/context-graph-contracts#4exact head8c5653ea2d7728b6b193d99466bf7f6de6d1d0dahas repositorycirun32088517330,supply-chainrun32088517312, andSecurity Scanrun32088517298terminal success, but centralSAST Semgreprun32088517351/ job95565909531fails on four instances ofpython.lang.compatibility.python37.python37-compatibility-importlib2solely because the leaf correctly imports stdlibimportlib.resourcesinsrc/cwl_context_contracts/{conformance,contracts,fixtures,schemas}/__init__.py. The product's declared/tested interpreter floor is Python 3.11, with CI through 3.14, so the rule's pre-3.7 compatibility premise is outside the supported runtime contract. This is not clean security evidence and must remain fail-closed, but changing leaf code to an obsolete backport or suppressing all Medium+ findings would be the wrong causal layer.Required central acceptance for the #690 replay: add a deterministic RED canary for a repository declaring
requires-python >=3.11that importsimportlib.resources; select/configure compatibility rules against the repository's declared supported interpreter floor (or otherwise exclude only demonstrably inapplicable compatibility rules) without muting unrelated WARNING/ERROR findings; prove a genuinely applicable compatibility finding still blocks; then rerun the unchanged downstream candidate or its then-current exact head and require Semgrep terminal success with zero unsuppressed applicable Medium+ findings. Preserve immutable scanner/action pins, SARIF upload, finding logging, least privilege, and fail-closed engine/configuration failure semantics.