From 6e83ef9da021ae3a21b76bf38058f034e8dc40d9 Mon Sep 17 00:00:00 2001 From: Siddharth Kothari Date: Thu, 16 Jul 2026 23:40:39 -0700 Subject: [PATCH] Remove internal review case log; use support address in contact fallbacks The false-positive case log documents real production designs and belongs in the private repo only. Contact-form fallback strings now point at the public support address. --- docs/review-false-positives.md | 168 ------------------ .../src/app/(marketing)/contact/actions.ts | 4 +- 2 files changed, 2 insertions(+), 170 deletions(-) delete mode 100644 docs/review-false-positives.md diff --git a/docs/review-false-positives.md b/docs/review-false-positives.md deleted file mode 100644 index 990ca80..0000000 --- a/docs/review-false-positives.md +++ /dev/null @@ -1,168 +0,0 @@ -# Review false positives — case log - -Real false positives caught in the wild, with the root cause and the -reviewer-prompt change (or open work) that addresses them. Use this as -the seed corpus when evaluating future prompt edits — a change is only -worth landing if it would have prevented or downgraded one of these -without regressing the true findings. - -## U1-002 — "5V DC on RF out via L5 damages internal DC block" - -**Project:** `434e247dfa98` (prod, 2026-05-26), version 2.3.1. -**IC:** U1, CMD263P3 (5–11 GHz LNA). -**Topology:** L5 (RF choke) connects `+5V` to U1 pin 11 (RF out). C6 -(broadband 0.1 µF) shunts the same node to GND. J2 (RF output coax) -sits on the same node. Pin 11 is documented as "DC blocked and 50 Ω -matched" internally. - -**What the reviewer flagged (ERROR):** "DC bias being applied to an -internally DC-blocked RF output … may damage it or degrade RF -performance." - -**Why it's wrong:** this is a textbook **bias-T**. The L+C network -exists to inject DC onto the coax to power a downstream active device -(active antenna / external LNA / mixer) through the same cable that -carries the RF signal back. The chip's *internal* DC block is exactly -the feature that makes bias-T safe: it isolates the LNA's RF stage -from the externally applied DC. The internal block cap is rated -against the chip's package abs-max (≥ Vdd abs max = 5 V here), so 5 V -across it is a non-event. - -**Root cause:** the reviewer correctly identified an unusual topology -(DC rail on an RF pin) and correctly read the datasheet ("DC blocked -internally"), but never connected the two. Two reasoning gaps: -1. **No harm-pathway numbers.** The `why` was pure speculation — - "*may* damage", "*may* degrade" — with no abs-max quoted, no - voltage stress computed. If the reviewer had been forced to write - the inequality (e.g. "internal DC-block cap rated for X V, sees Y V - → Y > X"), it would have either produced that proof or dropped the - claim. -2. **No "what is this part for" step.** The reviewer asked "what does - L5 do?" and answered "it puts 5 V on the RF pin" — true, but - incomplete. The next inference ("the DC doesn't reach the chip - because of the internal block, so it must be powering something - downstream of J2") never happened. - -**Prompt change landed:** new "ERROR requires a concrete harm pathway" -section in `backend/pinscopex/validate.py:SYSTEM_PROMPT`. Forces every -ERROR that alleges damage / abs-max violation / stress to name the -stressed component, the actual voltage/current on it, the datasheet -limit, and the inequality between the two. Hedged language without -numbers is no longer enough for ERROR — it must demote to WARNING. -Also adds an explicit note that *internal* components share the chip's -package abs-max, so external stress within the pin abs-max cannot -damage them by definition. - -**Expected effect on U1-002:** demotes to WARNING at worst (the -reviewer can no longer write "may damage" without quantifying the -stress on the internal cap), or drops entirely once the reviewer -recognizes the 5 V is below pin abs-max. - -## U1-001 — same bias-T, same IC, new project (landed: role-of-part step) - -**Project:** `13730c6991e3` (staging, 2026-05-26), version 2.3.1. -**IC/topology:** identical to U1-002 above — CMD263P3, L5 bias-T on -pin 11 (RF out), C6 shunt, J2 coax. Different project, same false -positive class. - -**Why harm-pathway alone wasn't enough:** the reviewer now cites -numbers (the gate's letter is satisfied), but the inequality is -bogus on two counts: -1. Wrong pin's abs-max — "places the RF output node at 5.0V — equal - to the absolute maximum **Vdd** rating (5.0V)" cites Vdd's limit - (pin 14) against pin 11 (RF out). -2. `=` is not `>` — abs-max is the don't-exceed line; *at* abs-max is - not damage. - -**Trace evidence:** the reviewer reached the right premise on its -own at turn 2 — *"L5 is an RF choke connecting RF_out to +5V. This -is a DC bias injection topology — but the datasheet says pin 11 is -'DC blocked and 50 ohm matched' internally"* — then dropped the -inference. The next step ("if the DC doesn't reach the chip, what -*is* it powering?") never happened. Both halves of the proof were -named in the same sentence; only the conclusion was missing. - -**Prompt changes landed:** -1. New "Identify the role of each external part before judging it" - section in `SYSTEM_PROMPT`, positioned before the "Net names" / - "Cross-IC interface" sections. Forces a four-step derivation - (pin behavior → part class → where the other end goes → role) - per external component, from first principles. Explicitly: when - a documented pin characteristic *prevents* the surface-reading - interaction (DC-blocked pin, AC-coupled pin, …), the part is - serving the rest of the circuit, not the chip. -2. New "Budget per concern: at most two follow-up tool calls" - section — caps deep-dive on one concern to two queries, demotes - to WARNING with `Unverified:` rather than burning turns. Stops - the death-spiral pattern where one suspect finding starves the - rest of the IC review. -3. Harm-pathway gate tightened: (a) abs-max number must come from - the *same pin's* abs-max row, not a different pin's; (b) strict - inequality (`>`, not `≥`) — equal-to-abs-max is at most WARNING. -4. `_MAX_REVIEW_TURNS` raised from 8 to 10 to absorb the role step - without truncating the rest of the review. - -**Expected effect on U1-001:** drops entirely once the reviewer -states "L5 + DC-blocked pin 11 + downstream J2 → bias-T powering a -downstream load". If the role step is skipped for any reason, the -tightened gate still demotes to WARNING (Vdd abs-max is no longer -valid as the limit for pin 11; `=` is no longer enough). - -**Open follow-ups:** -- Re-run this project (`/restart` admin path) to confirm U1-001 - drops or demotes. Add the resulting trace turn count as a sanity - check that 10 turns is enough. -- Watch the next 2–3 production runs for *regressions* — the role - step adds one reasoning pass per external part and could in - theory cause the reviewer to over-explain valid concerns as - WARNING. If any true ERROR demotes incorrectly, log it here. - -## Historical: "what is this part for?" reasoning step (now landed above) - -The harm-pathway requirement catches U1-002 by raising the bar on -ERROR. The deeper fix — and the one that catches the whole *family* of -unusual-but-correct RF topologies (bias-T, AC coupling, matching -networks, baluns, π/T attenuators) — is a forced reasoning step: -**for every external part on a chip pin, state what role it plays in -the design *before* judging whether it's correct.** - -The chain that kills U1-002 directly: - -> L5 connects +5 V to pin 11. Pin 11 is internally DC-blocked. -> Therefore the DC does not reach the chip. Therefore L5 must be -> powering something downstream of J2. → bias-T topology, expected. - -The chain that kills the U3-001/U1-001 contradiction (a separate but -related issue from the same project): - -> Net `$1N2250` is labeled 1.48 V but the ADJ divider math says 3.70 V. -> Which is the cause and which is the consequence? The divider is -> physical (resistor values), the label is an annotation. Trust the -> physics. → U1-001 ("Vdd below 2 V min") is the false consequence of -> trusting the label. - -**Status: landed** — see U1-001 case above. The role-of-part step -went in alongside the harm-pathway gate tightenings and a per-concern -turn budget, after the U1-001 run (same false-positive class, fresh -project) confirmed the harm-pathway change alone was not enough. - -**Original deferral rationale (retained for context):** the -harm-pathway fix was one prompt section and shipped first. The "what -is this part for" step is structurally larger — it changes the -reviewer's loop (one extra reasoning pass per external component) -and is more likely to regress true findings if done sloppily. Worth -doing after we've seen the harm-pathway change in production for a -few runs — which is exactly what U1-001 provided. - -**Pointer for whoever maintains this section:** -- The reasoning step lives *before* the existing "Net names are not - voltage labels" / "Cross-IC interface checks" sections in - `SYSTEM_PROMPT` — it's a precondition to those. -- Canonical RF patterns (bias-T, AC coupling, …) are deliberately - NOT listed by name. The win of agentic review over a pattern - library is that the reviewer figures out the role from first - principles. Don't add patterns to the prompt — add reasoning - scaffolds instead. -- Cross-check against this file: any prompt change that no longer - prevents U1-002 / U1-001 (and the future cases logged below them) - is a regression. diff --git a/frontend/src/app/(marketing)/contact/actions.ts b/frontend/src/app/(marketing)/contact/actions.ts index 9703382..ecbc27a 100644 --- a/frontend/src/app/(marketing)/contact/actions.ts +++ b/frontend/src/app/(marketing)/contact/actions.ts @@ -29,7 +29,7 @@ export async function submitContactForm(data: { } return { success: false, - message: result.message || "Something went wrong. Please try again or email us directly at sid@faradworks.com.", + message: result.message || "Something went wrong. Please try again or email us directly at dev@faradworks.com.", }; } @@ -37,7 +37,7 @@ export async function submitContactForm(data: { } catch { return { success: false, - message: "Could not reach the server. Please try again or email us directly at sid@faradworks.com.", + message: "Could not reach the server. Please try again or email us directly at dev@faradworks.com.", }; } }