apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/bounties/bounty-card.tsx (1)

1-1: Avoid recomputing getBountyRewardDescription(bounty) in the card body

The new reward row looks good and makes use of the shared helper, but you’re calling getBountyRewardDescription(bounty) twice per render. It’s cheap, but a local constant improves clarity and keeps condition + content in sync.

You could do:

 export function BountyCard({ bounty }: { bounty: BountyListProps }) {
-  const { slug: workspaceSlug, isOwner } = useWorkspace();
+  const { slug: workspaceSlug, isOwner } = useWorkspace();
+  const rewardDescription = getBountyRewardDescription(bounty);
@@
-          {getBountyRewardDescription(bounty) && (
+          {rewardDescription && (
             <div className="text-content-subtle font-regular flex items-center gap-2 text-sm">
               <Gift className="size-3.5" />
-              <span>{getBountyRewardDescription(bounty)}</span>
+              <span>{rewardDescription}</span>
             </div>
           )}

Also applies to: 9-9, 74-79

apps/web/ui/partners/bounties/claim-bounty-modal.tsx (1)

9-9: Reuse a local rewardDescription in the claim modal header

The new Gift + reward row is a nice UX improvement, but getBountyRewardDescription(bounty) is evaluated twice.

Precompute once at the top of ClaimBountyModalContent and reuse:

 function ClaimBountyModalContent({ bounty }: ClaimBountyModalProps) {
   const { submission } = bounty;
+  const rewardDescription = getBountyRewardDescription(bounty);
@@
-                  {getBountyRewardDescription(bounty) && (
+                  {rewardDescription && (
                     <div className="text-content-subtle flex items-center gap-2 text-sm font-medium">
                       <Gift className="size-3.5" />
-                      <span>{getBountyRewardDescription(bounty)}</span>
+                      <span>{rewardDescription}</span>
                     </div>
                   )}

This keeps the condition and displayed text guaranteed in sync and mirrors the pattern used on the cards. Based on learnings, this also centralizes the flat-rate vs custom reward semantics via the helper.

Also applies to: 21-21, 303-308

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/bounties/[bountyId]/bounty-info.tsx (1)

89-96: Precompute rewardDescription once, guarding for bounty being null

The reward row correctly uses getBountyRewardDescription, but it’s recomputed inside JSX. Given bounty can be null while loading, a small helper variable keeps things both safe and clearer.

For example:

 export function BountyInfo() {
   const { bounty, loading } = useBounty();
   const { isOwner } = useWorkspace();
+  const rewardDescription = bounty
+    ? getBountyRewardDescription(bounty)
+    : "";
@@
-        {getBountyRewardDescription(bounty) && (
+        {rewardDescription && (
           <div className="text-content-subtle font-regular flex items-center gap-2 text-sm">
             <Gift className="size-4 shrink-0" />
-            <span className="text-ellipsis">
-              {getBountyRewardDescription(bounty)}
-            </span>
+            <span className="text-ellipsis">{rewardDescription}</span>
           </div>
         )}

This avoids any chance of calling the helper with an undefined bounty while still using the same truthy check for rendering.

apps/web/app/(ee)/partners.dub.co/(dashboard)/programs/[programSlug]/(enrolled)/bounties/partner-bounty-card.tsx (2)

1-1: Use a local rewardDescription constant in PartnerBountyCard

The reward row looks good and matches the other bounty surfaces, but again getBountyRewardDescription(bounty) is called twice.

You can mirror the other suggested pattern:

 export function PartnerBountyCard({ bounty }: { bounty: PartnerBountyProps }) {
   const { programSlug } = useParams();
   const { claimBountyModal, setShowClaimBountyModal } = useClaimBountyModal({
     bounty,
   });
+  const rewardDescription = getBountyRewardDescription(bounty);
@@
-            {getBountyRewardDescription(bounty) && (
+            {rewardDescription && (
               <div className="text-content-subtle flex items-center gap-2 text-sm font-medium">
                 <Gift className="size-3.5" />
-                <span>{getBountyRewardDescription(bounty)}</span>
+                <span>{rewardDescription}</span>
               </div>
             )}

Also applies to: 8-8, 96-101

---

96-101: Consider a shared BountyRewardRow component to avoid repetition

The Gift + reward-description row is now effectively duplicated in:

• BountyCard (workspace)
• PartnerBountyCard (partner app)
• BountyInfo
• ClaimBountyModal

To keep iconography/typography from drifting over time, consider extracting a tiny shared component like:

// e.g. apps/web/ui/partners/bounties/bounty-reward-row.tsx
export function BountyRewardRow({
  description,
  className,
}: { description?: string; className?: string }) {
  if (!description) return null;
  return (
    <div
      className={cn(
        "text-content-subtle flex items-center gap-2 text-sm",
        className,
      )}
    >
      <Gift className="size-3.5" />
      <span>{description}</span>
    </div>
  );
}

Then each caller just passes in getBountyRewardDescription(bounty). Not urgent, but it would simplify future tweaks.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: devkiran
Repo: dubinc/dub PR: 2833
File: apps/web/lib/actions/partners/approve-bounty-submission.ts:53-61
Timestamp: 2025-09-12T17:31:10.548Z
Learning: In approve-bounty-submission.ts, the logic `bounty.rewardAmount ?? rewardAmount` is intentional. Bounties with preset reward amounts should use those fixed amounts, and the rewardAmount override parameter is only used when bounty.rewardAmount is null/undefined (for custom reward bounties). This follows the design pattern where bounties are either "flat rate" (fixed amount) or "custom" (variable amount set during approval).

Learnt from: devkiran
Repo: dubinc/dub PR: 2833
File: apps/web/lib/actions/partners/approve-bounty-submission.ts:53-61
Timestamp: 2025-09-12T17:31:10.548Z
Learning: In approve-bounty-submission.ts, the logic `bounty.rewardAmount ?? rewardAmount` is intentional. Bounties with preset reward amounts should use those fixed amounts, and the rewardAmount override parameter is only used when bounty.rewardAmount is null/undefined (for custom reward bounties). This follows the design pattern where bounties are either "flat rate" (fixed amount) or "custom" (variable amount set during approval).

Learnt from: TWilson023
Repo: dubinc/dub PR: 2736
File: apps/web/lib/actions/partners/create-bounty-submission.ts:105-112
Timestamp: 2025-08-26T14:32:33.851Z
Learning: Non-performance bounties are required to have submissionRequirements. In create-bounty-submission.ts, it's appropriate to let the parsing fail if submissionRequirements is null for non-performance bounties, as this indicates a data integrity issue that should be caught.

Learnt from: devkiran
Repo: dubinc/dub PR: 2736
File: apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/bounties/[bountyId]/bounty-info.tsx:45-56
Timestamp: 2025-08-25T17:39:38.965Z
Learning: In the bounty system, each partner can only submit to the same bounty once. This means totalSubmissions (pending + approved + rejected) equals the number of unique partners who have submitted, making UI text like "X of Y partners completed" accurate when using totalSubmissions.