feat(runtime): add atomic workflow scheduler state-store and recovery boundary

Problem and canonical owner boundary

Noema's Workflow / Task Execution + State / Checkpoint bounded contexts require one durable authority that binds an admitted plan revision to atomic task claims, checkpoint CAS/replay, effect-aware recovery, cancellation, blocked-descendant handling, and bounded provenance. Provider/model routing remains owned by contextual-orchestrator; quarantine/security verdicts, outbound policy, identity/secret truth, and foreign product-domain truth stay outside this boundary.

Current protected authority — 2026-09-18 KST

Fresh protected Noema is GitHub-verified main@f38962869307a45b3b6e65692b2acbabb075e0eb after normal #721 integration. There is currently 1 open Noema pull request, Draft #722. #722 repairs private-vulnerability-reporting audit authentication only; it does not modify Workflow / Task lifecycle or State / Checkpoint authority and is not deployed-runtime/recovery evidence. Fresh GitHub Release inventory remains 0.

The Workflow / Task durable-state source established through #542 remains in protected ancestry. Protected #605 added observation-only read_operability on the existing execution-scoped NOEMA_WORKFLOW_STATE object; #606 normally merged the documentation/gap-baseline convergence as GitHub merge 8a03aabf9c0f2d02d1f17c9848ba9abe88f71753. Current protected docs/OPERABILITY.md still describes Workflow / Task operability as exact-object evidence on the same authority and permits only bounded platform metadata such as { database_size_bytes } after exact execution/plan admission and object-name verification. It explicitly rejects workflow/task payload export or mutation/retry/recovery authority from an operability read.

Later protected work does not replace this Workflow / Task authority. #714 hardens a distinct State / Checkpoint retained procedural-evaluation history transaction by completing cryptographic verification/hash work before the durable transaction and retaining only short revalidation/write authority inside it. #719/#721 similarly harden and document the separate Policy / Approval transaction boundary. Those invariants reinforce the repository-wide minimal-transaction rule but do not silently change Workflow / Task lifecycle truth or satisfy this issue's deployed-runtime acceptance.

ADR-0013 remains Proposed until real deployed transaction/runtime and rollback evidence exists.

Protected source contract

Current protected source retains:

execution-scoped plan authority and exact object binding;
atomic task claim and checkpoint CAS/replay semantics;
effect-start/completion/terminal authority, cancellation and recovery invariants;
retained provenance with malformed/corrupt record rejection;
restart reconstruction and legacy/conflicting-state refusal;
exact-object operability admission before reading ctx.storage.sql.databaseSize;
observation-only response shape { database_size_bytes } with no second metrics/state store and no public route.

This is source behavior and exact-object observation, not proof of deployed Durable Object transaction compatibility, successful external effects, restart/recovery, production storage growth, synchronous p95, rollback, or release identity.

Completion evidence

Current execution boundary

No repository-only change can manufacture the remaining deployed-runtime/recovery/performance evidence while Noema has no immutable Release and no governed production deployment. #722's queued hosted gates block only that security-audit lane; they do not create Workflow / Task deployment evidence. Source/docs/review work remains executable if a concrete Noema-owned regression appears, but synthetic fixtures, local workerd timing, PR checks, unit database_size_bytes, namespace aggregates, or historical merge receipts are not substitutes for production evidence.

Do not create a second Workflow / Task truth, use cross-service SQL, absorb provider routing/security/outbound identity authority, weaken exact-head/release/environment gates, or close this issue merely because source and documentation are protected.

Related: #5, #36, #40, #561, #584, #605, #606, #611, #714, #719, #721, #722.

Current #542 repair note — exact branch head 16c896eea3c8fc7112637eb1a4c0da089218c5e4 now closes one cancellation/recovery authority defect found during fresh source review. Test-first e83d7f09afdec4a9e16b66a98db83f4a6c522dcb adds the case where an idempotent task has durably crossed effect start before execution cancellation. Previous production recovery would clear the active claim and manufacture terminal cancelled, even though the first external invocation may already have completed. Production e2e49d1c506ee29f46d857c6624ffd832bb78782 now fails closed for cancellation + started/legacy-unknown idempotent evidence and retains the exact running claim for explicit outcome/reconciliation; ADR-0013 is code-current at 16c896ee.... No exact hosted RED was observed before the causal repair because the test-first head did not acquire a runner; current exact-head CI/reviewer/image are queued and required Security had not materialized, so this remains Draft/non-passing and must be revalidated after #528 integrates.

2026-09-04 KST fresh #542 application-boundary review found another issue-owned fail-open path in the required “effect start before side effect” semantics. executeNextWorkflowTask awaited statePort.markEffectStarted(...) but discarded the returned snapshot, so a state adapter that resolved without actually proving the exact claim crossed the durable effect boundary could still be followed by effectPort.execute(...).

TDD/source lineage on feat/workflow-state-store-atomic-claim:

RED 0c0c6811e7b0548e4223867023b0540f9c31696c: a real repository claim is created, while the injected state port's markEffectStarted only returns the current durable snapshot (effectStarted=false). The runner is required to reject and never invoke the effect.
production 637da325d7ffa5eeb5c376d2522c81b473d3642e: the runner now requires the returned snapshot to prove the same execution/plan/task/claim/attempt remains running with effectStarted=true before effect invocation; otherwise WorkflowTaskEffectAuthorityError fails closed.

Current PR #542 head is 637da325d7ffa5eeb5c376d2522c81b473d3642e on protected main@bbee33270b496255d785c766fc009a5f9162a695. Hosted GREEN is not claimed: current ci 33815852157 job 100847724463 is still queued, steps=[], runner_id=null; reviewer-ci 33815851966, required Security Scan 33815852018, and patch-validator-image 33815852061 are also queued. The central runner-control-plane owner .github#712 has received this exact-head canary. Issue #541 therefore remains open; no predecessor evidence transfers and the branch stays Draft.

Fresh executable application-boundary finding on #542: RED 891fa741083e5dcfe5a88b8b6d94db56705a2b10 adds a state-port fixture whose effect executes successfully but whose completeTask(...) returns only the still-running effect-start snapshot. The predecessor runner accepted that stale snapshot as a successful WorkflowTaskRunResult, so application composition could report completion without durable proof that the observed outcome became terminal authority. Production 3685ce56b09f50d4d653570d596b29496cfacc55 now requires the returned completion snapshot to match the exact execution/plan/task attempt, equal the observed terminal outcome, clear the active claim, retain effect-start evidence, and advance the transition sequence beyond the verified effect-start snapshot. Mismatch fails closed with WorkflowTaskTerminalAuthorityError; it does not fabricate retry/compensation or foreign authority. Hosted GREEN remains pending on the new exact head.

#542의 application-service claim authority를 다시 검토해 새 fail-open 경로를 확인하고 source-level TDD로 수리했습니다.

executeNextWorkflowTask(...)가 WorkflowTaskExecutionStatePort.claimNextRunnableTask(...) 반환값을 admitted plan/caller request에 다시 결합하지 않은 채 effect-start 단계로 넘기고 있었습니다. 따라서 잘못된 adapter가 durable repository에서는 실제 side_effecting task를 claim한 뒤, 호출자에게는 같은 identity에 effect: "pure"를 붙인 claim을 반환할 수 있었습니다. 기존 effect-start/terminal snapshots에는 effect classification이 반복되지 않으므로 후속 snapshot checks만으로는 이 substitution을 검출할 수 있고, effect port가 잘못된 recovery semantics의 claim을 받을 수 있었습니다.

RED 4f4625dfee0a293425da0ae182f6dd28c4783920: real repository에 side_effecting claim을 남긴 뒤 injected state port가 pure로 바꾼 claim을 반환하는 회귀를 추가했습니다. predecessor runner는 이를 effect-start/completion까지 진행할 수 있습니다.
production da225d15fe8681f7f36a5490a0de2d88c9969f27: WorkflowTaskClaimAuthorityError와 claim/plan binding 검증을 추가했습니다. effect-start 전에 executionId/planId/requested claimId/positive safe-integer attempt/admitted task identity/exact admitted effect classification이 모두 일치해야 합니다.

이 변경은 Noema의 Workflow / Task Execution + State / Checkpoint application boundary에만 있습니다. provider/model routing, foreign domain truth, quarantine/security verdict, outbound authority, retry/compensation authority는 가져오지 않았습니다.

현재 exact #542 head는 da225d15fe8681f7f36a5490a0de2d88c9969f27이고 Security Scan 33824089404, ci 33824089340, patch-validator-image 33824089343, reviewer-ci 33824089400이 모두 queued/non-passing입니다. 따라서 source repair만 기록하고 exact-head GREEN/merge-ready로 승격하지 않습니다.

2026-09-04 KST fresh #542 application-service claim review found a second bounded-attempt fail-open at the state-port seam. The durable repository and private command adapter already reject attempts above MAX_AUTOMATIC_RECOVERY_ATTEMPTS, but executeNextWorkflowTask(...) revalidated only that a returned claim attempt was a positive safe integer. A faulty/incompatible state adapter could therefore return attempt 4+ for an otherwise valid admitted task and reach effect-start handling instead of being rejected as impossible Noema execution authority.

TDD/source lineage on feat/workflow-state-store-atomic-claim:

RED c744f9dde9ffd30df1b99ce332b6440be6184905: creates a real retained claim, substitutes only attempt = MAX_AUTOMATIC_RECOVERY_ATTEMPTS + 1 at the WorkflowTaskExecutionStatePort return boundary, and requires WorkflowTaskClaimAuthorityError before markEffectStarted, effect execution, or completion.
production f3a02262ba7b15fc287fbfe61d9f61c6d3b744bb: requireClaimAuthority(...) now binds the returned attempt to the same canonical 1..MAX_AUTOMATIC_RECOVERY_ATTEMPTS interval already enforced by durable state and command admission. No retry/compensation/provider/security/foreign-domain authority was added.

Current exact #542 head is f3a02262ba7b15fc287fbfe61d9f61c6d3b744bb on protected main@bbee33270b496255d785c766fc009a5f9162a695. New exact-head runs materialized as ci 33827829254, reviewer-ci 33827829267, required Security Scan 33827829256, and patch-validator-image 33827829271; all remain non-terminal. CI job 100884174260 is still queued with steps=[], runner_id=null, runner_name=null. Hosted GREEN is therefore not claimed and #541 remains open.

#542 advanced with another application-boundary authority repair. RED 3f42df7650f420c2adb8ae42555b7b814868417f proves that a storage-independent WorkflowTaskExecutionStatePort could echo a caller-supplied non-canonical claim identity and the predecessor runner would proceed to effect-start persistence. Production da3c53c97b23fab7706a475e09c23806aa74d147 now rejects claim IDs outside the same 1–128 printable non-whitespace ASCII contract before any effect-start/effect/completion call. Exact-head hosted evidence is still non-terminal (ci 33831824296, reviewer-ci 33831824261, Security Scan 33831824262, patch-validator-image 33831824266 all queued), so this is source-level RED→repair evidence only and does not complete #541 acceptance.

Fresh #542 application-boundary repair on exact head eca1e634803dc85287077b0b14351800fed2537b:

RED/source regression fb54babc3072ea7ed59c17389cb505dc03054b31 changes the malformed caller-claim test to require rejection before WorkflowTaskExecutionStatePort.claimNextRunnableTask(...) is invoked. The predecessor runner only validated the state adapter's returned claim, so a non-canonical caller claim ID could cross the application→state authority boundary before failure.
Production eca1e634803dc85287077b0b14351800fed2537b admits caller claim IDs against the canonical 1–128 printable non-whitespace ASCII contract before the state-port call, then independently revalidates the returned claim/effect/attempt authority as before.
No retry, compensation, provider routing, foreign domain truth, quarantine/security verdict, or outbound authority was added.

This is source-level causal repair only until the unchanged exact head executes. Current ci 33835157976 / job 100906049938 is still queued with steps=[], runner_id=null; reviewer-ci, required Security Scan, and patch-validator-image are also non-terminal. Do not transfer predecessor GREEN.

Fresh review finding on #542 exact 9236775bad5476a70601c3dd0331211d42eaed12: the four hosted lanes are GREEN, but merge authority is now blocked by a newly verified durable-provenance integrity gap. validateTransitionLedger permits a positive transitionSequence with fewer than min(sequence, MAX_TRANSITION_RECEIPTS) retained receipts (including an empty vector), although every production appendTransition preserves exactly that bounded suffix. Corrupted Durable Object state can therefore erase retained causal receipts and still pass readState, contrary to ADR-0013's observable bounded-provenance invariant. Existing hostile tests cover partial ledger presence, sequence below receipt count, oversized vectors, malformed receipt fields, and the deliberate pre-ledger case where both fields are absent; they do not cover shortened receipt retention with a positive sequence. Required repair: hostile RED for shortened/empty retained suffix, then fail closed unless receipts.length === Math.min(sequence, MAX_TRANSITION_RECEIPTS), while preserving the both-fields-absent legacy compatibility case. The existing GREEN generation is no longer merge-authoritative even before the #554 restack.

Repair landed on the same #542 branch. Test-first 8e7e0bbf97ec3508445f1d522c923b5074d5f7db adds the hostile sequence-one/zero-retained-receipt RED. Production 35f80f2eb4a0e861eaa833ef2bb474c012deafbe adds only the five-line causal invariant requiring transitionReceipts.length === Math.min(transitionSequence, MAX_TRANSITION_RECEIPTS) whenever ledger fields are present. The explicit pre-ledger compatibility case still requires both fields to be absent. Compare from prior exact 9236775... is 2 commits / 2 paths: the new regression (+67) and the production validator (+5), no other semantic delta. Fresh exact-head CI 34038387937, reviewer 34038387942, Security 34038387882, image 34038387881 are newly queued; prior GREEN does not transfer. #542 remains Draft and still requires post-#554 non-force semantic restack/revalidation.

Follow-up hostile edge is now repaired too. 8afef5416a73bc2662f2e3fe10412dcc0798daeb proves an explicitly present transitionSequence=0 / empty receipt ledger must not be accepted as the legacy pre-ledger format; production never persists that shape because initialized is appended before the first put. 55194e1d75f1ca31e87a34dc78d1ef1216006825 adds the three-line fail-closed check while leaving the true compatibility path (both ledger fields absent) intact. Current exact #542 head is therefore 55194e1...; fresh CI 34038628405, reviewer 34038628417, Security 34038628437, image 34038628409 are non-terminal. Previous GREEN generations remain non-authoritative.

2026-09-06 KST fresh authority update: central .github/main has advanced again to ee5567f7b15f0441a61ec2435415603b9518f1c6. The dd0b96... -> ee5567... compare is exactly one central commit and changes only CodeQL-dispatch / required-workflow queue contract tests; .github/workflows/noema-review.yml is unchanged, but GitHub OIDC job_workflow_sha source identity still moves with the protected central commit. PR #554 was therefore repaired test-first from predecessor 12e9efe07f72acdf9f1eb0f7ef0fec54d2ad633c: RED contract 8ae02909c21ba0f791c12ee97d3f7294a2468ce4 requires ee5567...; production exact head 8501d25507d4ecd3024205a92a9a3de4157300da changes only wrangler.toml.ALLOWED_WORKFLOW_SHA to that audited source and was advanced non-force. Its fresh CI/reviewer/Security/image generation is currently non-terminal, so the predecessor four-GREEN generation does not transfer.

#542 remains exact 1909f232dec32cf5d5de40d927af9c22366d2a85 with all current inline review threads resolved. Its four hosted exact-head lanes are also still non-terminal. #554 remains the foundation prerequisite: after it integrates, #542 must ordinary/non-force restack onto the new protected main while preserving the private NOEMA_WORKFLOW_STATE binding and the then-current central trust pin, then regenerate all exact-head evidence. No provider/model, quarantine/security, outbound or foreign-domain authority moves into Noema.

2026-09-07 KST current-owner correction after post-#554 restack:

PR #542 exact 7f743f4ee8d81c8d52511ef421d8e40a32edf2a8 produced a real hosted test RED in CI 34063013448 / job 101566805084 after exact checkout, live-base resolution to protected main@0dec8d84b1e4744e7a9c6a77e2e2631a183ee2ab, lockfile control, install, and typecheck all passed. Release tests reported 577 test files passed / 1 failed and 4,079 tests passed / 1 failed. The sole failure was workflow-state-store-retained-provenance-integrity.test.ts → rejects a retained ledger containing a non-record receipt.

RCA: that fixture replaced receipt index 0 with null, simultaneously corrupting the sequence-one causal root and the receipt record shape. Production therefore correctly failed on the earlier causal-root invariant (must begin with initialized evidence or a legacy first task claim) while the test demanded the later receipt is malformed diagnostic. This is fixture ambiguity, not a production state-admission gap.

Minimum repair is now exact 4616b5e93e19d51973aea330aa4124b51725b795: the unit fixture preserves the valid sequence-one initialized receipt, advances the synthetic sequence to 2, and appends null as receipt 2. This isolates the non-record-receipt invariant without changing production validation, causal-root semantics, or the 100% coverage gate. Synthetic mutation remains unit-test-only.

Fresh current-head generation: CI 34064157863, reviewer-ci 34064157866, required Security Scan 34064157896, image 34064157873; all are new/non-terminal. Do not transfer predecessor GREEN. Current protected Noema remains 0dec8d84...; central .github/main remains c9052e607e5f3cc76e73207e7786b21500721b79.

2026-09-08 KST durable-workflow authority update: protected Noema advanced normally through #550 to GitHub-verified main@6b5b2c8e6a50ce383cf781c5386dff5381582f65. #542 predecessor 195fdd70b267332f246d93beb95fa96fabade52e had a complete four-GREEN generation but became stale after that protected advance, so no gate evidence was transferred.

I ordinary/non-force converged #542 again at exact c2bb6fa6feafacd2300a30647dcc457959d06482: first parent current protected 6b5b2c8..., second parent predecessor 195fdd70..., tree built from current protected main with exactly the effective 29-path Workflow / Task Execution + State / Checkpoint delta overlaid. Fresh compare is ahead-only, behind_by=0, merge-base exactly 6b5b2c8...; #550 concurrency truth and earlier reviewer/Shared Kernel authority are preserved.

Fresh review-thread sweep has unresolved finding count 0. New exact-head generations are ci 34142208815, reviewer-ci 34142208767, required Security Scan 34142208735, and patch-validator-image 34142208758; all were queued at first post-push observation. #542 remains Draft. Merge authority requires all four terminal GREEN on unchanged c2bb6fa... plus another fresh review/protected/central sweep. ADR-0013 remains Proposed because source composition still does not manufacture deployed Durable Object transaction/runtime evidence.

Fresh owner-lane update (2026-09-11 KST): protected Noema is GitHub-verified main@585b2f09c418e7d90e9e2729ee51f384e0602d9f after normal #604 integration. The existing NOEMA_WORKFLOW_STATE SQLite Durable Object remains the canonical Workflow / Task Execution + State / Checkpoint authority; no second store is being introduced.

Draft #605 is a bounded operability slice from that exact protected base. Test-only exact 24a4d6a00131bf4075db75a14f97b394a8d8d53a requires an observation-only read_operability command to route to the same execution-scoped object, return only { database_size_bytes }, drop caller-only extras before the private boundary, reject wrong-object routing, and fail closed when the exact-object SQLite byte counter is unavailable. At this observation its current application/reviewer/Security/image generations are queued and the application verify job has no assigned runner/steps yet, so no hosted RED or GREEN is claimed and no production source repair has been pushed.

This closes no #541 operational acceptance by itself. Even after source integration, real deployed transaction/restart/recovery behavior, contention denominators, exact-object storage growth, synchronous buyer-path latency where applicable, PITR/equivalent recovery, and immutable release/deployment provenance remain separate evidence. Cloudflare's current SQLite Durable Object API documents ctx.storage.sql.databaseSize as the current per-object SQLite database size in bytes; #605 is intended only to expose that already-owner-local observation through the existing private boundary, not to create a public metric API or workflow payload dump.

2026-09-11 KST source-operability update: Draft #605 remains on exact 758231307dd34716e2e2e05838f625330bed23f3 against protected main@585b2f09c418e7d90e9e2729ee51f384e0602d9f. The branch adds observation-only read_operability to the existing execution-scoped NOEMA_WORKFLOW_STATE Durable Object boundary and returns only { database_size_bytes } from the same object-local SQLite authority. The exact head now has terminal SUCCESS on application CI 34537148500, reviewer-ci 34537148434, required Security Scan 34537148591, and patch-validator-image 34537148637; no predecessor result is being transferred. This still proves source behavior only. Deployed Durable Object transaction/restart/recovery, representative storage-growth denominator, real p95, PITR/rollback and immutable release evidence remain open #541 acceptance. #605 also remains Draft because canonical OPERABILITY/CHANGELOG convergence is still a valid completion finding; current GREEN does not waive it.

Current owner-path update: Draft #605 now carries the bounded Workflow / Task operability producer. Review found that the first source implementation could return storage.sql.databaseSize after plan/object-name validation without first proving that the selected execution object retained current Noema execution-plan/state authority. Test-only 31a1e599fb76a4598b86e58c54ce51ccaca5ab86 adds the uninitialized-object conflict regression; causal 7639856ee6d20a59a144944ed21f1abc273fd386 reuses the existing DurableWorkflowStateRepository.readState(plan) path before reading platform storage metadata, so missing/malformed/mismatched retained authority fails closed and no second state/metrics store is created. b4fd8abb77a69847655e04a03fa63a72ea6d56b4 makes ADR-0013 code-current: retained state is validated internally but never returned; the success payload remains only { database_size_bytes }. ADR-0013 remains Proposed. Fresh Noema release inventory is still empty, so deployed Durable Object transaction/restart/recovery, representative exact-object storage-growth denominator, synchronous-path p95, PITR/rollback and immutable release evidence in this issue remain open. #605 stays Draft until all required gates on the unchanged final exact are terminal GREEN and a fresh review/base/thread sweep is clean.

2026-09-11 KST protected integration update: #605 exact b4fd8abb77a69847655e04a03fa63a72ea6d56b4 reached terminal SUCCESS on application CI 34542741791, reviewer-ci 34542741784, required Security Scan 34542741748, and patch-validator-image 34542741760; fresh current-head review found no remaining valid source/test/DDD/documentation finding or unresolved inline thread. It was marked Ready and normally merged with expected-head protection. The resulting GitHub-verified protected source is main@98942c88c228c18d44808db1c29bd8f165aa4167, preserving old main 585b2f09c418e7d90e9e2729ee51f384e0602d9f and #605 exact as merge parents.

Protected #605 now makes the existing execution-scoped NOEMA_WORKFLOW_STATE exact-object storage observation source authority: private read_operability revalidates retained execution-plan/state authority through the existing repository before reading ctx.storage.sql.databaseSize and returns only { database_size_bytes }. This does not close #541: deployed transaction/restart/recovery, representative exact-object storage-growth denominator, synchronous-path p95 where applicable, PITR/equivalent rollback and immutable release/deployment provenance remain open. ADR-0013 stays Proposed.

Post-merge docs-to-code sweep found the moving docs/product-technical-gap-baseline.md still ended its protected/current-gap classification at #603 and described this lane as only merged #542 / ADR 0013. Draft #606 is the single documentation-authority repair lane. Its test-only first exact af06f70971227ccfc148563b6055ca08be47b87a was superseded before execution and all four hosted generations were cancelled, so no hosted RED is claimed. Current #606 head is e24537150a1bff3e812d1ee6b52a585b150e5f22; it classifies #605 as protected source while preserving the deployed/recovery/release boundary. Fresh Noema GitHub Release inventory remains empty.

2026-09-11 authority refresh after normal #606 integration: protected Noema is GitHub-verified main@8a03aabf9c0f2d02d1f17c9848ba9abe88f71753; #605 exact-object Workflow / Task operability source and #606 baseline convergence are both protected, and there is no longer a Draft #606 lane. Noema GitHub Release inventory is still empty.

The completion boundary remains unchanged: protected source can validate retained execution-plan/state authority and read object-local { database_size_bytes }, but it is not deployed Durable Object transaction/restart/recovery evidence, a representative storage-growth denominator, synchronous-path p95, PITR/rollback rehearsal, or immutable release/deployment provenance. Do not manufacture those from unit fakes or source CI. The next valid #541 mutation requires an approved deployed target/release identity that can produce exact-object runtime/recovery receipts.

Navigation Menu

Repository navigation

feat(runtime): add atomic workflow scheduler state-store and recovery boundary #541

Problem and canonical owner boundary

Current protected authority — 2026-09-18 KST

Protected source contract

Completion evidence

Current execution boundary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

feat(runtime): add atomic workflow scheduler state-store and recovery boundary #541

Description

Problem and canonical owner boundary

Current protected authority — 2026-09-18 KST

Protected source contract

Completion evidence

Current execution boundary

Activity

seonghobae commented on Sep 2, 2026

seonghobae commented on Sep 3, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 6, 2026

seonghobae commented on Sep 6, 2026

seonghobae commented on Sep 6, 2026

seonghobae commented on Sep 6, 2026

seonghobae commented on Sep 6, 2026

seonghobae commented on Sep 7, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 11, 2026

seonghobae commented on Sep 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions