The Problem

@media (prefers-color-scheme: dark) {
  body { background: #121212; color: #eaeaea; }
  .card { background: #1e1e1e; border-color: #333; }
}

@media (prefers-color-scheme: light) {
  body { background: #ffffff; color: #1a1a1a; }
  .card { background: #f5f5f5; border-color: #ddd; }
}

/* This correctly renders the light-mode rules when the OS reports
   a light preference - the media query itself is not wrong. A
   browser extension with forced dark mode enabled then rewrites
   the computed background and text colors AFTER layout, on top
   of the already-correct light styles, producing a page where a
   light-styled .card sits on a forced-dark body, with image and
   icon contrast tuned for one scheme sitting on a background from
   the other - a combination this stylesheet never had to account
   for, because it assumes only one system is deciding the colors. */

Fix: Don’t Assume Your Media Query Is the Only Thing Deciding Colors

• Reproduce the issue by actually enabling a forced-dark-mode browser extension during testing, rather than relying solely on the operating system’s own light/dark toggle, since that toggle alone never exercises the extension layer at all.
• Set an explicit color-scheme meta value or CSS property declaring which schemes the page actually supports, which gives some forced-dark extensions a stronger signal to respect the page’s own styling instead of overriding it uniformly.
• Avoid relying on an image, icon, or illustration whose contrast was tuned for only one color scheme, and prefer styling approaches – a background shorthand instead of separate layered properties, for instance – that degrade more predictably if something outside the page’s own stylesheet later adjusts individual color values.

Why This Is Easy to Miss

• The media query itself is implemented correctly and passes every test that checks the operating system’s own preference toggle, so there is nothing in the stylesheet’s logic to suggest the final rendered result depends on anything beyond that one setting.
• A forced-dark-mode extension is specific to whichever browser and configuration an individual visitor happens to be running, so the mismatched colors only appear for a subset of visitors and never show up in a design review done on a clean, extension-free browser.

The Problem

$ git log --oneline --graph --all
*   a1b2c3d (HEAD -> main) Merge branch 'rename-config'
|\
| * d4e5f6a (rename-config) Move legacy.config to config/app.config
* | 9f8e7d6 (remove-dead-code) Delete legacy.config (dead feature)
|/
* 1234567 Base commit with legacy.config present

$ git show a1b2c3d --stat
# No conflict was ever reported during this merge - 'legacy.config'
# simply disappears from the tree, because both branches agree it
# should no longer exist at that path. The rename-config branch's
# actual intent - that the FILE still exists, under config/app.config
# - is invisible to a merge algorithm that only ever compares paths,
# never file content moved to a new location.

$ git show a1b2c3d -- config/app.config
# fatal: path 'config/app.config' does not exist in 'a1b2c3d' either -
# the rename branch's new file was never actually merged in, because
# it lived on a commit this merge's history graph never touched.

Fix: Treat a Clean Merge as a Starting Point, Not Proof of Correctness

• Diff the merge commit against each of its two parents individually right after merging, specifically looking for any file that disappears relative to one parent, since a clean merge’s absence of conflict markers never checks for this kind of cross-branch rename.
• Use a rename-detection-aware diff, or review the actual commit history of a deleted file on each branch, before merging two long-lived branches that both touched the same area of the codebase, so an intentional rename on one side is caught before the merge silently erases it.
• Run the test suite, and specifically any test that loads configuration or data from a file path, immediately after a merge that touched shared infrastructure files, rather than trusting a conflict-free merge to mean every file ended up where it needed to be.

Why This Is Easy to Miss

• A merge with zero conflicts reads as the safe, boring outcome – the kind every developer wants to see – so there is no natural prompt to go back and double-check individual files once the merge command itself reports success with nothing to resolve.
• The missing file only causes a visible failure once something tries to load it at runtime, which can be long after the merge itself, especially if the file is only read in a code path or environment that isn’t exercised by routine local testing.

The Problem

<div class="tab-panel" id="specs" style="display: none;">
  <!-- Hidden by display:none until the user clicks the "Specs" tab -->
  <img src="diagram.png" loading="lazy" alt="Product diagram">
</div>

<script>
  tabButton.addEventListener('click', () => {
    specsPanel.style.display = 'block';
    // The image's loading="lazy" decision was already evaluated
    // while display:none meant it had no real position on the
    // page at all - some browsers simply never revisit that
    // decision once the element becomes visible later, leaving
    // the image unloaded even though it is now clearly on screen.
  });
</script>

Fix: Don’t Ask Lazy Loading to Judge an Element With No Position

• Switch the image’s loading attribute from lazy to eager for any image inside a tab, accordion, or other initially hidden container, since the performance benefit of lazy loading assumes a real scroll position to measure against in the first place.
• Trigger the browser to re-evaluate the image, such as by briefly toggling the src attribute or forcing a reflow, at the exact moment the containing tab or panel becomes visible, if keeping lazy loading on that image is still worth the extra handling.
• Use a visibility-based loading approach built specifically for this case – loading the image the moment its container’s hidden state changes – rather than relying on the browser’s own viewport-distance heuristic to somehow account for content it currently cannot see at all.

Why This Is Easy to Miss

• Lazy loading behaves exactly as expected for every image lower down a normal, fully visible page, so there is nothing to suggest it needs different treatment for an image that starts out hidden in a tab rather than merely off-screen below the fold.
• The blank space where the image should be often gets attributed to a slow network or a broken image path, since nothing in the browser’s behavior visibly announces that a loading decision was made and simply never revisited once the tab opened.

The Problem

You are tracing a null reference exception back to its actual
source, not just describing where it crashed. I'll paste the stack
trace and the relevant methods along the call chain it passed
through. Please:

1. Identify the exact variable or expression that was null at the
   crash site, from the stack trace and the crashing line.
2. Walk backward through the call chain I've provided: for each
   method in the trace, find where that same value was assigned,
   returned, or passed in, and determine whether IT could have
   been null at that point too.
3. Keep walking backward until you reach the first point in the
   provided code where the value was assigned from something that
   can plausibly return or produce null - a lookup that can miss, an
   external call, a optional field - rather than stopping at the
   first assignment you see.
4. State clearly which single line is the most likely original
   source of the null, and what specifically about that line can
   produce a null value.

Stack trace and relevant code:

[paste your stack trace and methods here]

Why This Prompt Works

• Explicitly separating the crash site from the source forces the walk backward through the call chain instead of stopping at the first and most visible line, which is usually just where the null finally got used, not where it was created.
• Asking the model to keep walking until it reaches a plausibly null-producing operation – a lookup, an external call, an optional value – gives it a concrete stopping condition, instead of guessing arbitrarily how far back in the chain to look.
• Requesting the single most likely source line, rather than a list of every place null theoretically could have come from, produces one specific, checkable hypothesis to go verify first instead of a broad list that still requires manual triage.

Why This Is Easy to Miss

• Paste every method the stack trace actually passes through, not just the one where the exception was thrown, since the backward walk this prompt performs can only go as far back as the code you actually provide.
• Treat the identified source line as the most likely explanation to verify with a debugger or a log statement next, not as a confirmed root cause – the model is reasoning from the code’s logic, not from an actual runtime trace of that specific failure.

The Problem

Here's a photo/scan of my gym membership contract. Please read
through it and pull out everything specifically related to
canceling the membership, organized as:

1. The exact notice period required before cancellation takes
   effect (for example, "30 days before your next billing date"),
   stated in plain terms with the specific number of days.
2. The required method of cancellation - in writing, in person,
   through a specific online form, certified mail, or anything
   else the contract specifies - and flag clearly if a method that
   seems reasonable (like a phone call or an email) is NOT actually
   accepted according to the contract's own wording.
3. Any fee that applies to cancellation, and under what specific
   condition it does or doesn't apply (an early-termination fee
   inside a minimum commitment period, for example, versus no fee
   once that period has passed).
4. Any auto-renewal clause, and the specific date or window before
   which I'd need to act to stop the next renewal from happening.

Summarize it as a short numbered checklist I could actually follow,
in the order I'd need to do things, with the specific dates or
deadlines spelled out rather than just described in relative terms.

Why This Prompt Works

• Asking specifically whether an easy, obvious-seeming cancellation method is actually NOT accepted catches the single most common and costly mistake – assuming a phone call or an email counts as proper cancellation when the contract requires something more formal.
• Requesting the notice period stated with a specific number of days, rather than left as the contract’s own relative phrasing, turns a clause that requires mental math against your own billing date into a deadline you can act on directly.
• Asking for the result as an ordered checklist, rather than a summary of what the contract says, turns legal text into something you can actually act on the day you decide to cancel, instead of information you would have to re-read and re-interpret again at that point.

Why This Is Easy to Miss

• Provide the complete contract, including any pages that look like they are just boilerplate or signatures, since a cancellation clause or fee schedule is sometimes placed in an appendix or a separate addendum rather than the main body of the agreement.
• Treat the extracted checklist as a strong starting point to act on, not a substitute for confirming with the gym directly if anything in the contract’s wording feels ambiguous – some contracts leave real room for interpretation that only the business itself can resolve.

The Problem

Setup: a photo edited and color-graded on a wide-gamut monitor,
saved with the document's working space set to a wide-gamut profile
because that's what the camera's raw file was imported with and
nothing was deliberately changed afterward.

1. On-screen, deep saturated reds and greens in the photo look
   accurate and vivid - the monitor can actually display most of
   that wide-gamut range.
2. File sent directly to a commercial print service with no
   soft-proofing step and no explicit profile conversion performed
   first - "it looks right here, so it should print right."
3. Printed copy comes back with the same reds and greens rendered
   as flat, muddy, and noticeably different from what was visible
   on screen throughout editing.

What's actually happening: the printer's actual color profile
covers a narrower range of reproducible colors than the wide-gamut
working space the document was edited in. Every color outside the
printer's range gets silently converted to the nearest reproducible
color during the print pipeline's own conversion step - a step that
happened with no preview, no warning, and no choice offered over
exactly how that out-of-range color should be handled.

Fix: Soft-Proof and Convert Deliberately Before You Ever Print

• Use Soft Proof with the printer’s or print service’s actual ICC profile loaded before sending any file for printing, specifically to see on screen, in advance, exactly which colors the print process will have to compress or shift during its own conversion.
• Convert the document to the target printer profile explicitly, choosing the rendering intent deliberately, rather than leaving the working space as wide-gamut and letting whatever conversion the print service’s own pipeline performs make that decision for you with no visibility into the result.
• Ask any commercial print service directly which ICC profile they actually use and whether they expect a file already converted to it, or a file left in its original working space for them to convert – the two workflows produce different results, and assuming the wrong one is a common, avoidable mismatch.

Why This Is Easy to Miss

• A wide-gamut monitor makes an image genuinely look accurate and well-saturated throughout the entire editing process, with nothing in that on-screen experience hinting that a meaningful share of those colors sit outside what a standard printer can ever physically reproduce.
• The conversion from the document’s working space to the printer’s profile happens automatically, as an invisible step inside the print pipeline, with no dialog or preview offered unless soft-proofing is deliberately turned on beforehand – by default, there is simply no warning at all.

The Problem

Symptom:
1. Theme switched from "BuilderTheme Pro" to a new theme six months
   ago; the BuilderTheme Pro companion plugin was deactivated and
   deleted at the same time.
2. Site search for "pricing" returns a result titled "Pricing -
   Builder Layout" dated from over a year ago.
3. Clicking the result loads a mostly blank page with a few raw
   shortcode tags visible as plain text instead of rendered content.
4. The actual current pricing page, built in the new theme, also
   appears in the results, further down the list.

What's actually happening:
- BuilderTheme Pro's companion plugin registered its own custom
  post type (e.g. `builder_layout`) to store saved page layouts.
- WordPress's default search query includes any public post type by
  default unless a theme or plugin explicitly excludes it - so old
  `builder_layout` entries remain fully searchable even after the
  plugin that created and could render them is gone.
- The raw shortcode text renders as plain text because the
  shortcode was registered by the now-deleted plugin; WordPress
  has no other plugin left that knows what to do with it.

Fix: Clean Up or Explicitly Exclude the Orphaned Post Type

• Check the Custom Post Type UI or a direct database query for any post type registered by a previous theme or plugin before deleting that plugin, and either export the content somewhere usable or delete the now-orphaned entries outright if they serve no purpose anymore.
• Exclude a specific legacy post type from search results directly, using the pre_get_posts action to filter it out of the main query, as an immediate fix that doesn’t require touching the old data itself if you’re not ready to delete it yet.
• Audit the site for any other custom post type left behind by a previous theme or plugin switch, since a search result pointing at dead content is usually just the most visible symptom of leftover data that can also affect sitemaps, RSS feeds, and internal link structures.

Why This Is Easy to Miss

• A theme switch is correctly understood as a purely visual and template-level change, so there’s no obvious reason to suspect it could leave searchable database content behind – the mental model of “themes don’t touch content” is accurate for everything except a plugin’s own custom post type.
• The broken result only surfaces when a visitor’s search term happens to match the old entry’s title or content specifically, so a site can run for months with the leftover data quietly sitting in the database before anyone’s search query actually surfaces it.

The Problem

1. Test project builds successfully - Build Succeeded, zero errors,
   zero warnings related to the test framework itself.
2. Test Explorer shows the test project listed, but with zero
   individual tests underneath it - no error icon, no red text,
   just an empty node where dozens of tests used to appear.
3. Recent action: ran a NuGet restore after pulling teammates'
   changes, which updated the test SDK package
   (Microsoft.NET.Test.Sdk) to a newer version, while the test
   adapter package (e.g. xunit.runner.visualstudio) stayed pinned
   at its previous version in this project's own file.
4. Output window, Tests category, shows a quiet warning about an
   adapter failing to load or a version mismatch - easy to miss
   entirely unless that specific output category is selected.

The build succeeds because the test SDK/adapter mismatch doesn't
actually break compilation - it only affects whether Test Explorer's
discovery process can successfully load and talk to the adapter at
runtime, which is a completely separate step from compiling the
project's code.

Fix: Keep the Test SDK and Adapter Versions Moving Together

• Check the Output window’s Tests category specifically after any restore that touches a test project, since the actual warning about a failed or mismatched adapter load is usually sitting there in plain text, just in a pane most people never select unless they already suspect test discovery is broken.
• Update the test framework’s adapter package to a version compatible with the test SDK version the restore just pulled in, rather than leaving one pinned while the other moves – the two are meant to be upgraded together, not independently.
• Add a central package version management file, or explicitly pin both the test SDK and the adapter package together in the same place, so a future restore can’t silently update one without the other drifting out of a compatible version range.

Why This Is Easy to Miss

• A successful build gives every visual signal that the project is in a healthy state, so there’s no natural reason to suspect the restore that just ran is actually the cause of a completely separate-seeming problem in Test Explorer a few minutes later.
• Test Explorer showing an empty, test-free project looks identical whether the cause is an adapter version mismatch, a build configuration issue, or genuinely zero tests existing in that project – there’s no prominent error state to distinguish “broken discovery” from “nothing to discover.”

The Problem

// A generous size limit and request timeout both suggest this
// upload should be allowed to take its time:
builder.Services.Configure<FormOptions>(options =>
{
    options.MultipartBodyLengthLimit = 500_000_000;
});
builder.Services.Configure<KestrelServerOptions>(options =>
{
    options.Limits.MaxRequestBodySize = 500_000_000;
});

// But Kestrel's default minimum data rate still applies underneath
// both of those settings - a client sustaining less than roughly
// 240 bytes/second for more than a short grace period gets its
// connection aborted mid-upload, regardless of the body size limit
// or how generous any other timeout was configured to be:
//   MinRequestBodyDataRate: 240 bytes/sec, 5 second grace period
// (the actual Kestrel default, unless explicitly overridden)

Fix: Set the Minimum Data Rate to Match What Slow Uploads Actually Need

• Override MinRequestBodyDataRate explicitly for the specific upload endpoint, lowering the bytes-per-second floor or disabling the check entirely for that route rather than for the whole application, once you know real clients upload from genuinely slow connections.
• Reproduce the failure by actually throttling a test upload’s bandwidth to a realistic worst case, instead of relying on a fast local network connection where the minimum data rate floor is never remotely close to being tripped.
• Log the specific exception Kestrel raises when it aborts a connection for falling below the minimum rate, since it is distinct from a generic timeout and immediately points at the correct setting instead of leaving the cause to be guessed at from a plain connection reset.

Why This Is Easy to Miss

• Every other timeout and size limit involved in the upload path can be configured generously and still not matter, because the minimum data rate check operates independently of all of them and enforces its own floor regardless of what the rest of the configuration allows.
• The failure only reproduces on a connection slow enough to fall under the floor for long enough to trigger it, so testing on a typical office or home connection almost never reveals the problem – it surfaces only once real users on weak mobile or rural connections try the same upload.

The Problem

function getUserPrefs(userId) {
    // theme comes back as null specifically when the user has no
    // saved preference row at all - not undefined, null:
    const row = lookupPrefsRow(userId);
    return [row ? row.theme : null, row ? row.fontSize : null];
}

const [theme = 'light', fontSize = 14] = getUserPrefs(42);

// Expected: theme === 'light', fontSize === 14, when there's no
// saved row. What actually happens: theme === null, fontSize ===
// null - the default values never apply, because null is not
// undefined, and a destructuring default only triggers for
// undefined specifically.

applyTheme(theme);      // called with null, not 'light'
setFontSize(fontSize);  // called with null, not 14

Fix: Normalize to Undefined Before the Default Ever Has to Apply

• Convert a deliberate null into undefined at the source – right where the lookup can return null – before the value ever reaches a destructuring pattern, so the default value mechanism sees exactly the signal it actually checks for.
• Use the nullish coalescing operator explicitly on each value instead of relying on a destructuring default when a value can be either null or undefined, since nullish coalescing treats both the same way and a destructuring default does not.
• Add a direct equality check for null immediately after any API, parser, or database call known to return it for a missing value, and decide there – deliberately – whether the rest of the code should treat that null the same as undefined or differently.

Why This Is Easy to Miss

• A destructuring default reads as a general catch-all for any kind of missing value, so it is a reasonable, common assumption that it covers null as well as undefined – the actual rule is narrower than the syntax visually suggests.
• A quick manual test calling the function with a completely missing argument, rather than one that explicitly returns null, exercises the undefined case and shows the default working correctly, hiding the gap until a real null value happens to flow through.