[상류 구현] P52b 명시적 deferred launch discard 결과 #217

New Issue

2026-10-29T23:01:55+09:00

dreampiler commented

2026-10-29 23:01:55 +09:00

원 요구·승인

소유자 직접 지시(운영 대화 2026-10-29, 원문): 「P50·P52b는 maintainer 답변만 기다리지 말고, 지금 권장한 안전한 범위로 상류 제출용 최소 패치를 구현·검증해줘. 답변이 꼭 필요한 부분만 분리해 남기고, 운영판 반영 전에는 변경 내용과 검증 결과를 알려줘.」 승인된 권장안(P52b): 기존 task mutation/ownership 검사에 맞는 동기식 task 범위 요청으로 하고, already-clear·discarded·settlement 미완을 구분하며, 실패 시 durable record와 owner를 보존한다. 이 task는 P52b 상류 제출용 구현 단위의 단일 source writer다. 원 준비 단위(queue KANDEV-UPSTREAM-P52b-20261014-project, wrapper b0cc9e7e, 원 준비 39d8ee09 — 현재 등록 DB에 없음, 준비 flow closed)는 다시 열지 않고 입력으로만 쓴다.

입력

원 fork 9395959302(manual-route slice), draft commit 1c8c4fd(base 0c37470)의 P52b-discard-deferred-launch-api-draft.md(제안 POST /api/v1/tasks/:id/deferred-launch/discard, 200 discarded bool). 방향 질문 #4508(답 없음). 93이 2026-10-29T12:53:18Z wrapper Plan b0cc9e7e에 current main 012fb3c04069 대조를 저장했다 — 먼저 읽는다.
정본: projects/260926_Kandev/_Prj_Work/p330_jobsheets/KANDEV-UPSTREAM-P52b-20261014-project.md, _UserHub/_task/kandev-ops/261020_codex-ops-diagnostics.md 21:55 결과.

할 일 (원자 변경 1개)

현재 유효한 upstream main에서 깨끗한 자기 Native 사본을 만든다(남의 dirty source/branch 쓰기 0).
automatic invalid replay 정리를 그대로 user discard로 불러 bool만 돌려주는 원 후보는 쓰지 않는다. task write·executor mutation과 기존 ownership/identity-CAS/입장 lock 경계를 재사용하는 명시적 discard 결과를 구현한다. 구분할 결과는 셋이다 — 이미 비어 있음(no-op), 성공, settlement 또는 clear 미완으로 원 durable record가 남은 경우. 다른 owner의 key나 새 세대 record는 clear하지 않는다. 정산이 실패하면 복구 가능한 원 record와 owner를 보존한다. 기존 manual launch·실행 중 session을 시작하거나 멈추지 않는다.
공통 안전 service와 얇은 후보 API를 분리한다. 그래야 maintainer가 계약을 바꿔도 내부 안전성이 유지된다. 동기식 task API 후보도 최소로 구현·확인하되, path·verb·응답 필드와 추가 operator 권한 필요 여부는 상류 미합의 계약 제안임을 문서에 표시한다.
증명할 것(isolated fixture): no-op, 성공, settlement 오류, clear 오류, CAS 경쟁·다른 owner, 진행 중 session 비간섭. 실패를 no-op이나 성공으로 숨기지 않는다. 기존 관련 test 파일과 좁은 build를 재사용한다. 일회성 확인은 자동 수집 밖 임시 위치에서 하고 끝나면 정리한다. 새 상시 test 파일·framework 0.
상류 pr-docs.cjs validateCoverage로 필요한 최소 linked work order를 확인한다. normal hooks, 바뀐 delta만 gate workflow rv-run, 필수 지적만 고친다.
결과(branch·base/head·diffstat·commit, 검증 이름·결과, 미결 계약 — path/verb/응답 필드·operator 권한)를 8e/current 96e9d7f4-0840-479a-b7b6-3e18d45b4da4에 1회.

경계

운영판 반영·교체·재시작 0, 운영 DB write 0, 실운영 endpoint 호출 0, 공개 PR/issue/comment/push 0. 새 권한·역할·DB schema·비밀·설정 잠금 우회 0. 모델·동적 순서·한도 변경 0. P50 구현 단위와 같은 통합 파일·Git ref를 동시에 쓰지 않는다(겹치면 8e에 경로를 알린다).

## 원 요구·승인 소유자 직접 지시(운영 대화 2026-10-29, 원문): 「P50·P52b는 maintainer 답변만 기다리지 말고, 지금 권장한 안전한 범위로 상류 제출용 최소 패치를 구현·검증해줘. 답변이 꼭 필요한 부분만 분리해 남기고, 운영판 반영 전에는 변경 내용과 검증 결과를 알려줘.」 승인된 권장안(P52b): 기존 task mutation/ownership 검사에 맞는 동기식 task 범위 요청으로 하고, already-clear·discarded·settlement 미완을 구분하며, 실패 시 durable record와 owner를 보존한다. 이 task는 P52b 상류 제출용 구현 단위의 단일 source writer다. 원 준비 단위(queue KANDEV-UPSTREAM-P52b-20261014-project, wrapper b0cc9e7e, 원 준비 39d8ee09 — 현재 등록 DB에 없음, 준비 flow closed)는 다시 열지 않고 입력으로만 쓴다. ## 입력 - 원 fork 9395959302(manual-route slice), draft commit 1c8c4fd(base 0c37470)의 P52b-discard-deferred-launch-api-draft.md(제안 POST /api/v1/tasks/:id/deferred-launch/discard, 200 discarded bool). 방향 질문 #4508(답 없음). 93이 2026-10-29T12:53:18Z wrapper Plan b0cc9e7e에 current main 012fb3c04069 대조를 저장했다 — 먼저 읽는다. - 정본: projects/260926_Kandev/_Prj_Work/p330_jobsheets/KANDEV-UPSTREAM-P52b-20261014-project.md, _UserHub/_task/kandev-ops/261020_codex-ops-diagnostics.md 21:55 결과. ## 할 일 (원자 변경 1개) 1. 현재 유효한 upstream main에서 깨끗한 자기 Native 사본을 만든다(남의 dirty source/branch 쓰기 0). 2. automatic invalid replay 정리를 그대로 user discard로 불러 bool만 돌려주는 원 후보는 쓰지 않는다. task write·executor mutation과 기존 ownership/identity-CAS/입장 lock 경계를 재사용하는 명시적 discard 결과를 구현한다. 구분할 결과는 셋이다 — 이미 비어 있음(no-op), 성공, settlement 또는 clear 미완으로 원 durable record가 남은 경우. 다른 owner의 key나 새 세대 record는 clear하지 않는다. 정산이 실패하면 복구 가능한 원 record와 owner를 보존한다. 기존 manual launch·실행 중 session을 시작하거나 멈추지 않는다. 3. 공통 안전 service와 얇은 후보 API를 분리한다. 그래야 maintainer가 계약을 바꿔도 내부 안전성이 유지된다. 동기식 task API 후보도 최소로 구현·확인하되, path·verb·응답 필드와 추가 operator 권한 필요 여부는 상류 미합의 계약 제안임을 문서에 표시한다. 4. 증명할 것(isolated fixture): no-op, 성공, settlement 오류, clear 오류, CAS 경쟁·다른 owner, 진행 중 session 비간섭. 실패를 no-op이나 성공으로 숨기지 않는다. 기존 관련 test 파일과 좁은 build를 재사용한다. 일회성 확인은 자동 수집 밖 임시 위치에서 하고 끝나면 정리한다. 새 상시 test 파일·framework 0. 5. 상류 pr-docs.cjs validateCoverage로 필요한 최소 linked work order를 확인한다. normal hooks, 바뀐 delta만 gate workflow rv-run, 필수 지적만 고친다. 6. 결과(branch·base/head·diffstat·commit, 검증 이름·결과, 미결 계약 — path/verb/응답 필드·operator 권한)를 8e/current 96e9d7f4-0840-479a-b7b6-3e18d45b4da4에 1회. ## 경계 운영판 반영·교체·재시작 0, 운영 DB write 0, 실운영 endpoint 호출 0, 공개 PR/issue/comment/push 0. 새 권한·역할·DB schema·비밀·설정 잠금 우회 0. 모델·동적 순서·한도 변경 0. P50 구현 단위와 같은 통합 파일·Git ref를 동시에 쓰지 않는다(겹치면 8e에 경로를 알린다).

dreampiler commented

2026-10-30 04:25:33 +09:00

8e 수락(상류 제출 후보, 운영 root 단일 writer 마무리): 사본 kandev-upstream-p52b_1oa6vl1y HEAD fc28e64521c2 clean, base da9ff6332863, commit 4개(460ace9 feat, 2af99df, 0c850fa, fc28e64 root 정상 commit), 14 files +932/-69, 새 test 파일 0. 8e 재확인: validateCoverage covered(14 files), CALL-20261030-f4d4e89d9a3a completed APPROVE findings 0(artifact 261030_p52b-explicit-discard-review.md가 fc28e645 기재). 실검증 근거(root 원출력): HTTP/auth 7 cases(43309), SQLite trigger rollback·재요청 9 cases(ed24cae9), Triggered 정산 owner 해제 RED16325->GREEN85306. PG 실DB·운영 API·Windows 전체 suite PASS 주장 0. 사고: 원 SID 9ee489b6가 18:48:37Z golangci-lint 이름 기준 일괄 종료 → root가 정식 stop·auto_run false, 그 SID 재개 0. maintainer 미결: API path/verb/응답 필드(POST /api/v1/tasks/:id/deferred-launch/discard, 200 outcome/reason)와 전용 operator 권한 여부(#4508 답 0). 상류 중복 PR 없음. 다음: 93이 게시 방식 결정(독립 새 PR 제안형, #4508 Refs) → 5d. 운영판 반영 0.

dreampiler commented

2026-10-30 04:35:45 +09:00

검토 지적(clear 실패 시 owner 소실)을 원자 경계로 수정했습니다.

head 0c850fa1ca4 / base da9ff633286, 14 files +930/-69, _test.go 변경 0, push·PR·병합 없음
새 repository 연산 ClearTaskDeferredLaunchAndReleaseOwnershipIfUnchanged: deferred-launch CAS와 automation-start owner 조건부 해제를 한 task 트랜잭션에서 적용. 한쪽 실패 시 양쪽 롤백되므로 "record는 남고 owner만 사라짐"과 그 반대가 모두 불가능. 다른/bound run의 marker는 그대로 두고 clear를 실패시키지 않음. owner/session 조회 불가는 변경 전 retained/ownership_incomplete.
공용 TaskRepository 인터페이스·기존 fake는 건드리지 않고 RemoveTaskMetadataKeyIfValue 방식의 repository type assertion으로만 연결했습니다.
검증: 실제 SQLite + owner 해제를 막는 BEFORE UPDATE trigger overlay에서 clear가 함께 롤백되어 record·owner 둘 다 보존, trigger 제거 후 재시도에서 둘 다 제거. already-clear/성공/settlement/소유권 조회 불가/다른 owner/claim 경쟁/successor/live claim/비간섭도 통과. build·vet·changed-delta lint 0, 관련 package 시험·docs 검증·validateCoverage 통과.
운영 root의 HTTP 7-cases(exec 43309)와 clear/owner 재현(exec 59360)은 Plan에 인수했고, "HTTP 미실행" 한계 문구는 보완 완료로 정합했습니다.

검토 단계 완료 신호를 보냈고, 다음 단계에서 8e로 결과 1회 인계가 남아 있습니다.

검토 지적(clear 실패 시 owner 소실)을 원자 경계로 수정했습니다. - head `0c850fa1ca4` / base `da9ff633286`, 14 files `+930/-69`, `_test.go` 변경 0, push·PR·병합 없음 - 새 repository 연산 `ClearTaskDeferredLaunchAndReleaseOwnershipIfUnchanged`: deferred-launch CAS와 automation-start owner 조건부 해제를 **한 task 트랜잭션**에서 적용. 한쪽 실패 시 양쪽 롤백되므로 "record는 남고 owner만 사라짐"과 그 반대가 모두 불가능. 다른/bound run의 marker는 그대로 두고 clear를 실패시키지 않음. owner/session 조회 불가는 변경 전 `retained/ownership_incomplete`. - 공용 `TaskRepository` 인터페이스·기존 fake는 건드리지 않고 `RemoveTaskMetadataKeyIfValue` 방식의 repository type assertion으로만 연결했습니다. - 검증: 실제 SQLite + owner 해제를 막는 `BEFORE UPDATE` trigger overlay에서 clear가 함께 롤백되어 record·owner 둘 다 보존, trigger 제거 후 재시도에서 둘 다 제거. already-clear/성공/settlement/소유권 조회 불가/다른 owner/claim 경쟁/successor/live claim/비간섭도 통과. build·vet·changed-delta lint 0, 관련 package 시험·docs 검증·`validateCoverage` 통과. - 운영 root의 HTTP 7-cases(exec 43309)와 clear/owner 재현(exec 59360)은 Plan에 인수했고, "HTTP 미실행" 한계 문구는 보완 완료로 정합했습니다. 검토 단계 완료 신호를 보냈고, 다음 단계에서 8e로 결과 1회 인계가 남아 있습니다.

dreampiler closed this issue

2026-10-30 04:36:06 +09:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dreampiler/kandev#217