fix(coverage): unblock org-wide OpenCode approval + docs(gaps) corrections

.github/workflows/noema-review.yml

@@ -189,6 +189,14 @@ jobs:
   noema-review:
     name: noema-review
     runs-on: ubuntu-latest
+    # Explicit, not just the platform's own 360-minute (6h) default for
+    # unset timeout-minutes: NOEMA_LLM_TOTAL_BUDGET_SECONDS (19800s = 5.5h,
+    # scripts/ci/noema_review_gate.py) already budgets this job against that
+    # ceiling and relies on ~30 minutes of margin for checkout, credential
+    # minting, and posting the review; stating it here makes the relationship
+    # auditable/testable instead of implicit (Devin Review,
+    # ContextualWisdomLab/.github#1438).
+    timeout-minutes: 360
     if: >-
       github.event_name == 'repository_dispatch'
       || (

.github/workflows/strix.yml

@@ -167,15 +167,19 @@ jobs:
   strix:
     if: github.event_name != 'pull_request_target' || github.event.action != 'closed'
     # Large, actively-growing repositories (e.g. contextual-orchestrator) can
-    # legitimately require well over two hours to scan -- this org's own
-    # standing operating directive accepts that central OpenCode/Strix/Noema
-    # scans may take more than two hours per model (docs/product-goal-directive.md).
-    # The scanner gets a 150-minute process budget and a 155-minute total
-    # retry budget; the 170-minute step and 200-minute job leave deterministic
-    # time to preserve partial reports and publish a concrete failure reason.
-    # Hitting any cap is fail-closed and never turns an incomplete scan into
-    # an approval.
-    timeout-minutes: 200
+    # legitimately require several hours to scan -- the standing operating
+    # directive already accepts central Strix/OpenCode/Noema scans taking
+    # more than two hours per model (docs/product-goal-directive.md), and the
+    # repo owner separately raised the floor to at least three hours, with
+    # real observed runs well past that (owner comment, ContextualWisdomLab/.github#1438,
+    # 2026-09-01). The scanner gets a 310-minute process
+    # budget and a 315-minute total retry budget; the 330-minute step and
+    # 360-minute job leave deterministic time to preserve partial reports and
+    # publish a concrete failure reason. 360 minutes is also the maximum job
+    # execution time GitHub-hosted runners allow, so the job timeout itself
+    # cannot go any higher on ubuntu-latest. Hitting any cap is fail-closed
+    # and never turns an incomplete scan into an approval.
+    timeout-minutes: 360
     runs-on: ubuntu-latest
     # Least-privilege token scoped to this job (Scorecard alert #43): the scan
     # exchanges an OIDC token (id-token) and publishes same-repo status evidence
@@ -729,7 +733,7 @@ jobs:
 
       - name: Run Strix (quick)
         if: steps.gate.outputs.enabled == 'true'
-        timeout-minutes: 170
+        timeout-minutes: 330
         # Security invariant for pull_request_target: execute only from the
         # trusted base checkout. The gate copies PR-head blobs into an isolated
         # temporary scope with execute bits stripped, then scans that scope as
@@ -771,11 +775,11 @@ jobs:
           IS_PR_EVIDENCE_RUN: ${{ (github.event_name == 'pull_request_target' || github.event.client_payload.pr_number != '') && 'true' || 'false' }}
         run: |
           budget_suffix="TIME""OUT"
-          process_budget_seconds="9000"
+          process_budget_seconds="18600"
           export "LLM_${budget_suffix}=900"
           export "STRIX_MEMORY_COMPRESSOR_${budget_suffix}=300"
           export "STRIX_PROCESS_${budget_suffix}_SECONDS=$process_budget_seconds"
-          export "STRIX_TOTAL_${budget_suffix}_SECONDS=9300"
+          export "STRIX_TOTAL_${budget_suffix}_SECONDS=18900"
 
           # Recognized signals that the LLM backend was unavailable / starved.
           # Defined before the gate loop so the bounded retry decision below
@@ -802,14 +806,20 @@ jobs:
           # provider failures do not fail the required check on the first
           # attempt. Genuine findings, configuration failures, and unexpected
           # exit codes never retry; the deadline keeps every path inside the
-          # deterministic 200-minute job budget, and all-terminal outcomes
-          # remain fail-closed.
+          # deterministic 330-minute step budget (within the 360-minute job),
+          # and all-terminal outcomes remain fail-closed. The 3-attempt cap
+          # below is a ceiling, not a guarantee: the remaining-time guard only
+          # allows a retry when enough of the deadline is left to reserve
+          # another full process_budget_seconds attempt, so only early
+          # failures actually get to retry -- an attempt that itself
+          # consumes most of its budget before failing has already spent the
+          # time a retry would need.
           strix_run_log="$RUNNER_TEMP/strix_gate_console.log"
           : > "$strix_run_log"
           strix_terminal_log="$strix_run_log"
           strix_rc=0
           strix_gate_attempt=1
-          strix_gate_deadline=$(( SECONDS + 9600 ))
+          strix_gate_deadline=$(( SECONDS + 19200 ))
           # Reserve the scanner process budget, not the gate's total wrapper
           # budget.  The latter includes setup/cleanup overhead already spent
           # by the current attempt and can make every retry impossible.

.gitignore

@@ -3,4 +3,5 @@ __pycache__/
 .coverage
 .pytest_cache/
 .codegraph/
+.claude/
 strix_runs/

CHANGELOG.md

@@ -5,6 +5,62 @@ this file. The format follows Keep a Changelog, and versioned releases follow
 Semantic Versioning where the repository publishes a release.
 
 ## [Unreleased]
+- **(Devin 리뷰 대응, 🟡 실제 결함 1건 + 🔍 문서 정정 1건) daemon-스레드 데드라인 fix 자체에 대한
+  Devin의 후속 지적 2건 반영.** (1) 🟡 `call_llm`이 `request_thread.join(timeout=
+  remaining_budget)`(공유 5.5시간 예산 전체)으로 join하고 있었는데, 이는 개별 호출의 상한이어야
+  할 `request_timeout`(`min(NOEMA_LLM_REQUEST_TIMEOUT_SECONDS, remaining_budget)`, 이미 공유
+  예산에 맞춰 min된 값)을 사실상 무시하는 것이었다 — trickle 응답 하나가 3시간이 아니라 공유
+  예산 전체(5.5시간)를 다 써버릴 수 있어, `NOEMA_LLM_REQUEST_TIMEOUT_SECONDS`가 애초에 막으려던
+  "한 호출이 repair 재시도 몫까지 다 태운다"는 바로 그 실패를 재도입하고 있었다. `join(timeout=
+  request_timeout)`으로 수정(Devin의 제안과 동일). 실제 wall-clock을 쓰는 새 테스트로 진짜
+  RED(공유 예산에 여유(10초)가 있으면 개별 호출 상한(0.05초)을 무시하고 0.3초 trickle이 정상
+  완료됨) → GREEN(0.05초 내 TimeoutError) 확인. 에러 메시지도 "shared wall-clock budget"에서
+  "per-request wall-clock budget"으로 정정(기존 트리클 테스트의 match 문자열도 함께 갱신).
+  (2) 🔍 `NOEMA_LLM_TOTAL_BUDGET_SECONDS` 위 주석이 "noema-review job에 명시적
+  timeout-minutes가 없다"고 말하고 있었는데, 바로 이 PR이 그 job에 `timeout-minutes: 360`을
+  추가했으므로 이미 낡은 서술이 되어 있었다 — 주석을 현재 상태를 반영하도록 갱신. 전체 스위트
+  2215 passed/1 skipped/21 subtests, coverage 100%, interrogate 100%.
+- **(Devin 리뷰 대응, 실재 결함 3건) 지난 timeout/deadline 수정 자체에 대한 Devin의 후속 지적 3건
+  반영.** (1) 🟡 `scripts/ci/noema_review_gate.py::call_llm`의 공유 데드라인이
+  `urllib.request`의 `timeout=` 인자만으로 강제되고 있었는데, 그 인자는 소켓 단일 연산의
+  inactivity(무응답) 타임아웃일 뿐 요청 전체의 wall-clock 상한이 아니다 -- 응답이 각 타임아웃
+  구간이 끝나기 전에 최소 1바이트씩 계속 흘러들어오면(trickle) 5.5시간 공유 예산을 무한정
+  초과할 수 있었다. 실제 네트워크 호출을 daemon 스레드에서 실행하고 `Thread.join(timeout=
+  remaining_budget)`으로 절대 wall-clock 데드라인을 강제하도록 재작성 -- daemon이라 데드라인
+  초과 후에도 스레드가 계속 트리클을 기다리고 있어도 프로세스 종료를 막지 않는다. 실제
+  wall-clock을 사용하는(모킹하지 않는) 새 회귀 테스트로 진짜 RED(2초 트리클 응답이 0.05초
+  데드라인을 무시하고 정상 반환) → GREEN(0.24초 내 TimeoutError) 확인. 큐를 통한 예외 전달
+  경로 자체의 커버리지 공백(성공 케이스만 있고 전송 실패 케이스가 없었음)도 별도 테스트로
+  메움. (2) 🔍 `noema-review.yml`의 `noema-review` job에 명시적 `timeout-minutes`가 없어
+  5.5시간 예산과 GitHub의 암묵적 360분(6시간) 기본값 사이의 관계가 감사 불가능했다 --
+  `timeout-minutes: 360`을 명시하고 계약 테스트 추가, 진짜 RED(부재) → GREEN 확인. (3) 🔍
+  `scripts/ci/contextual_orchestrator_review_sidecar.sh`의 게이트웨이 preflight 재시도
+  루프에서, 사이드카가 죽었는지 확인하는 `kill -0` 체크가 마지막 시도에서만 실행되어, 1번째
+  시도에서 이미 죽은 사이드카도 나머지 시도(기본 3회, 시도당 최대 120초)를 모두 소진한 뒤에야
+  감지되었다 -- 실제 이 분기가 존재하게 된 사고(Strix job 99337282309, .github#1460)의
+  근거 자체가 "6분 동안 3번의 시도가 모두 실패"로, 정확히 3×120초에 해당해 매 시도가 거의
+  풀타임 소요됐음을 보여준다. 데드-사이드카 체크를 매 실패 시도마다(시도 예산 소진 여부와
+  무관하게) 즉시 실행하도록 이동. 계약 테스트를 새 구조(체크가 attempt-budget 검사보다 먼저
+  실행됨)에 맞게 재작성, 옛 스크립트에 대해 진짜 RED(`26104 < 25156` 실패) 확인 후 복원해
+  GREEN. 세 항목 모두 `bash -n` 문법 확인, 전체 스위트 2214 passed/1 skipped/21 subtests,
+  coverage 100%, interrogate 100%.
+- Fix a false-positive in `scripts/ci/test_strix_quick_gate.sh`'s
+  `assert_opencode_review_uses_codegraph_and_contextual_orchestrator`: its
+  `awk '/^  required-workflow-bootstrap:$/,/^[^ ]/'` range never actually
+  terminated (no line in `opencode-review.yml`'s `jobs:` block dedents to
+  column 0 before EOF), so the assertion scanned the entire rest of the file
+  instead of just the `required-workflow-bootstrap` job -- flagging the
+  unrelated `opencode-review-target` job's own `if:
+  github.event.action != 'closed'` (a legitimate closed-PR skip) as if it
+  violated required-workflow-bootstrap's payload-independence rule.
+  Confirmed via two independent full runs of the script (this branch's
+  merged worktree, and a fresh clone of `main` alone) that both fail this
+  exact assertion identically -- a pre-existing defect on `main`, not
+  introduced by this branch's merge. Replaced the range with a flag-based
+  scan that stops at the next 2-space-indented job key. Verified the fix
+  still catches a genuine violation (a synthetic `if:` injected inside
+  `required-workflow-bootstrap` itself) and that the full script now passes
+  with zero failures.
 - Fail closed when the first top-level Noema JSON candidate is malformed,
   preventing a later approval object from overriding malformed preface data;
   multiple-object output remains supported when its first object is valid.
@@ -111,6 +167,13 @@ Semantic Versioning where the repository publishes a release.
   superseded commit, test path, rule, and line, with an executable contract.
 - Allow a Contextual Orchestrator-backed Noema review request to run for up to
   four hours instead of failing long reviews at a hard-coded 120 seconds.
+- Reconcile two independent fixes for that same 120-second timeout (this
+  branch's own `NOEMA_LLM_REQUEST_TIMEOUT_SECONDS` and the flat four-hour
+  `NOEMA_LLM_TIMEOUT_SECONDS` above) into one shared design: a per-call
+  request timeout (10800s/3h) capped by a shared `NOEMA_LLM_TOTAL_BUDGET_SECONDS`
+  (19800s/5.5h) monotonic deadline spanning the initial call and its one
+  possible repair call together, so two independent long calls can never sum
+  past the 6-hour GitHub-hosted job execution ceiling.
 - Stop logging raw (even regex-scrubbed) LLM response text in Noema's
   malformed-JSON fail-closed diagnostic (Devin Review security finding on
   PR #1507): `noema-review.yml` is a `pull_request_target` workflow with
@@ -141,6 +204,52 @@ Semantic Versioning where the repository publishes a release.
   then rejected via 429/404/timeout). New regression tests pin the default
   to the policy module's canonical value and forbid the total-routes
   constant from reappearing as the account-cap fallback.
+- Fix `scripts/ci/contextual_orchestrator_review_sidecar.sh`'s gateway-preflight
+  retry loop: when every configured attempt exhausted with no usable HTTP
+  response, the script always recorded generic "transport exhausted" evidence
+  even when the sidecar process itself had already exited after passing
+  readiness -- discarding the single most useful diagnostic (the process's own
+  exit status and stderr). Now checks `kill -0 "$sidecar_pid"` first (safe for
+  a bash-owned background job: a failing `kill -0` means bash's own job table
+  has already reaped it, so the following `wait` retrieves the real cached
+  exit status, not a fresh `waitpid()` on an already-gone zombie -- the same
+  pattern the pre-existing healthz branch already used) and, when the sidecar
+  has exited, records distinct evidence (`error_type:
+  "sidecar_process_exited"`, exit status, attempts) and fails with a distinct
+  message including the exit status and stderr tail, instead of the generic
+  transport-exhausted path. Exact-head evidence: Strix run/job
+  `33341290448`/`99337282309` for `ContextualWisdomLab/.github#1460` target
+  `2cc819a9` (reported via a cross-agent coordination comment, verified
+  against issue #1399 and PR #1460 before acting on it). New tests:
+  `tests/test_contextual_orchestrator_review_sidecar_contract.py::test_gateway_preflight_distinguishes_a_dead_sidecar_from_an_unreachable_one`
+  and
+  `tests/test_contextual_orchestrator_review_runtime_preflight.py::test_gateway_retry_loop_diagnoses_a_sidecar_that_died_after_readiness`.
+  See the 2026-08-30 gap-baseline entry for the full diagnosis and the two
+  pairs of pre-existing-test regressions this surfaced and fixed along the
+  way.
+- Fix `scripts/ci/pingora_edge_policy.py`'s `_load_changed_files`: the
+  post-loop pagination-exhaustion `PolicyError` was unreachable dead code
+  (proven: 31 full 100-item pages always trip the in-loop `len(files) >
+  3_000` raise during page 31's own iteration before the loop can exhaust
+  its range), and it was silently failing this repo's org-wide
+  `coverage-evidence` gate (`fail_under=100`) for every PR reviewed through
+  the central OpenCode/Noema/Strix dispatcher, blocking opencode-agent from
+  ever posting an APPROVED verdict anywhere in the org. Marked
+  `# pragma: no cover` with justification, matching this repo's existing
+  convention. See the 2026-08-30 "OpenCode Agent 자체 문제" gap-baseline
+  entry for the full three-PR diagnosis this came out of. (Independently
+  found and fixed by the org owner in the same window, commit `34c88356`,
+  with a stronger regression test pinning the arithmetic invariant itself —
+  adopted the owner's version when reconciling the resulting merge conflict.)
+- Document a structural CodeRabbit gap in `docs/product-technical-gap-baseline.md`
+  (2026-08-30 entry): every ContextualWisdomLab repo is below CodeRabbit's
+  10-GitHub-star automatic-review threshold, so CodeRabbit never reviews a new
+  commit without an explicit `@coderabbitai review` trigger comment — this was
+  surfacing as a `naruon` PR-governance metadata-gate block that looked like a
+  blocking finding but was actually CodeRabbit's own "not reviewed yet" state.
+  No code change; a central auto-trigger workflow is a candidate follow-up,
+  deliberately deferred pending a review of its required-workflow-ruleset
+  blast radius.
 - Fix a dangling reference #1468 left in `docs/product-goal-directive.md`
   (flagged by Devin Review on that PR): the standing operating directive
   still named the removed `free_family_diversity` evidence field instead of
@@ -705,6 +814,27 @@ Semantic Versioning where the repository publishes a release.
   `zero_data_retention` stays `False` as it already was; only the citation
   and note change. See the 2026-08-30 ZDR/NIM-routing gap-baseline entry for
   the full architecture review this citation was part of.
+- Correct `docs/product-technical-gap-baseline.md`'s "2026-08-30 post-#1486/#1438 wake" entry: Bytez
+  can never populate `orchestrator/free` regardless of its HTTP status (`_parse_bytez` never sets
+  `is_free`), and the `request_failed status=413` line is the sidecar's own unconditional self-test
+  rather than a live ZDR-prefetch fallback. The incident's actual terminating message
+  (`"review sidecar preflight failed"`, a live warm-up-probe rejection) is the same one the
+  `ORCHESTRATOR_CATALOG_FAMILY_CAP` fix above mitigates (hosted confirmation remains pending) — the
+  two corrections converge on the same real root cause rather than describing two different bugs.
+  Also adds a bounded, one-retry
+  resilience improvement to `contextual-orchestrator`'s provider *discovery* fetch (a different,
+  non-overlapping call site from the family-cap/preflight fix above) in
+  `ContextualWisdomLab/contextual-orchestrator#923`.
+- Refresh `docs/product-technical-gap-baseline.md`'s §5.1 next-increment list,
+  which had gone stale: #1297 was already merged, and #1345/#1326 were closed
+  unmerged, yet all three were still listed as pending candidates. Replaced
+  with the current state (#1347 still open/dirty; `ContextualWisdomLab/naruon#1486`
+  added as this pass's naruon increment) and recorded the naruon-side Noema
+  role clarification: naruon's `noema-general-agent` is a separate, correctly
+  BYO-LLM-scoped agent from this repo's central review-bot Noema — they
+  intentionally share only a name — and it now has a `check_calendar_conflict`
+  tool (PRD-02) that reuses naruon's existing deterministic conflict policy
+  instead of inventing a second one.
 - Bump the vendored `contextual-orchestrator` review-sidecar pin from
   `5f2753a` (the #1422 pin) to current `main` `30c6d716`, picking up
   `ContextualWisdomLab/contextual-orchestrator#919`: generalizes the