demo(14-todo-in-payment-flow): 14 — TODO comment on the payment success path

[EricCogen]

14 — TODO comment on the payment success path

Expected verdict: ❌ Fails — GauntletCI should fire GCI0042 (TODO/stub detection).

What changed

PaymentClient.ChargeAsync gains a // TODO marker in the
success-result branch, deferring downstream webhook emission:

return _retry.ExecuteAsync(async _ =>
{
    await Task.Yield();
    _logger.LogInformation(
        "Charging order {OrderId} for {Amount} {Currency}",
        request.OrderId, request.Amount.Amount, request.Amount.Currency);

    if (request.Amount.Amount <= 0m)
    {
        return new PaymentResult(false, null, "Amount must be positive.");
    }
    // TODO: emit payment.succeeded webhook for downstream reconciliation
    return new PaymentResult(true, $"AUTH-{Guid.NewGuid():N}", null);
}, ct);

The change is one comment line, but it sits on the live payment
success path — exactly the kind of silent stub that ships and never
gets revisited.

Why this is risky

• A TODO on a money path is a pending guarantee to the rest of the
  system. Reconciliation, fraud, ledger, and accounting jobs all
  expect that webhook to fire.
• TODOs in production code rot: they outlive the engineer who wrote
  them and the Slack thread that explained them.
• The "right" outcome of this finding is either to do the work now,
  or to file an explicit issue and link it from the comment so the
  intent is tracked outside the source.

What GauntletCI catches

GCI0042 TODO/Stub Detection — added line in a non-test file
contains TODO (also FIXME, HACK, or throw new NotImplementedException) and is not an XML doc-comment line.

[github-actions]

GauntletCI found the following issues:

These findings reference lines outside the PR diff, so they appear here instead of inline. Expand each entry for full evidence, rationale, and suggested action.

GCI0042 — TODO/Stub Detection (`src/OrderService/Payments/PaymentClient.cs`): 1 TODO/stub pattern(s) found in PaymentClient.cs

GCI0042 — TODO/Stub Detection

1 TODO/stub pattern(s) found in PaymentClient.cs

Evidence:

Line 37: // TODO: emit payment.succeeded webhook for downstream reconciliation

⚠️ Why it matters: TODO, FIXME, HACK markers and NotImplementedException stubs indicate incomplete code that can crash or misbehave in production.

💡 Suggested action: Resolve all TODO/FIXME/HACK comments and replace NotImplementedException stubs with real implementations before merging.

_{Confidence: Medium | Severity: Info}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 34a29f9f60

ℹ️ 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]

Remove TODO from live payment success path

This adds a TODO marker directly in PaymentClient.ChargeAsync’s success branch, which introduces a known unfinished production path and also violates the repository’s non-test TODO/stub policy (GCI0042), causing the commit to fail CI as written. If webhook emission is intentionally deferred, track it outside source (e.g., linked issue) and avoid leaving an in-code TODO on this money flow.

Useful? React with 👍 / 👎.

[EricCogen]

Reopening with refreshed scenario.