feat(#673): MachineStatusEvent flow and ROM-fraction stall detection

[9thLevelSoftware]

Summary

PR 2 of 3 for Issue #673. It widens the narrow deloadOccurredEvents: Flow<Unit> to Flow<MachineStatusEvent>, carrying the full SampleStatus, position, and velocity for every processed BLE monitor packet. It adds a geometric ROM-fraction signal as a secondary stall-arm path.

Refs #673 — non-final phase; PR 3 owns the closing keyword.

Independent value

• More reliable set-ending detection from continuous status, position, and velocity data.
• Conservative mid-ROM/dead-band detection that does not depend on DELOAD_WARN.
• A richer machine-status flow for future hardware behavior.

Audit correction: F5 was already resolved by earlier audit work. This PR adds a complementary reliability signal; it does not claim to close F5.

Changes

Machine-status flow

• New MachineStatusEvent(timestamp, sampleStatus, position, velocity) model.
• BleRepository.machineStatusEvents: Flow<MachineStatusEvent>.
• MonitorDataProcessor emits an event after smoothing for every processed packet, including status = 0, with maximum position and velocity magnitude.
• KableBleRepository forwards the rich event while retaining the existing derived deloadOccurredEvents flow for compatibility.
• FakeBleRepository supports deterministic event injection for behavioral tests.

ROM-fraction stall signal

• WorkoutCoordinator retains only ROM range extrema and clears them on auto-stop reset.
• ActiveSessionEngine calibrates ROM extrema from warmup samples, then permits arming only after normal auto-stop eligibility is open.
• The timer arms only when position is 30–80% of a meaningful calibrated ROM, velocity is 2.5–10 mm/s, standard-set/AMRAP guards permit it, and no timer is already active.
• Completed rep processing cancels the same shared stall timer.

Tests

• MonitorDataProcessorStatusEventTest: status event emission for non-zero and zero status packets, position selection, and legacy deload callback preservation.
• DWSMWorkoutLifecycleTest: warmup calibration enables later mid-ROM arming; out-of-band ROM/velocity does not arm; sustained in-window cable progress resets the countdown; DELOAD takeover survives ROM-window exit; and a completed working rep cancels a ROM-fraction timer.
• Fresh local verification:
  • ./gradlew -Pskip.supabase.check=true :shared:testAndroidHostTest
  • ./gradlew -Pskip.supabase.check=true :shared:compileKotlinIosArm64 :shared:compileTestKotlinIosArm64

Sequential phase requirement

PR #686 (Phase 1) was merged to working_branch, not main. It must be promoted into main before this Phase-2 PR is merged, preserving the signed-off three-phase sequence.

UI visual evidence

Not required for this non-UI phase. PR 3 is UI-involved and requires final in-app visual evidence.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[kilo-code-bot]

Code Review Roast 🔥

Verdict: No Issues Found | Recommendation: Merge

Oh look, the previous reviewer left a clean bill of health and the new commit kept the streak alive. One new @Volatile anchor field, one new else if branch gated correctly on stallArmedByRomFraction && !stallArmedByDeload, and the anchor gets nuked in every reset path it needs to be nuked in (DELOAD arm/upgrade, velocity stall arm, resetStallTimer, resetAutoStopState). I went looking for off-by-one races between the anchor == null lazy-init and a concurrent DELOAD upgrade and walked away empty-handed — the else-if gate on !stallArmedByDeload makes it impossible.

🏆 Best part: The new else if branch at ActiveSessionEngine.kt:732-744 does exactly one new thing — refresh the timer only when cable progress exceeds 5 mm. It doesn't try to be clever about velocity, doesn't fork a new state machine, doesn't introduce a new collector. It piggybacks on the existing in-window sample the collector was already evaluating. That is the correct amount of code for the problem.

💀 Worst part: Picking nits, ROM_FRACTION_STALL_PROGRESS_THRESHOLD_MM = 5f is a magic number with a comment justifying "filters ordinary sample noise" but no empirical basis. It's tunable, it's correct given the value, and it's a one-line constant — not worth blocking on.

📊 Overall: Like the previous commit, this is a one-feature-one-test patch that doesn't drag in any new bugs. The deload-takes-precedence invariant is now actively guarded by a regression test instead of just being asserted in comments.

Files Reviewed (3 files changed since previous SHA)

• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt — new else if progress-refresh branch + 4 anchor resets, all correctly gated
• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/WorkoutCoordinator.kt — one new constant, one new @Volatile field, one new reset line — all in the right places
• shared/src/commonTest/kotlin/com/devil/phoenixproject/presentation/manager/DWSMWorkoutLifecycleTest.kt — two new tests: refresh on progress, and deload-takes-precedence after out-of-window sample

---

Correctness / Safety Findings

No correctness or safety findings.

Ponytail Review

Ponytail: Lean already. Ship.

Ponytail net: 0 lines.

Suggested Minimal Patch

No patch needed.

Final Merge Guidance

Can merge as-is.

Previous Review Summaries (5 snapshots, latest commit 09b926d)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 09b926d)

Verdict: No Issues Found | Recommendation: Merge

Oh wait, this incremental change is actually clean. The previous Codex finding ("timer not cancelling when status leaves qualifying window") is fixed with the smallest possible surface area: one new @Volatile provenance flag, one new else if branch with a properly-guarded cancel, four flag-resets in arm/upgrade/reset paths, and one targeted regression test. I had my flamethrower warmed up and found nothing to burn.

🏆 Best part: The cancel branch (ActiveSessionEngine.kt:729-739) gates on stallArmedByRomFraction && !stallArmedByDeload. That's the correct, minimal way to say "I only cancel timers I armed, and I yield to the stronger DELOAD signal." No lock, no enum, no ceremony — two @Volatile flags do the job.

💀 Worst part: There's a theoretical race where the ROM collector's arm path and the DELOAD collector's arm path could both pass the stallStartTime == null check and clobber each other's flag writes. In practice the deload upgrade re-runs on subsequent deload events (self-healing), and the metrics are derived from the same packet source, so the window is microseconds. Not worth flagging as critical.

📊 Overall: Like finding a unicorn in production — a PR that adds state and logic without adding bugs. The fix is one logical commit with one logical test.

Files Reviewed (3 files changed since previous SHA)

• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt — provenance flag + cancel branch + 4 resets, all correct
• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/WorkoutCoordinator.kt — field declaration + reset, with truthful comment about why it must not cancel a deload-upgraded timer
• shared/src/commonTest/kotlin/com/devil/phoenixproject/presentation/manager/DWSMWorkoutLifecycleTest.kt — one new test covering the leave-window cancel branch

---

Correctness / Safety Findings

No correctness or safety findings.

Ponytail Review

Ponytail: Lean already. Ship.

Ponytail net: 0 lines.

Suggested Minimal Patch

No patch needed.

Final Merge Guidance

Can merge as-is.

Verdict

Approve — incremental fix is minimal, correct, and properly tested.

Previous review (commit 37a9429)

Verdict: 0 Active Findings | Recommendation: Merge

Overview

Severity	Count
🚨 critical	0
⚠️ warning	0
💡 suggestion	0
🤏 nitpick	0

The previous review's warning (warmup gate blocking ROM calibration) and suggestion (missing arm/cancel/no-arm tests) are both resolved in commit 37a94293:

• ActiveSessionEngine.kt:697 — shouldEnableAutoStop(params) is now called after the ROM range tracking block (lines 690-694). The comment on lines 688-689 is now truthful: ROM extrema are seeded during warmup, then arming is gated.
• DWSMWorkoutLifecycleTest.kt:972-1097 — Three new behavioral tests cover warmup calibration enabling later mid-ROM arming, out-of-mid-ROM/out-of-dead-band no-arm, and rep-event cancellation of a ROM-fraction-armed timer.

🏆 Best part: The fix is the minimum patch possible — one line moved, one comment updated, no new abstractions. The previous review's "hoist ROM tracking above the gate" suggestion is implemented literally.

💀 Worst part: The prepareRomFractionStallHarness helper takes a suspend () -> Unit advance parameter that every caller passes identically as { advanceUntilIdle() }. Tiny yagni smell, not worth fixing.

📊 Overall: The parachute now has the fabric deployed where it matters. Ship it.

Files Reviewed (1 file changed since previous SHA)

• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt — fix verified clean
• shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/model/MachineStatusEvent.kt — doc comment clarification
• shared/src/commonTest/kotlin/com/devil/phoenixproject/presentation/manager/DWSMWorkoutLifecycleTest.kt — 3 new tests added, all correct

---

Ponytail Review

Ponytail: Lean already. Ship.

Ponytail net: 0 lines.

Correctness / Safety Findings

No correctness or safety findings.

Final Merge Guidance

Can merge as-is. Both previous findings are resolved with minimum-surface-area changes.

Previous review (commit 18a4138)

Verdict: 2 Active Findings | Recommendation: Address before merge

Overview

Severity	Count
🚨 critical	0
⚠ warning	1
💡 suggestion	1
🤏 nitpick	0

Active Findings

• warning ActiveSessionEngine.kt:687 — shouldEnableAutoStop(params) internally checks isWarmupGateOpenForAutoStop() (line 1285) and returns false during warmup. The new comment on lines 689-690 claims ROM tracking happens "even during warmup," but the return@collect at line 687 fires first. Net: warmup rep positions never seed romRangeTop/romRangeBottom, so a stall during the first working rep has no calibrated range and cannot arm the ROM-fraction detector. Fix: hoist ROM tracking above the shouldEnableAutoStop gate, or split the helper so stallDetectionEnabled is checked separately from the warmup gate.
• suggestion ActiveSessionEngine.kt:714 — New collector's arm/cancel/no-arm logic still has zero test coverage. The PR description lists "ROM-fraction arm/cancel/no-arm scenarios" as an acceptance criterion, but only callback-plumbing tests were added. Fix: add 5 tests via FakeBleRepository.emitMachineStatusEvent(...) covering mid-ROM + dead-band arms, rep-event cancellation, out-of-mid-ROM no-arm, out-of-dead-band no-arm, sub-threshold range no-arm.

🏆 Best part: The dead-state cleanup is actually dead-state cleanup this time — romFraction / stallArmedByRomFraction fields, writes, resets, AND test assertions are all gone in one swing. That's the kind of commit message you can read without a painkiller.

💀 Worst part: The author moved the visible warmup gate but left shouldEnableAutoStop() — which itself contains a warmup check — sitting on the same line. The new comment claims ROM tracking happens "even during warmup," which is a lie the code doesn't back up. Like fixing a leaky pipe by relocating the bucket.

📊 Overall: Three of four wires are cut clean. The fourth still touches ground through a helper function nobody remembered to disconnect. Incremental progress — the parachute has more fabric, it just still won't deploy at altitude.

Files Reviewed (5 changed files)

• shared/src/commonMain/kotlin/com/devil/phoenixproject/data/ble/MonitorDataProcessor.kt — clean (gating + sign fixes verified)
• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt — 2 active findings (carry-forward)
• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/WorkoutCoordinator.kt — clean (dead state removed)
• shared/src/commonTest/kotlin/com/devil/phoenixproject/data/ble/MonitorDataProcessorStatusEventTest.kt — clean (test updated correctly)
• shared/src/commonTest/kotlin/com/devil/phoenixproject/presentation/manager/WorkoutCoordinatorAutoStopResetTest.kt — clean (dead assertions removed)

Fix these issues in Kilo Cloud

Previous review (commit 333a1c4)

Verdict: 1 Critical | Recommendation: Address before merge

Overview

Severity	Count
🚨 critical	1
⚠️ important	2
💡 suggestion	1
🤏 nitpick	0

Current Findings (click to expand)

File	Line	Roast
ActiveSessionEngine.kt	679	Collector still consumes machineStatusEvents, but MonitorDataProcessor.kt:230 only emits when packet.status != 0. The mid-ROM stall scenario produces status == 0 for the entire stall window — this collector cannot fire.
ActiveSessionEngine.kt	712	ARM/CANCEL/NO-ARM logic for the new collector still has zero coverage despite the PR claiming it.
MonitorDataProcessor.kt	236	Carry-forward (codex P2): max(smoothedVelocityA, smoothedVelocityB) is signed; during eccentric motion both velocities are negative, so event.velocity is negative and can never satisfy velocity >= 2.5 dead-band threshold. The ROM-fraction arm path is dead in the exact scenario it's designed for.
WorkoutCoordinator.kt	446	romFraction and stallArmedByRomFraction still written with @Volatile ceremony but never read by any control flow.

Resolved Since Last Review

• ✅ MonitorDataProcessorStatusEventTest.kt — DELOAD_OCCURRED bitmask corrected from 0x80 to 0x8000; timeProvider bumped to 3000L to clear the 2-second deload debounce. Tests now actually exercise the isDeloadOccurred() path.

Carry-Forward (Not Re-Commented)

• MonitorDataProcessor.kt:236 — velocity-magnitude issue (see codex P2 comment above). Still valid; covered by tabulated finding.

---

🏆 Best part: Commit 2 actually addressed the test bitmask bug cleanly — single-purpose fix, no scope creep. I had to double-check the commit hash to believe it.

💀 Worst part: The incremental diff is six lines of test fixes, and the structural critical bug it was supposed to address time for is still byte-for-byte identical. Timeout for stall detection shipping: whenever the smoke detector decides to attend the actual fire.

📊 Overall: Like a parachute with the ripcord wired to the altimeter — all the parts are present and well-named, the parachute just won't deploy at the right altitude. (Same verdict as last review, because nothing material changed.)

Files Reviewed (9 files)

• shared/src/commonMain/kotlin/com/devil/phoenixproject/data/ble/MonitorDataProcessor.kt — critical + important (carry-forward)
• shared/src/commonMain/kotlin/com/devil/phoenixproject/data/repository/BleRepository.kt — clean
• shared/src/commonMain/kotlin/com/devil/phoenixproject/data/repository/KableBleRepository.kt — clean
• shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/model/MachineStatusEvent.kt — clean
• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt — critical + important
• shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/WorkoutCoordinator.kt — suggestion
• shared/src/commonTest/kotlin/com/devil/phoenixproject/data/ble/MonitorDataProcessorStatusEventTest.kt — RESOLVED (bitmask fix)
• shared/src/commonTest/kotlin/com/devil/phoenixproject/presentation/manager/WorkoutCoordinatorAutoStopResetTest.kt — clean (only updated to assert dead-state fields; will rebaseline if dead state is deleted)
• shared/src/commonTest/kotlin/com/devil/phoenixproject/testutil/FakeBleRepository.kt — clean

Verdict

Request changes — critical gating bug (MonitorDataProcessor.kt:230) plus the newly-visible signed-velocity bug (MonitorDataProcessor.kt:236) still break the scenario this PR is supposed to detect. Test coverage for the new collector's arm logic is still missing.

Correctness / Safety Findings

• critical: ActiveSessionEngine.kt:679 — collector consumes machineStatusEvents, but MonitorDataProcessor.kt:230 only emits when packet.status != 0. Status flags are edge events; a user stalled motionless mid-ROM produces status == 0 for the entire stall window, so this arm path cannot fire. Fix: drop the if (packet.status != 0) gate in MonitorDataProcessor and let downstream filter, or have this collector consume metricsFlow instead.
• important: ActiveSessionEngine.kt:712 — new collector's arm/cancel/no-arm logic is untested despite the PR claiming coverage. Fix: add tests via FakeBleRepository.emitMachineStatusEvent(...) covering mid-ROM + dead-band arms, rep event cancels, out-of-mid-ROM no-arm, out-of-dead-band no-arm, sub-threshold range no-arm.
• important: MonitorDataProcessor.kt:236 — max(smoothedVelocityA, smoothedVelocityB) is signed; eccentric motion emits negative values, which fail the velocity >= 2.5 dead-band test. Fix: emit max(abs(smoothedVelocityA), abs(smoothedVelocityB)) (or absolute value, consistent with the existing stall calculation's use of absolute velocities). This finding is a carry-forward from the codex P2 comment already on the PR.
• suggestion: WorkoutCoordinator.kt:446,451 — romFraction and stallArmedByRomFraction are dead state (written, reset, never read). Delete the fields, their writes/resets, and the corresponding test assertions.

Ponytail Review

• WorkoutCoordinator.kt:446: yagni romFraction field. Never read. Delete.
• WorkoutCoordinator.kt:451: yagni stallArmedByRomFraction field. Never read. Delete.
• ActiveSessionEngine.kt:722: yagni write to stallArmedByRomFraction. Has no behavioral effect. Delete.
• ActiveSessionEngine.kt:1243: delete dead-state reset. Inline-reset is meaningless without a reader.
• WorkoutCoordinator.kt:483: delete dead-state resets for romFraction / stallArmedByRomFraction.
• WorkoutCoordinatorAutoStopResetTest.kt:30,50-51: test-shrink drop assertions for fields with no behavioral contract.
• ActiveSessionEngine.kt:705: shrink event.velocity.toDouble() widens a Float for no reason. Compare as Float directly.

Ponytail net: -12 lines.

Suggested Minimal Patch

1. In MonitorDataProcessor.kt, remove the if (packet.status != 0) { gate around onStatusEvent so the flow carries every packet — downstream decides what's interesting.
2. In MonitorDataProcessor.kt:236, emit max(abs(smoothedVelocityA), abs(smoothedVelocityB)) so the dead-band comparison works for eccentric motion.
3. Delete romFraction and stallArmedByRomFraction from WorkoutCoordinator and every write/reset/test assertion of them.
4. Add the four arm/cancel/no-arm tests described above using FakeBleRepository.emitMachineStatusEvent(...).

Final Merge Guidance

Do not merge until the critical gating fix AND the signed-velocity fix land, and the new collector has at least one arm + one no-arm test. The dead-state cleanup is optional but cheap.

Fix these issues in Kilo Cloud

Previous review (commit 7cba1cd)

Verdict: 1 Critical | Recommendation: Address before merge

Overview

Severity	Count
🚨 critical	1
⚠️ important	1
💡 suggestion	1
🤏 nitpick	0

Issue Details (click to expand)

File	Line	Roast
ActiveSessionEngine.kt	679	New collector subscribes to a flow that's only emitted when status != 0 — but the mid-ROM stall scenario this PR is designed to detect is exactly the case where status is 0 for the entire window.
ActiveSessionEngine.kt	712	PR claims "new tests for arm/cancel/no-arm scenarios" but only the reset-clears-fields test exists; the new collector's gate ordering and threshold logic has zero coverage.
WorkoutCoordinator.kt	446	romFraction and stallArmedByRomFraction are written and reset with full @Volatile ceremony but never read by any control flow.

---

🏆 Best part: The plumbing widening — MachineStatusEvent data class, the new machineStatusEvents flow, the FakeBleRepository test double — is genuinely clean. I had my flamethrower warmed up for MachineStatusEvent.kt and found almost nothing to burn.

💀 Worst part: The core stall-detection path can't actually fire in the scenario it's meant to detect. It's like installing a smoke detector that only triggers during a birthday party.

📊 Overall: Like a parachute with the ripcord wired to the altimeter — all the parts are present and well-named, the parachute just won't deploy at the right altitude.

---

Verdict

Request changes — critical gating bug breaks the very scenario this PR is supposed to detect.

Correctness / Safety Findings

• critical: ActiveSessionEngine.kt:679 — collector consumes machineStatusEvents, but MonitorDataProcessor.kt:230 only emits when packet.status != 0. Status flags are edge events; a user stalled motionless mid-ROM produces status == 0 for the entire stall window, so this arm path cannot fire. Fix: drop the if (packet.status != 0) gate in MonitorDataProcessor and let downstream filter, or have this collector consume metricsFlow instead.
• important: ActiveSessionEngine.kt:712 — new collector's arm/cancel/no-arm logic is untested despite the PR claiming coverage. Fix: add tests via FakeBleRepository.emitMachineStatusEvent(...) covering mid-ROM + dead-band arms, rep event cancels, out-of-mid-ROM no-arm, out-of-dead-band no-arm, sub-threshold range no-arm.
• suggestion: WorkoutCoordinator.kt:446,451 — romFraction and stallArmedByRomFraction are dead state (written, reset, never read). Delete the fields, their writes/resets, and the corresponding test assertions.

Ponytail Review

• WorkoutCoordinator.kt:446: yagni romFraction field. Never read. Delete.
• WorkoutCoordinator.kt:451: yagni stallArmedByRomFraction field. Never read. Delete.
• ActiveSessionEngine.kt:722: yagni write to stallArmedByRomFraction. Has no behavioral effect. Delete.
• ActiveSessionEngine.kt:1243: delete dead-state reset. Inline-reset is meaningless without a reader.
• WorkoutCoordinator.kt:483: delete dead-state resets for romFraction / stallArmedByRomFraction.
• WorkoutCoordinatorAutoStopResetTest.kt:30,50-51: test-shrink drop assertions for fields with no behavioral contract.
• ActiveSessionEngine.kt:705: shrink event.velocity.toDouble() widens a Float for no reason. Compare as Float directly.

Ponytail net: -12 lines.

Suggested Minimal Patch

1. In MonitorDataProcessor.kt, remove the if (packet.status != 0) { gate around onStatusEvent so the flow carries every packet — downstream decides what's interesting.
2. Delete romFraction and stallArmedByRomFraction from WorkoutCoordinator and every write/reset/test assertion of them.
3. Add the four arm/cancel/no-arm tests described above using FakeBleRepository.emitMachineStatusEvent(...).

Final Merge Guidance

Do not merge until the critical gating fix lands and the new collector has at least one arm + one no-arm test. The dead-state cleanup is optional but cheap.

Fix these issues in Kilo Cloud

---

_{Reviewed by minimax-m3 · Input: 36K · Output: 5.7K · Cached: 447K}

_{Review guidance: REVIEW.md from base branch main}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7cba1cd74b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 333a1c40a5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6e09b2b2dd

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 37a9429324

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 09b926dc21

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".