Effect Truth Slice A-C: Characterise, type, and settle (Epic)

[George-RD]

What to build

Effect Truth track: typed effect disposition and disposition-driven settlement (T1→T2→T3 critical path).

Sequence

T1: Effect Truth Slice A — Characterise and reproduce (#173, #174)
Map the current action → connector → reservation → audit flow; document every conversion that can lose attempted/not-attempted/unknown information; add regression tests reproducing the defects.

Stop condition: If the defects cannot be reproduced, STOP the track, write up observations, re-plan T2/T3.

T2: Effect Truth Slice B — Typed EffectDisposition
Introduce EffectDisposition (NotAttempted / ConfirmedSuccess / ConfirmedFailure / DeliveryUnknown) at the provider boundary. Gmail classifies 429/5xx/timeout-after-transmission as DeliveryUnknown unless the response proves non-occurrence. Behaviour unchanged except the proven defects.

T3: Effect Truth Slice C — Disposition-driven settlement
Settlement determined solely by disposition (NotAttempted/ConfirmedFailure cancel; ConfirmedSuccess finalizes; DeliveryUnknown retains and fences). Remove caller-side interpretation of generic errors. Production-entering tests for all four dispositions. Closes #173, #174.

Users served

Lyra, Bell, Unattended workhorse, Auditor. Promise: Ledger.

Evidence

Fold comments on #173 and #174 carry the review shape notes and are the authoritative source for this track.

Blocks

T17 action mediation deepening (#128, #133), T19 WhatsApp connector (#131), T22 responsibility composition (#132).

---

Parented by wayfinder map #182.

[coderabbitai]

Coding Plan

Summary

• Prove the defect first with characterization tests, then flip those tests when the fix lands. This makes the change visible and reviewable.
• Rename the existing EffectOutcome to EffectDisposition instead of adding a parallel taxonomy, because the four states already match the ticket.
• Classify the disposition on a shared Connector trait method at the provider boundary. This fixes Gmail 429/5xx, defines Telegram behaviour, and prepares the future WhatsApp connector.
• Consolidate all reservation settlement into one disposition-driven function. Remove the caller-side re-interpretation of generic errors.

Design Choices

Design Choice 1: Relationship between the existing EffectOutcome enum and the new EffectDisposition enum

Options Considered:

1. Rename EffectOutcome to EffectDisposition and rename its variants to NotAttempted/ConfirmedSuccess/ConfirmedFailure/DeliveryUnknown.
2. Add a new EffectDisposition enum at the provider boundary and keep EffectOutcome as the executor return type, converting between them.

Chosen Option: 1

Rationale: The existing enum is functionally identical to the requested enum. A single rename avoids a duplicate taxonomy. This rename matches the roadmap intent that EffectDisposition is a renaming and generalization of EffectOutcome.

Design Choice 2: Where the provider boundary classifies the disposition

Options Considered:

1. Add a classification method to the shared Connector trait in connectors.rs that maps a resolved provider error to an EffectDisposition.
2. Keep status-code logic inside gmail.rs and continue special-casing each connector in connector_breaker.rs.

Chosen Option: 1

Rationale: A trait-level classification seam removes the per-connector downcast_ref. This seam gives Telegram and WhatsApp a correct default. The exploration confirms this is the natural extension point.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Characterise and reproduce (Slice A)

This phase documents the current flow and proves the defect with tests before any behaviour changes. The tests assert the current wrong behaviour so the fix in later phases produces a visible, reviewable change. This phase also enforces the ticket stop condition.

Task 1: Document the effect flow and its lossy conversions

Record where attempted, not-attempted, or unknown information is lost.

• Add a design note under docs/ that maps the flow: api/actions.rs::mediate_and_dispatch_action → api/scoped_admission.rs::dispatch_scoped_effect → executor (pipeline/approval_draft.rs) → api/connector_breaker.rs → gmail.rs/telegram.rs.
• Document each conversion that loses information: gmail.rs::create_draft collapsing non-2xx (except 404) into GmailFailureClass::Api; connector_breaker.rs::map_write_error mapping Api to DispatchError::Connector; scoped_admission.rs mapping EffectOutcome to DispatchError; actions.rs re-deriving retain/cancel from the DispatchError variant.
• State the expected correct disposition for each provider condition (429, 5xx, timeout-after-transmission, definite 4xx, clean success).

Task 2: Add regression tests reproducing the 429/5xx defect

Reproduce the defect described in #173 and #174.

• Add tests near pipeline/tests/approval_draft_admission_tests.rs that mount a wiremock 429 and a 503 response on the /gmail/v1/users/me/drafts POST, following the existing pattern in definite_write_failure_is_failed_after_attempt_and_resolves_the_fence.
• Assert the current wrong behaviour: the outcome is EffectOutcome::FailedAfterAttempt, the pending-write fence is resolved, and the reservation is cancelled.
• Add a unit test near connector_breaker.rs::confirmed_gmail_api_write_failure_is_connector_error that shows a status: Some(429) and a status: Some(503) currently map to DispatchError::Connector.
• Mark these tests clearly as characterization of the defect so a later phase can flip their assertions.

Task 3: Confirm the timeout path and record the stop-condition result

Confirm which behaviours already work and record the go/no-go decision.

• Confirm the existing outer-timeout coverage (draft_write_timeout_is_delivery_unknown_and_leaves_pending_row) already asserts retain-and-fence, so the timeout path needs no new reproduction.
• Record in the Task 1.1 note that the 429/5xx defect is reproduced. If the defect cannot be reproduced, stop the track and write up the observations instead of proceeding to Phase 2.

🤖 Prompt for AI agents

Implement Phase 1: characterize the current effect flow and reproduce the
429/5xx defect with tests, without changing behaviour.

- Write a design note under `docs/` that traces the flow
`api/actions.rs::mediate_and_dispatch_action` →
`api/scoped_admission.rs::dispatch_scoped_effect` → executor
(`pipeline/approval_draft.rs`) → `api/connector_breaker.rs` →
`gmail.rs`/`telegram.rs`.
- In the note, document each lossy conversion: `gmail.rs::create_draft`
collapsing non-2xx (except 404) into `GmailFailureClass::Api`;
`connector_breaker.rs::map_write_error` mapping `Api` to
`DispatchError::Connector`; `scoped_admission.rs` mapping `EffectOutcome` to
`DispatchError`; `actions.rs` re-deriving retain/cancel from the `DispatchError`
variant.
- State the expected correct disposition for each provider condition: 429, 5xx,
timeout-after-transmission, definite 4xx, and clean success.
- Add regression tests near `pipeline/tests/approval_draft_admission_tests.rs`
that mount wiremock `429` and `503` responses on the `/gmail/v1/users/me/drafts`
POST, following the pattern in
`definite_write_failure_is_failed_after_attempt_and_resolves_the_fence`. Assert
the current wrong behaviour: `EffectOutcome::FailedAfterAttempt`, a resolved
pending-write fence, and a cancelled reservation.
- Add a unit test near
`connector_breaker.rs::confirmed_gmail_api_write_failure_is_connector_error`
showing `status: Some(429)` and `status: Some(503)` currently map to
`DispatchError::Connector`.
- Mark all new tests clearly as characterizing the defect, so Phase 2 can flip
their assertions.
- Confirm the existing outer-timeout test
(`draft_write_timeout_is_delivery_unknown_and_leaves_pending_row`) already
asserts retain-and-fence; do not add new timeout reproduction.
- Record the defect-reproduction result in the design note. If the defect cannot
be reproduced, stop the track and write up the observations instead of
proceeding to Phase 2.

Phase 2: Typed EffectDisposition at the provider boundary (Slice B)

This phase introduces the typed disposition and classifies it at the provider boundary. Behaviour must stay unchanged except for the proven defect. The scope is the classification seam and Gmail status handling.

Task 1: Establish the EffectDisposition type

Adopt a single typed disposition across the effect path.

• Rename EffectOutcome in api/effect_executors.rs to EffectDisposition and rename its variants to NotAttempted, ConfirmedSuccess, ConfirmedFailure, DeliveryUnknown.
• Update all producers and consumers of the old name (pipeline/approval_draft.rs, api/scoped_admission.rs, tests) to the new type and variant names.
• Keep the documented semantics: DeliveryUnknown leaves the pending-write fence open; ConfirmedFailure and NotAttempted resolve or never open the fence.

Task 2: Preserve provider status granularity in Gmail

Stop collapsing distinct statuses into one class.

• Update gmail.rs::create_draft (and the other write-facing helpers) to preserve the HTTP status distinction: 429 and 5xx must be distinguishable from other 4xx.
• Split or extend GmailFailureClass so a 429/5xx maps to an ambiguous class and other non-2xx (except the existing 404 case) maps to a definite-rejection class.
• Update gmail/tests.rs (for example a_non_404_api_error_is_not_treated_as_missing) to reflect the finer classification.

Task 3: Classify disposition at the connector seam

Move classification onto a shared, generalizable contract.

• Add a classification method to the Connector trait in connectors.rs that maps a resolved provider error to an EffectDisposition. Provide a conservative default for connectors without specific logic.
• Implement the Gmail classification: 429, 5xx, and transport/malformed-response map to DeliveryUnknown unless the response proves non-occurrence; definite 4xx rejections map to ConfirmedFailure.
• Update connector_breaker.rs::map_write_error to call the trait classification instead of the Gmail-only downcast_ref. Keep the outer-timeout path mapping to DeliveryUnknown for every connector.
• Keep Telegram flowing through the default classification so its behaviour is defined rather than accidental. This default also serves the future WhatsApp connector (T19).

Task 4: Flip the Phase 1 characterization tests

Confirm the defect is fixed and behaviour is otherwise unchanged.

• Update the tests added in Task 1.2 so the 429 and 5xx cases now assert DeliveryUnknown, an open fence, and a retained reservation.
• Update the connector_breaker.rs unit test so 429/503 now map to DispatchError::DeliveryUnknown while a definite 4xx still maps to DispatchError::Connector.
• Confirm existing success, definite-4xx, and timeout tests still pass to prove behaviour is unchanged outside the proven defect.

🤖 Prompt for AI agents

Implement Phase 2: introduce the typed `EffectDisposition` and classify it at
the provider boundary, keeping all other behaviour unchanged except for the
proven 429/5xx defect.

- Rename `EffectOutcome` in `api/effect_executors.rs` to `EffectDisposition`.
Rename its variants to `NotAttempted`, `ConfirmedSuccess`, `ConfirmedFailure`,
`DeliveryUnknown`.
- Update all producers and consumers of the old name and variants, including
`pipeline/approval_draft.rs`, `api/scoped_admission.rs`, and related tests.
- Preserve the documented semantics: `DeliveryUnknown` leaves the pending-write
fence open; `ConfirmedFailure` and `NotAttempted` resolve or never open the
fence.
- Update `gmail.rs::create_draft` and the other write-facing helpers to preserve
the HTTP status distinction, so 429 and 5xx are distinguishable from other 4xx
statuses.
- Split or extend `GmailFailureClass` so 429/5xx maps to an ambiguous class and
other non-2xx (except the existing 404 case) maps to a definite-rejection class.
- Update `gmail/tests.rs` (for example
`a_non_404_api_error_is_not_treated_as_missing`) to match the finer
classification.
- Add a classification method to the `Connector` trait in `connectors.rs` that
maps a resolved provider error to an `EffectDisposition`. Provide a conservative
default for connectors without specific classification logic.
- Implement the Gmail classification: map 429, 5xx, and
transport/malformed-response to `DeliveryUnknown` unless the response proves
non-occurrence; map definite 4xx rejections to `ConfirmedFailure`.
- Update `connector_breaker.rs::map_write_error` to call the trait
classification method instead of the Gmail-only `downcast_ref`. Keep the
outer-timeout path mapping to `DeliveryUnknown` for every connector.
- Let Telegram use the default classification so its behaviour is defined. This
default must also work for the future WhatsApp connector (T19).
- Update the Phase 1 characterization tests: flip the 429/5xx test assertions to
`DeliveryUnknown`, an open fence, and a retained reservation. Flip the
`connector_breaker.rs` unit test so 429/503 map to
`DispatchError::DeliveryUnknown`, while a definite 4xx still maps to
`DispatchError::Connector`.
- Confirm existing success, definite-4xx, and timeout tests still pass to prove
behaviour outside the fixed defect is unchanged.

Phase 3: Disposition-driven settlement (Slice C)

This phase makes settlement depend only on the disposition and removes the caller-side interpretation of generic errors. It consolidates the scattered finalize/retain/cancel logic into one path.

Task 1: Carry the typed disposition through dispatch

Stop erasing the disposition into a generic error and re-deriving it.

• Update api/scoped_admission.rs::dispatch_scoped_effect and the dispatch path in api/actions.rs so the typed EffectDisposition reaches the settlement site directly, instead of being collapsed into a DispatchError variant and re-interpreted.
• Preserve the caller-facing Result/error surface where other layers still need it, but source the settlement decision from the disposition.

Task 2: Introduce a single disposition-driven settlement function

Consolidate the duplicated settlement logic.

• Add one settlement function that maps an EffectDisposition to a reservation action: ConfirmedSuccess finalizes; NotAttempted and ConfirmedFailure cancel; DeliveryUnknown retains and leaves the fence open.
• Apply this function uniformly to the consult reservation, each disclosure reservation, and the fired-exception reservation, using the existing store primitives in store/standing_rules_budget.rs (finalize_standing_rule_reservation, finalize_standing_rule_exception_reservation, cancel_standing_rule_reservation, note_standing_rule_use[_with_lapse]).
• Replace the near-duplicate success-finalize, retain-note, and cancel blocks in api/actions.rs::mediate_and_dispatch_action with calls to this function.

Task 3: Remove caller-side interpretation of generic errors

Eliminate the second, error-typed copy of the disposition table.

• Remove the retain_reservation = matches!(err, DeliveryUnknown | Resource ...) re-derivation in api/actions.rs.
• Reconcile the independent cancel-on-audit-failure logic in api/scoped_admission.rs::consult_scoped_rule, disclosure.rs::cancel_reservations, and cleanup_pre_effect_reservations so pre-effect failures resolve to NotAttempted and settle through the single function.
• Update the doc table above dispatch_scoped_effect to describe disposition-driven settlement as the single source of truth.

Task 4: Add production-entering tests for all four dispositions

Prove end-to-end settlement for each disposition.

• Add tests that drive a full dispatch for each disposition: ConfirmedSuccess finalizes the reservation; ConfirmedFailure cancels it; NotAttempted never consumes budget; DeliveryUnknown retains the reservation and leaves the fence open.
• Cover both Gmail and the shared connector seam so the classification and settlement paths are exercised together.
• Confirm these tests close the defects tracked by #173 and #174.

🤖 Prompt for AI agents

Implement Phase 3: drive reservation settlement solely from the
`EffectDisposition` and remove caller-side interpretation of generic errors.

- Update `api/scoped_admission.rs::dispatch_scoped_effect` and the dispatch path
in `api/actions.rs` so the typed `EffectDisposition` reaches the settlement site
directly, instead of being collapsed into a `DispatchError` variant and
re-interpreted. Preserve the caller-facing `Result`/error surface where other
layers still need it, but source the settlement decision from the disposition.
- Add one settlement function that maps an `EffectDisposition` to a reservation
action: `ConfirmedSuccess` finalizes; `NotAttempted` and `ConfirmedFailure`
cancel; `DeliveryUnknown` retains and leaves the fence open.
- Apply this settlement function uniformly to the consult reservation, each
disclosure reservation, and the fired-exception reservation, using the existing
store primitives in `store/standing_rules_budget.rs`:
`finalize_standing_rule_reservation`,
`finalize_standing_rule_exception_reservation`,
`cancel_standing_rule_reservation`, `note_standing_rule_use[_with_lapse]`.
- Replace the near-duplicate success-finalize, retain-note, and cancel blocks in
`api/actions.rs::mediate_and_dispatch_action` with calls to the new settlement
function.
- Remove the `retain_reservation = matches!(err, DeliveryUnknown | Resource
...)` re-derivation in `api/actions.rs`.
- Reconcile the independent cancel-on-audit-failure logic in
`api/scoped_admission.rs::consult_scoped_rule`,
`disclosure.rs::cancel_reservations`, and `cleanup_pre_effect_reservations`, so
pre-effect failures resolve to `NotAttempted` and settle through the single
settlement function.
- Update the doc table above `dispatch_scoped_effect` to describe
disposition-driven settlement as the single source of truth.
- Add tests that drive a full dispatch for each of the four dispositions:
`ConfirmedSuccess` finalizes the reservation; `ConfirmedFailure` cancels it;
`NotAttempted` never consumes budget; `DeliveryUnknown` retains the reservation
and leaves the fence open.
- Cover both Gmail and the shared connector seam in these tests, so the
classification and settlement paths are exercised together.
- Confirm these tests close the defects tracked by `#173` and `#174`.

Research

The kernel executes effects through a fixed flow. api/actions.rs::mediate_and_dispatch_action reserves standing-rule budget, dispatches the effect, then settles the reservation. Effect executors return a typed EffectOutcome (Executed, RefusedPreEffect, DeliveryUnknown, FailedAfterAttempt) defined in api/effect_executors.rs. api/connector_breaker.rs is the single choke point for every connector call (Gmail and Telegram today); it applies admission, timeout, and breaker logic, then classifies errors with map_write_error and map_admission_error. gmail.rs returns a GmailError with a GmailFailureClass. api/scoped_admission.rs maps EffectOutcome to DispatchError, and api/actions.rs then re-derives finalize/retain/cancel from the DispatchError variant. The store-level settlement primitives live in store/standing_rules_budget.rs and take reservation IDs, not outcome types.

The defect has two roots. First, gmail.rs::create_draft collapses every non-2xx status except 404 into GmailFailureClass::Api, so 429 and 5xx are indistinguishable from a definite 4xx client error. Second, connector_breaker.rs::map_write_error maps GmailFailureClass::Api to DispatchError::Connector (confirmed failure), so a 429/5xx cancels the reservation instead of retaining and fencing it. The same choke point uses a Gmail-only downcast_ref, so Telegram (and any future connector) has no classification at all and always falls through to confirmed failure.

Per DIRECTION.md, the OpenSpec change ceremony is retired for new work. This track follows the wayfinder workflow and is parented by wayfinder map #182. Do not author changes under openspec/changes/.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: characterize the current effect flow and reproduce the
429/5xx defect with tests, without changing behaviour.

- Write a design note under `docs/` that traces the flow
`api/actions.rs::mediate_and_dispatch_action` →
`api/scoped_admission.rs::dispatch_scoped_effect` → executor
(`pipeline/approval_draft.rs`) → `api/connector_breaker.rs` →
`gmail.rs`/`telegram.rs`.
- In the note, document each lossy conversion: `gmail.rs::create_draft`
collapsing non-2xx (except 404) into `GmailFailureClass::Api`;
`connector_breaker.rs::map_write_error` mapping `Api` to
`DispatchError::Connector`; `scoped_admission.rs` mapping `EffectOutcome` to
`DispatchError`; `actions.rs` re-deriving retain/cancel from the `DispatchError`
variant.
- State the expected correct disposition for each provider condition: 429, 5xx,
timeout-after-transmission, definite 4xx, and clean success.
- Add regression tests near `pipeline/tests/approval_draft_admission_tests.rs`
that mount wiremock `429` and `503` responses on the `/gmail/v1/users/me/drafts`
POST, following the pattern in
`definite_write_failure_is_failed_after_attempt_and_resolves_the_fence`. Assert
the current wrong behaviour: `EffectOutcome::FailedAfterAttempt`, a resolved
pending-write fence, and a cancelled reservation.
- Add a unit test near
`connector_breaker.rs::confirmed_gmail_api_write_failure_is_connector_error`
showing `status: Some(429)` and `status: Some(503)` currently map to
`DispatchError::Connector`.
- Mark all new tests clearly as characterizing the defect, so Phase 2 can flip
their assertions.
- Confirm the existing outer-timeout test
(`draft_write_timeout_is_delivery_unknown_and_leaves_pending_row`) already
asserts retain-and-fence; do not add new timeout reproduction.
- Record the defect-reproduction result in the design note. If the defect cannot
be reproduced, stop the track and write up the observations instead of
proceeding to Phase 2.
===============================================================================

Task: 2

Implement Phase 2: introduce the typed `EffectDisposition` and classify it at
the provider boundary, keeping all other behaviour unchanged except for the
proven 429/5xx defect.

- Rename `EffectOutcome` in `api/effect_executors.rs` to `EffectDisposition`.
Rename its variants to `NotAttempted`, `ConfirmedSuccess`, `ConfirmedFailure`,
`DeliveryUnknown`.
- Update all producers and consumers of the old name and variants, including
`pipeline/approval_draft.rs`, `api/scoped_admission.rs`, and related tests.
- Preserve the documented semantics: `DeliveryUnknown` leaves the pending-write
fence open; `ConfirmedFailure` and `NotAttempted` resolve or never open the
fence.
- Update `gmail.rs::create_draft` and the other write-facing helpers to preserve
the HTTP status distinction, so 429 and 5xx are distinguishable from other 4xx
statuses.
- Split or extend `GmailFailureClass` so 429/5xx maps to an ambiguous class and
other non-2xx (except the existing 404 case) maps to a definite-rejection class.
- Update `gmail/tests.rs` (for example
`a_non_404_api_error_is_not_treated_as_missing`) to match the finer
classification.
- Add a classification method to the `Connector` trait in `connectors.rs` that
maps a resolved provider error to an `EffectDisposition`. Provide a conservative
default for connectors without specific classification logic.
- Implement the Gmail classification: map 429, 5xx, and
transport/malformed-response to `DeliveryUnknown` unless the response proves
non-occurrence; map definite 4xx rejections to `ConfirmedFailure`.
- Update `connector_breaker.rs::map_write_error` to call the trait
classification method instead of the Gmail-only `downcast_ref`. Keep the
outer-timeout path mapping to `DeliveryUnknown` for every connector.
- Let Telegram use the default classification so its behaviour is defined. This
default must also work for the future WhatsApp connector (T19).
- Update the Phase 1 characterization tests: flip the 429/5xx test assertions to
`DeliveryUnknown`, an open fence, and a retained reservation. Flip the
`connector_breaker.rs` unit test so 429/503 map to
`DispatchError::DeliveryUnknown`, while a definite 4xx still maps to
`DispatchError::Connector`.
- Confirm existing success, definite-4xx, and timeout tests still pass to prove
behaviour outside the fixed defect is unchanged.
===============================================================================

Task: 3

Implement Phase 3: drive reservation settlement solely from the
`EffectDisposition` and remove caller-side interpretation of generic errors.

- Update `api/scoped_admission.rs::dispatch_scoped_effect` and the dispatch path
in `api/actions.rs` so the typed `EffectDisposition` reaches the settlement site
directly, instead of being collapsed into a `DispatchError` variant and
re-interpreted. Preserve the caller-facing `Result`/error surface where other
layers still need it, but source the settlement decision from the disposition.
- Add one settlement function that maps an `EffectDisposition` to a reservation
action: `ConfirmedSuccess` finalizes; `NotAttempted` and `ConfirmedFailure`
cancel; `DeliveryUnknown` retains and leaves the fence open.
- Apply this settlement function uniformly to the consult reservation, each
disclosure reservation, and the fired-exception reservation, using the existing
store primitives in `store/standing_rules_budget.rs`:
`finalize_standing_rule_reservation`,
`finalize_standing_rule_exception_reservation`,
`cancel_standing_rule_reservation`, `note_standing_rule_use[_with_lapse]`.
- Replace the near-duplicate success-finalize, retain-note, and cancel blocks in
`api/actions.rs::mediate_and_dispatch_action` with calls to the new settlement
function.
- Remove the `retain_reservation = matches!(err, DeliveryUnknown | Resource
...)` re-derivation in `api/actions.rs`.
- Reconcile the independent cancel-on-audit-failure logic in
`api/scoped_admission.rs::consult_scoped_rule`,
`disclosure.rs::cancel_reservations`, and `cleanup_pre_effect_reservations`, so
pre-effect failures resolve to `NotAttempted` and settle through the single
settlement function.
- Update the doc table above `dispatch_scoped_effect` to describe
disposition-driven settlement as the single source of truth.
- Add tests that drive a full dispatch for each of the four dispositions:
`ConfirmedSuccess` finalizes the reservation; `ConfirmedFailure` cancels it;
`NotAttempted` never consumes budget; `DeliveryUnknown` retains the reservation
and leaves the fence open.
- Cover both Gmail and the shared connector seam in these tests, so the
classification and settlement paths are exercised together.
- Confirm these tests close the defects tracked by `#173` and `#174`.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!