Ship software you understand and trust

rubberduck explores your problem with you, decision by decision, and only writes code once you’ve made the calls.

Sessions / Billing alerts for usage spikes

You Aug 26,
4:02 PM

Customers keep missing usage spikes until the invoice lands. Add billing alerts to the dashboard.

Thought for 2.4s

Alerts could hang off the notification service or the billing worker — and the worker already owns the usage_rollups table.

Explore Investigate billing rollups

Read billing/services.py …

Grep "rollup" → 14 hits, 3 files …

Let’s start with alerts in the billing worker. Three directions you could take it:

Fixed thresholds — a dollar cap per org. Simplest; ships this week.
Forecast alerts — project month-end spend, warn when the trajectory crosses the plan.
Weekly digest — no triggers, just a Monday summary. Least noisy, least protective.

Which fits how your customers think about spend?

You now

Forecasts. Caps punish bursty-but-fine usage.

Agreed — recorded. Drafting the design doc: forecast over a 7-day window…

1 tool call 2.8s

Write design.md §2 — Forecast model …

Agent is processing…

Why rubberduck?

The problem

Coding agents make design decisions implicitly, and the reasoning is lost when the session ends.

Our belief

The engineer shipping the code should make those calls: a decision you made is one you can defend, debug, and explain. It also gets the benefit of your experience and your understanding of the team, infrastructure and domain.

Our answer

rubberduck explores the design with you, bringing you each decision with its tradeoffs. It writes down what you decided and why, and only then does it autonomously build.

How it works

A session runs in three phases: design, plan, execution. Each phase ends with something you review before the next begins — the design doc, the implementation plan, the PR.

Design

rubberduck explores the problem and solution space with you, bringing you each design decision with its tradeoffs.

It reads your codebase, advises, and answers your questions — but you make each call.

Every decision, every rejected alternative, and the reasoning behind both go into a design doc that stays after the feature ships.

SESSIONS / Frontend state architecture redesign DESIGN PLAN

CONVERSATION

Problem & Context

The frontend has become difficult to reason about. State is distributed across module singletons and the DOM itself — there is no state model between incoming WebSocket events and rendering. Each event is treated as an imperative command (“append this block”, “flip this flag”) rather than a fact that updates a model the UI renders from.

The goal is not to fix these bugs individually but to redesign the frontend architecture and the backend↔frontend event contract so this class of bug is structurally hard to write.

Requirements

Functional Requirements

Primary

A single, explicit client-side state model: events update state; rendering is a function of state.

Missed or reordered events must self-heal rather than permanently diverging the UI.

Connection lifecycle must be an explicit, derivable decision — never inferred from an unrelated flag.

Derived/time-based values (relative timestamps, durations) must stay current.

Secondary

PR status and env-status freshness without an open connection: state changes originating outside agent activity must reach an open tab within a bounded window.

You 9:58 AM

Why decide when to close the socket at all? Keep it open — it’s simpler than a lifecycle.

Thought for 46s

3 tool calls

Read deploy/terraform/main.tf 180ms

Grep "cpu_idle" → request-based billing, min = 0 240ms

Read designer/websocket_codes.py 96ms

Checked — it’s not simpler, it’s a bill. The web tier is request-billed with min instances = 0: one parked tab holds a billable instance around the clock. And the service sets no request timeout, so infra already severs every socket at 300s — reconnect is the steady state whatever we choose. So the real question isn’t “when do we close” but “who decides done.” If the client infers it from isProcessing, that’s the original bug again. I’d make quiescence a server-side predicate over DB state. One wrinkle: artifact sync lands ~30s after a turn ends, and the server can’t see it pending.

You now

Then defer the evaluation 30s — non-durable timer; a reconnect converges to the same state anyway.

Agreed — that keeps the predicate pure and makes the timer safe to lose. Recording both, with keep-alive as the rejected alternative and the billing math as why.

1 tool call

Write /workspace/artifacts/design_document/document.md

Type a message…

Plan

rubberduck compiles the approved design into an implementation plan.

It follows the data flows in your codebase to map dependencies and edge cases, and breaks the work into a stack of small tasks.

You review the plan and approve it before execution starts.

SESSIONS / Frontend state architecture redesign DESIGN PLAN

CONVERSATION

WorkflowStep.turn_state

Snapshot broadcast choke point

Quiescence predicate + 4420

HTTP endpoint + ETag polling

Zustand store + typed contract

React per-block message list

Vite build + legacy cleanup

+ RESET −

Add WorkflowStep.turn_state; delete is_agent_processing

build_session_snapshot() + broadcast choke point

Quiescence predicate + close code 4420

HTTP snapshot endpoint + ETag quiescent polling

Zustand store + typed event contract

React message list — per-block subscriptions

Vite build stage; delete legacy events

That closes the last open decision — the doc now records the contract, the lifecycle, and both rejected alternatives. Ready to compile the plan whenever you are.

You 10:31 AM

Design’s settled. Compile the plan.

Thought for 8.3s

Tracing the data flows the design touches so the tasks map real dependencies — dispatch paths, the broadcast sites being replaced, and the frontend build.

6 tool calls

Thought for 12s

The approved design compiles into 7 tasks. I followed the dispatch paths in executioner/services/ — turn delivery and the delivered stamp land in the same transaction, so turn_state alone gates input. Task 3 evaluates quiescence at task 2’s choke point, so they land together.

You now

Approved. Keep the dual-emit until the template swap, then delete the legacy events in the cleanup commit.

Sequenced — every commit keeps tests green; the cleanup commit enables quiescent-close last. Starting execution when you are.

Type a message…

Execution

rubberduck implements your change task by task in an isolated environment — built from an image you provide, with your dev dependencies like databases and test infrastructure.

Each completed task gets a detailed code review, and all your quality gates pass before it opens a PR for you to review.

SESSIONS / Frontend state architecture redesign DESIGN PLAN

CONVERSATION

WorkflowStep.turn_state

Snapshot broadcast choke point

Quiescence predicate + 4420

HTTP endpoint + ETag polling

Zustand store + typed contract

React per-block message list

Vite build + legacy cleanup

+ RESET −

Add WorkflowStep.turn_state; delete is_agent_processing COMPLETED

build_session_snapshot() + broadcast choke point COMPLETED

Quiescence predicate + close code 4420 COMPLETED

HTTP snapshot endpoint + ETag quiescent polling RUNNING

Zustand store + typed event contract

React message list — per-block subscriptions

Vite build stage; delete legacy events

EXECUTING

Thought for 3.5s

This is a focused Django change — a JSON view plus ETag handling in one file. Let me examine the current routes before delegating.

2 tool calls

Thought for 4.4s

Branch created. Now I’ll delegate the implementation to the implementer tool.

IMPLEMENTER Please implement the task described in this tas… COMPLETED

Thought for 2.5s

The implementer reports the changes are done but claims completion_criteria.sh is failing due to environment issues. Per my responsibilities, I must not blow past a failing completion script — let me first review the diff, then investigate the claimed environment issues myself.

1 tool call

The diff is exactly correct — the view, the ETag header, and the 304 path, nothing extraneous. Verifying the claimed environment failures myself rather than trusting the report.

Type a message…