JAY TANK

Agreed, and that's a real gap in what a source scanner can see. BrowserKey reads the repo, so a NEXT_PUBLIC_OPENAI_API_KEY set only in the Vercel or Netlify dashboard is invisible to it. The built bundle is the one place that tells you the truth. If the key is in there, it's public, whatever the source looks like. A few things that make the CI check more reliable: Scan only the client output. For Next.js that's .next/static, not .next/server, which would give false alarms. For Vite and CRA it's dist/ or build/. Include source maps. .map files often hold the original source with the inlined value. Match the prefixes, not just sk-: sk-proj-, sk-ant-, AIza, gsk_. Print file names only (grep -l), so the check itself doesn't leak the key into your CI logs. npm run build if grep -rlE 'sk-(proj|ant)-[A-Za-z0-9_-]{20,}|gsk_[A-Za-z0-9]{20,}' .next/static dist build 2>/dev/null; then echo "AI provider key found in the client bundle (files listed above)"; exit 1 fi Doing both makes sense. BrowserKey catches it while you're writing the code, and the build check catches whatever was configured outside the repo.

Thanks, you've put your finger on exactly the failure that hurts most. The 5174 fallback is the worst kind of bug, because the error you see (an OAuth redirect mismatch or a CORS block) points somewhere completely different from the real cause. PortClash already covers both points: Vite: when a Vite dev server's port clashes with something else, the finding says Vite will silently move to the next free port unless server.strictPort is true. It also checks whether strictPort is already set in vite.config or passed as --strictPort, so you know which behaviour you'll get. Databases: if a compose service publishes a database port on all interfaces ("5432:5432" with no host IP, which means 0.0.0.0), it gets flagged even when nothing else is using that port. It's reachable from your network, and Docker's published ports can bypass host firewall rules like ufw. The fix is to bind it to 127.0.0.1:5432:5432. I agree on strictPort: true as a default for shared repos. A loud "port already in use" takes ten seconds to fix. A quiet move to 5174 can cost an afternoon.

That's the exact framing behind hintgap - the annotation is the permission model, not documentation. If destructiveHint/readOnlyHint is missing, the agent reasons about blast radius from the name and description alone, and a vague description invites precisely the "guess the argument shape, server accepts a wider call" failure you describe. On your two questions: Sensitive or public schema? It's public schema - the description/annotation ships to any client that lists your tools, so it must never carry secrets, internal hostnames, or auth hints. But it's security-relevant public schema: it defines what the agent believes it's allowed to do, so it deserves review like an authz policy, not a changelog. What to log when the agent picks the wrong tool? The decision context, not the payload: the tool name chosen, which annotations were present/absent at call time, and the shape of the arguments (keys/types, not values). That tells you whether the miss was a missing hint, an ambiguous description, or a genuine model error - which is exactly the signal you feed back into tightening the schema.

Exactly - retrieval without a refusal is the quiet failure mode: the model treats the top hit as an answer no matter how weak the match is. My rule of thumb is two gates, not one: a minimum similarity score below which nothing is eligible, and a margin check (the top hit must beat the runner-up by a set gap, so "lots of mediocre matches" doesn't sneak through). A concrete starting point for cosine on normalized embeddings: require ~0.75+ to answer, treat 0.6–0.75 as "retrieve but hedge," and refuse below that - then tune on your own eval set, because the right threshold is corpus-specific. When nothing clears the bar, the honest move is a refusal with a next step, not a guess: "I don't have a confident source for that," plus what I do have (closest topics) or a handoff. A visible "no answer" is a feature —-it's the line between a bot that's confidently wrong and one people actually trust.

Thanks for following up - same fair point, this time framed around outage disputes rather than billing. To keep scope clear: this article is about Kubernetes' own pod-termination mechanics (SIGTERM, the grace period, preStop hooks, and getting readiness to flip before the signal lands), not about producing evidence for a dispute between a buyer and an operator. For what it does cover, nothing is gated behind a "vendor badge" - kubectl describe pod, kubelet logs, and the pod's own terminationGracePeriodSeconds are the actual source of truth, and any operator can pull them directly rather than taking anyone's word for it. The scenario you're describing - a buyer who doesn't control the cluster needing independently verifiable, signed proof of runtime behavior after an outage - is a real problem, but it's an attestation/provenance question, not a shutdown-mechanics one. It's outside what this post is trying to do. If that gap is what you're getting at, I'd be glad to dig into it as its own topic.

Thanks for the comment - that's a fair distinction between observability and verifiable proof. To clarify scope: this article is about the mechanics of pod termination itself (SIGTERM, the grace period, preStop hooks, and the readiness/signal ordering), not about settling a billing dispute between two parties. For what it does cover, the "proof" isn't a dashboard or a vendor badge - it's the cluster's own record: kubectl describe pod for the termination reason and exit code, kubelet logs for signal timing, and terminationGracePeriodSeconds in the pod spec, all of which any operator can query directly. What you're describing - a signed, tamper-evident record of "what ran" that a buyer can independently verify in an invoice dispute - is a genuinely different and valid problem, closer to metering/attestation than to shutdown mechanics. It's just outside what this piece set out to do. Happy to discuss that separately if you'd like to go deeper on it.

Really appreciate this - and you've named the exact case that matters most: the query living in get_by_id() in the data layer, one or two hops from the handler, is precisely where intraprocedural taint goes quiet. You're right that a clean run shouldn't be read as full coverage there. Two things I'm taking from this: I'll document the wrapped-call / cross-function boundary as an explicit known gap in the README, so a green result never over-promises. I like your "can't tell, wrapped call" idea a lot - surfacing a low-confidence "tainted value crosses a function boundary here" note is far more honest than silence. Tracking it as a planned signal (likely opt-in so it stays low-noise). Thanks for pushing on the honesty of the output - that's the part I most want to get right.

That's the sharpest part of the whole thread - thank you. You're right: the requested model is an intention, the response's model id is the fact, and after a router fallback they diverge exactly when you most need the truth. I'll add it to the README's provenance note as the explicit guidance: log the resolved model from the response payload (and the endpoint/gateway that served it), not the argument you passed in. Appreciate you closing that loop.

Well put - approval gates answer "should this run?", provenance answers "who decided it?", and an incident needs both. The key word is resolved: teams log model="gpt-4o" but not the dated snapshot, endpoint, or params, so the one call that misbehaved can't be reproduced. handbrake stays static on purpose - it gates the missing approval at the PR, before anything runs - so per-call provenance is the complementary runtime half of the same story. Might add "log the resolved model + endpoint alongside destructive tool calls" to the README as a companion practice. Appreciate the thoughtful note.

Thanks - that mirrors exactly why I built it: by the time recall looks bad, the chunk that caused it is buried three steps back. And agreed, mid-sentence splits are the quiet killer. Deterministic is a deliberate choice for the core: it stays offline, free, and CI-gateable, so the structural checks run on every ingestion with zero cost or flakiness. I do want a semantic layer, but as an opt-in on top - a BYO-key flag for things like chunk-topic coherence or "does this chunk answer anything retrievable" - never in the default path. The structural gate should always work with no network or spend; semantics would be the extra pass you turn on when you want it.