Repository navigation
WP13: composed acceptance at the production boundary #1048
Description
Activity
Automated translation bookkeeping — detected language: unknown.
Follow-up work
This issue is the parent tracker for composed Codex write-coordination correctness.
Focused follow-ups:
- Adopt pre-substrate Codex homes into the write coordinator #1049 — adopt pre-substrate Codex homes into the coordinator
- History migration: make no-op detection atomic with coordination and backup accounting #1183 — make history-migration no-op detection atomic
- [Bug]: Concurrent ocx start restores journal before checking the existing healthy proxy #1230 — prevent concurrent startup from restoring journal state owned by another healthy proxy
- addedchoreMaintenance, CI, tests, refactors, or build changes (not a user-facing bug or feature).Maintenance, CI, tests, refactors, or build changes (not a user-facing bug or feature).
on Aug 15, 2026 리뷰 · 우선순위 51 / 80
현재
dev에는 워크스테이션 안전 합성 수락이 있습니다.tests/codex-composed-acceptance.test.ts가 있고, PR #1106이 CLI 자식·임시 홈 HTTP 서버·엔트리-퍼널·lost-transition·외국 홈 거부·동일 사용자 교차 홈 단일 잠금·Grok OFF 재시작·ocx restore --json복원 진실을 넣었습니다. 그 부분은 다시 구현하면 안 됩니다.이슈가 열린 이유는 서비스 등급입니다. 일반 테스트 발견에 넣으면 안 되는 disposable-host 시나리오(P09, P10, P18, P34–P36), 아직 조정자로 수렴이 증명되지 않은 production census 행, 서비스 매니저 경로에서 기판을 우회하는 생산 작성자가 없다는 최종 증명입니다. 개념적 진입점은
scripts/disposable-host/codex-service-composed-acceptance.ts이고, 현재 트리에서 그 스크립트는 보이지 않습니다.Windows/서비스가 점수입니다. 워크스테이션 스위트는 launchd/서비스/MSIX 재시작과 같은 수명 주기를 증명하지 않습니다. 네이티브 신뢰성의 남은 구멍은 “테스트가 초록”이 아니라 “서비스 매니저가 같은 조정자를 쓰는가”입니다. #1049, #1183, #1230은 별 이슈로 두고, 수락 시나리오 자체가 문제일 때만 여기로 접습니다.
위생적으로 서비스 테스트를 일반
tests/발견에 넣으면 워크스테이션 CI가 호스트를 부숩니다. disposable-host는 파괴/리셋 가능한 기계에만 있어야 합니다. 이미 고친 OFF 아티팩트 생성,/api/sync오래된 설정, HTTP 외국 홈 수락을 다시 열면 안 됩니다.해결방안은 워크스테이션 스위트를 동결하고, 서비스 클래스만 분리 엔트리로 추가하며, census에서 미증명 작성 경로만 추적하는 것입니다. 패치는 추측하지 않으며, 현재 트리에서 남은 것은 서비스 호스트 수락입니다.
이 댓글은 grok-bot이 작성했습니다
Backlog review 2026-08-23 — retained, now bounded.
Still partially implemented: PR #1106 landed the workstation-safe composed acceptance suite and six production-path scenarios on
dev. The remaining scope is the Windows leg, which is exactly what #2152 and PR #2452 address, so this is no longer open-ended — when the Windows WP13 scenarios pass, this issue's remaining gap closes with them.Linking to #2152 rather than leaving this as a standing placeholder.
Closed on
devby #2618 (squasheca432d6a87a51600863767669f43dd2fe321648).The deferred half is implemented and, more to the point, it ran.
scripts/disposable-host/codex-service-composed-acceptance.tsexecuted all six service rows on a real Linux/systemd host, exit 0:P09 PASS generation=1->2 direction=remove tx=7f9b2fc7-… P10 PASS generation=1->2 direction=remove tx=13de0a20-… P18 PASS generation=1->2 direction=remove tx=5736b469-… P34 PASS generation=2->3 direction=apply tx=d5aee30d-… P35 PASS generation=1->2 direction=remove tx=bbad3bbd-… P36 PASS generation=1->2 direction=remove tx=e08c2ca5-… PASS disposable service census: P09, P10, P18, P34, P35, P36Each row ran the empty-registration gate on both sides, installed only its own fixture registration, invoked the production entry as a real process, and asserted exactly one admitted transaction in the right direction. The host was returned to its exact prior state and that was proven by re-running the same gate afterwards.
It found a real product bug.
ocx uninstallcould not remove a config home OpenCodex created itself — "partial uninstall: unowned files remain" — becauseadmin-api-tokenand the per-CODEX_HOMEcatalog-backup-<16 hex>.jsonwere never claimed by the ownership manifest. That is exactly the class of defect this issue existed to catch, and no workstation test could have: it only appears when the production uninstall runs against a home the product itself created. Fixed with its own regression, falsified per hunk.Three harness defects were fixed along the way, one of which is worth keeping: a fake
HOMEcannot work for these rows at all, becausesystemctl --userresolves its unit directory from the running user manager rather than$HOME. That is the concrete reason these rows are disposable-host-only — a globally addressed service cannot be redirected into a temp root, so the safety property comes from the sentinel and the gate, not from isolation.Census:
devlog/_plan/260826_wp13_disposable_host/010_census.mddispositions all 36 rows — 14 with direct composed process coverage, 22 explicitly retired with named evidence. "Deferred" appears nowhere in it, which was the close condition.One finding recorded rather than papered over: the rows report
PROVENANCE record absent.updateIntegrationRecordhas no caller insrc/, so the provenance ledger is never written, andconvergence-types.tssays provenance is optional at record v1. The original assertion required an entry no production path can produce. It now fails only on disagreement — a ledger that exists and omits the admitted transaction is a real defect. Worth a separate issue; not something to make green by assertion.GitHub only auto-closes on merges into
main; PRs here targetdev, so closing manually.- addedlanded-via-maintainerOriginal PR closed after landing via a maintainer merge trainOriginal PR closed after landing via a maintainer merge train
on Aug 25, 2026 - added a commit that references this issue
on Sep 14, 2026 - added 6 commits that reference this issue
on Sep 17, 2026
Why this is its own issue
Every phase of the Codex write substrate proved its own mechanism, but phase-local green tests do not prove that every production entry point converges on the same coordination substrate.
This issue tracks composed acceptance across those production boundaries.
Current status
This issue is partially implemented.
PR #1106 merged the workstation-safe composed acceptance suite and six production-path scenarios into
dev.Delivered there:
tests/codex-composed-acceptance.test.ts;ocx restore --json.That work also found and fixed several real production holes, including OFF paths creating artifacts, stale server-captured config during
/api/sync, foreign homes accepted over HTTP, and opaque busy results.The workstation-safe portion should not be reimplemented.
Remaining scope
The issue remains open for the acceptance work deliberately deferred from #1106:
The deferred service class includes the scenarios identified in the WP13 resume plan as:
The intended disposable-host entry point remains conceptually:
Service-manager tests require a host that can be destroyed or reset safely and should stay out of normal test discovery.
Related follow-ups
Focused correctness issues remain separate:
Those issues should not be folded into this acceptance tracker unless the missing acceptance scenario itself is the problem.
Acceptance criteria
dev.Close condition
Close this issue only when the deferred disposable-host/service-class coverage and remaining production census are complete. The workstation-safe subset delivered by #1106 is necessary but not sufficient for closure.