Skip to content

program: 2026-09-03 CI·Agent·Contextual Orchestrator 구조 복구 추적 #1802

Description

@seonghobae

목표

2026년 9월 2일과 9월 3일에도 계속된 GitHub Actions 적체와 41개 제품·Agent·Contextual Orchestrator 요구사항을 저장소별 canonical owner에서 해결하고, exact-head GREEN·독립 리뷰·병합·consumer canary까지 추적합니다.

완료율은 보호된 기본 브랜치에 병합되고 운영 검증까지 끝난 항목만 계산합니다. 분석, 이슈 생성, Draft PR, predecessor의 과거 GREEN은 완료가 아닙니다.

현재 기준

A. GitHub Actions 처리량·중앙화·동시성

B. Agent 실행·리뷰·격리·보안

  • 1 OpenCode Review가 실질적으로 Contextual Orchestrator를 통해 실행
  • 2 Strix가 실질적으로 Contextual Orchestrator를 통해 실행
  • 3 Noema가 실질적으로 Contextual Orchestrator를 통해 실행
  • 4 응답 정합성 오류의 typed reason·평가·telemetry와 900초 원인 제거
  • 5 Noema가 naruon의 제품 Agent로 기능하고 review workflow와 domain runtime을 분리
  • 6 quarantine-sandbox-runtime을 Noema·OpenCode의 실제 코드 실행에 연결
  • 7 통신 보안 authority를 EgressWeave·Wardnet으로 이관하고 중복 HTTP policy 제거
  • 23 Noema 리뷰 실패 사례 재수집·분모·taxonomy·개선안
  • 24 Noema/OpenCode 리뷰 품질을 CodeRabbit/Devin과 비교하는 blind benchmark·ablation
  • 28 일반지침 기반 PR·리뷰·웹·논문·표준·issue 대행 Agent capability
  • 38 새 저장소·새 stack 감지 후 CodeQL PR 자동 생성

C. Contextual Orchestrator provider·OpenAI API·batch

D. Search·MCP·A2A·Browser

  • 14 MCP Gateway·A2A Gateway, 내부 검색 판단, SearXNG 복수 메타 검색, Camoufox, quarantine session isolation — CO #1009은 SearXNG web_search()만 병합된 부분 완료

E. 관리자 Web·Identity·조직 모델

  • 19 Noema·CO·Keyverse 관리자 Web과 상호 연계, Keyverse secret/KV 경계
  • 20 naruon 제품 form이 Keyverse REST API로 login/signup/recovery, ABAC/RBAC 사용
  • 21 naruon이 OpenAI json_schema로 통신
  • 22 Keyverse를 identity federation + credential store + service ABAC/RBAC + 관리 UI로 확장
  • 25 CO model_groups save/delete 후 /admin/state 재조회와 feedback 상태 색 — CO feat(actions): inventory orphaned workflow identities #1026, protected main 계약 테스트
  • 27 지주→지역 HQ→계열사→사업부문→사업부→파트/팀 및 역전·겸직·TFT를 시간가변 graph로 모델링하고 SCIM/OIDC/SAML 교환

공통 Definition of Done

각 체크는 다음을 모두 만족해야 닫습니다.

  1. canonical owner에 RED test와 causal fix
  2. PRD·TRD·ADR·ARCHITECTURE·CHANGELOG·docs/product-technical-gap-baseline.md 추적
  3. 목적을 마친 source-fix/self-modifying workflow 제거
  4. exact-head tests/security/contracts/provenance GREEN
  5. 미해결 유효 review thread 0
  6. 보호된 기본 브랜치 병합 또는 검증된 successor 완전 승계
  7. consumer canary 또는 실제 장애 run 재검증
  8. 운영 지표의 전후 비교

진척률 산식

완료율 = 보호된 기본 브랜치 + 운영 재검증까지 끝난 항목 수 / 41

하위 PR·이슈의 진행률은 별도이며 합산해 완료율을 부풀리지 않습니다.

협업 지시

여유가 있는 로컬 세션은 위 체크 중 파일 writer가 겹치지 않는 하나를 맡아 owner repo, exact base/head, RED, 최소 fix, GREEN, merge/successor evidence를 이 이슈에 남기십시오. 구독 중인 PR을 이관할 때는 delta inventory와 unresolved finding을 함께 넘깁니다.

기다리는 동안 다른 로컬 세션에게 지속적으로 지시 받아 도우세요. 계속 묻고 계속 피드백하고 계속 지원하세요. 더 주도적이고 더 적극적으로요.

60-job ceiling 또는 API rate limit이 원인인 경우 sleep·no-op retrigger·workflow 복제로 우회하지 말고 중앙 owner에서 trigger fan-out, token scope, startup failure, runner materialization, concurrency를 수리합니다.

Activity

  1. self-assigned this
    on Sep 3, 2026
  2. seonghobae commented on Sep 3, 2026

    @seonghobae
    ContributorAuthor

    실행 중간 기록 — 지정 장애 run RCA와 진척률

    완료율은 그대로 **4/41 = 9.8%**로 유지합니다. 아래 source fix·RCA·owner 지정은 운영 재검증 전까지 완료로 올리지 않습니다.

    Item 4 — 응답 정합성·구체적 telemetry: 미완료

    • newsdom-api run 33510285421, job 99864028341
      • credential/token/CO sidecar/orchestrator/free preflight 성공
      • 최종 실패: 모델 출력 JSON 문법 오류, line 1 column 2223, 응답 길이 3,713자, SHA-256만 제공
      • schema path, provider/model, structured-output repair 단계, parser context가 최종 오류에 없음
    • html4tree run 33560972491, job 100033086428
      • 초기 실패: JSON 문법 오류, line 1 column 1530, 응답 길이 1,890자
      • 옛 caller가 repair용 두 번째 LLM 요청을 만들고 NoemaRepairDeadlineExceeded 900초에 도달

    보호된 central source의 commit a28fc2f4e185df7847e2f2f5f6ec561d1e84805d는 caller repair·900초 deadline·두 번째 모델 호출을 제거하고 CO에 timeout/repair/failover를 귀속했습니다. 하지만 새 source로 실제 consumer canary가 성공하기 전에는 item 4를 닫지 않습니다. 남은 acceptance는 provider/model/phase/attempt/elapsed/schema violation을 typed receipt로 남기고 malformed raw output을 노출하지 않으면서 운영자가 고칠 수 있는 원인을 제공하는 것입니다.

    Item 39 — 900초 제한: source-fixed, 운영 미검증

    지정 CO run 33580381913, job 100093226133에서:

    1. 첫 모델 verdict가 request_changes인데 adversarial_validation.status=failed가 없어 local semantic contract failure
    2. 옛 caller가 repair request 생성
    3. caller-owned 900초 absolute deadline이 두 번째 요청을 종료

    a28fc2f4...에서 이 경로는 제거됐습니다. 사용자 지시의 “3시간으로 늘리기”보다, 공통 기본 timeout null·CO owner·provider termination이라는 현행 아키텍처가 더 정확합니다. 다만 queued old-source runs가 계속 materialize되므로 운영 canary 전까지 미완료입니다.

    Item 40 — fast-mlsirm Noema failure: 전제 정정, 미완료

    run 33646974279, job 100304078562:

    • step 7 credential selection: 성공
    • step 8 repository-scoped app token: 성공
    • step 12 CO sidecar + orchestrator/free: 성공, 54 routes admitted, 5 ready
    • step 13: 649.5초 후 CO HTTP 500, phase=connecting, served_model=unknown

    따라서 credential failure가 step 13을 유발했다는 전제는 로그와 다릅니다. 실제 문제는 오래 queue된 run이 옛 workflow/sidecar source로 실행된 것, gateway internal 500의 구체적 원인이 unknown으로 남는 것, current source canary 부재입니다.

    Item 41 — startup failure: 미완료

    • Wardnet run 33710719228: CodeQL PR, startup_failure, Jobs API [], job/runner/checkout 없음
    • run head 46ede...와 연결 PR auto-merge 대기 PR의 update-branch 처리 보강 #140 current head 9389a... 불일치
    • .github source-fix run 33761818467: 같은 형태의 job 0개 failure

    #712와 #1150에 startup_failure_before_job_materialization, stale_workflow_source_materialized, runner_id=0, source/test/credential/gateway failure를 분리하도록 증거를 전달했습니다.

    Item 30 — OpenCode startup UX: source-fixed, 운영 미검증

    옛 run 33548447878은 stale event head가 live head와 다르다는 이유로 step 2에서 red 처리했습니다. 보호된 main은 이제 open/ready PR의 moved head를 성공적으로 self-retire하고 fresh dispatch를 기다리도록 변경되어 있습니다. current-source canary가 없는 관계로 완료 체크는 보류합니다.

    다음 owner 작업

    다른 세션은 위 owner 중 파일 충돌이 없는 하나를 맡고 RED→GREEN→exact-head→merge/canary를 이 이슈에 남겨 주십시오.

    기다리는 동안 다른 로컬 세션에게 지속적으로 지시 받아 도우세요. 계속 묻고 계속 피드백하고 계속 지원하세요. 더 주도적이고 더 적극적으로요.

  3. seonghobae commented on Sep 3, 2026

    @seonghobae
    ContributorAuthor

    Item 40 fresh causal evidence from ContextualWisdomLab/fast-mlsirm#1536 confirms the Noema credential-lifetime defect remains live and is not a leaf/source failure.

    Exact consumer canary:

    • protected fast base: main@b5a3a0c1057d4b53d7a4bb18e0de69f630c2b45c
    • unchanged PR head: 77bef27cff780b909be484b52be35e97be752780
    • required Noema run/job: 33634978342 / 100263465886
    • trusted central workflow source used by the run: .github@9330d41c92b1e6ab35261f3f5189936ea1ad8bff
    • runner and exact-head validation succeeded; repository-scoped cwl-noema-review installation token was minted at 2026-09-03T00:26:23Z.
    • contextual-orchestrator sidecar came up and orchestrator/free preflight was healthy; Prepare Noema model verdict started at 00:49:57Z.
    • at 01:44:26Z, ~78 minutes after token mint, the prepare phase failed at a GitHub CLI call with gh: Bad credentials (HTTP 401); post-job cleanup independently reported Token expired, skipping token revocation.

    This exactly matches the defect previously RED/implemented in .github#1745 (12b44ee781daf7bcd88954e62c8ecb2d8784d20f), but #1745 is closed, unmerged. Fresh comparison against protected .github/main@269e5bd9e65c38770a827af1291a5657d5cfcd01 is diverged, ahead_by=1, behind_by=75; its unique delta still changes scripts/ci/noema_review_gate.py, two_phase.py, focused tests, doctoring, and CHANGELOG. Default-branch code search finds no NoemaRepairRecheckUnavailableError, so no verified successor carryover is visible.

    A second fast canary (#1690, f811f471..., run 33633945304) shows a related but distinct prepare-path failure: the model contract repair hit the hard 900-second NoemaRepairDeadlineExceeded; cleanup again reported the repository App token expired. Do not collapse that deadline defect into the 401 defect; item 39 owns the 900s policy, item 40 owns credential lifecycle.

    Required owner repair / acceptance for item 40:

    1. Preserve fix(noema): fail closed when repair-retry live-head recheck outlives its token #1745's valid RED and fail-closed tests or explicitly supersede them with byte/contract-equivalent evidence; a closed-unmerged valid delta is not completion.
    2. Do not carry a GitHub App installation token across an unbounded model/provider phase. Any GitHub live-head/review revalidation that can occur after model execution must obtain a fresh repository-scoped credential at that boundary (or equivalently move the GitHub recheck outside the long-lived credential lifetime); the model/CO subprocess must not receive GitHub credentials.
    3. Preserve a separately fresh publication credential and exact live head/base validation before any review is submitted.
    4. Add a realistic >1h token-age regression for both initial prepare and repair-retry paths, plus fail-closed behavior when refresh/revalidation is unavailable; do not broaden permissions, weaken Noema, or impose a shorter model timeout as a workaround.
    5. GREEN is a current protected .github successor plus a fresh unchanged fast-mlsirm canary where the same long-running path survives past the old token lifetime, performs post-model GitHub revalidation with a fresh credential, and publishes only after exact-head/base revalidation.

    No fast-mlsirm source churn or retrigger commit is indicated by this failure.

  4. seonghobae commented on Sep 3, 2026

    @seonghobae
    ContributorAuthor

    Item 40 revalidation requested in the program body is now completed against the named fast-mlsirm canary 33646974279 (#1518@b8e72773c34cd2f383bf44f492e52bf61736c680, job 100304078562).

    Result: the designated run does not reproduce the earlier GitHub-App credential-expiry failure. Trusted workflow source was .github@bbe65f08b1ae663c467be343e8fd5a98881eb686. It minted the repository-scoped reviewer token at ~02:32Z, performed live-head validation, provisioned contextual-orchestrator, and later post-job cleanup reported Token revoked at 02:52Z. There was no gh: Bad credentials / expired-token failure. The workflow also contains a separate Refresh repository-scoped Noema GitHub App token for publication step, although that publication refresh was skipped because verdict preparation failed first.

    The run instead failed at a different owner boundary: after healthy orchestrator/free discovery/readiness and a successful chat/completions preflight, the actual Noema request spent 649.5s in phase=connecting and returned gateway HTTP 500 with served_model=unknown. That new causal evidence has been handed to canonical contextual-orchestrator owner issue ContextualWisdomLab/contextual-orchestrator#1016 (comment 5527940637) because the leaf cannot safely identify selected/attempted provider/fallback outcomes from the public error contract.

    Do not mark item 40 fully complete from this canary alone: its credential lifetime was only ~20 minutes, so it does not prove the >1h path that failed on fast-mlsirm#1536 run/job 33634978342/100263465886. The earlier acceptance still stands: prove a long model phase crossing the old installation-token lifetime, obtain/revalidate fresh GitHub authority at the post-model boundary, keep publication on a separately fresh credential, and preserve exact live-head/base validation. But the named 33646974279 recheck itself is now classified: credential failure not reproduced; terminal failure moved to the contextual-orchestrator transport/evidence lane.

  5. seonghobae commented on Sep 7, 2026

    @seonghobae
    ContributorAuthor

    2026-09-07 추적 원장 정합성 점검

    현재 본문 완료 체크는 8·9·10·25·31의 5개인데 상단은 **4/41 = 9.8%**입니다. 이를 곧바로 5/41로 올리면 안 됩니다. 본문 근거 중 source/tests·정책 적용과 공통 DoD의 운영 재검증은 범위가 다릅니다. 각 완료 항목의 보호 병합 SHA와 consumer canary/운영 원시 증거를 재확인하기 전까지 이 원장의 전체 완료율은 재검증 필요 상태입니다. 이번 점검으로 새로 완료 인정한 항목은 0개입니다.

    추가 조사 연결: #2000의 실패 후 route 반복 선택 보고는 항목 4·39와 Actions runner 점유에 연결됩니다. 보고된 909회 시도/837회 단일 route/소진 이벤트 0회는 아직 이 작업에서 원본 artifact를 독립 검증하지 않았습니다. CO 담당 작업에 request-ID별 분모, 동일 logical request와 caller 재호출 구분, 기존 owner의 소진 계약 조사를 요청했습니다. 경과 시간만으로 model timeout을 추가하는 근거로 사용하지 않습니다.

    항목 13·16·17의 현재 변경은 #1962 exact f162c6b(Draft, 로컬 전체 2994 passed/1 skipped), #1996 후속 로컬 9f08ed0(282 passed, 미push)입니다. #1996 기존 Strix job101590121689는 API에서 실제 in_progress를 확인해 유지했습니다. 이 수치들은 보호 병합이나 조직 전체 처리량 개선의 증거가 아닙니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions