AI 智能體把除錯輸出留在已合併的請求處理程序中，測試未能發現

The agent traced an auth mismatch by dropping a console.log("token=", token) into the request handler. It found the real cause — the interceptor attached a stale credential after refresh — patched it, ran the suite, reported green, and we merged. The debug print stayed behind.

Nobody flagged it because the tests had nothing to check. A logging call changes no return value, throws nothing, and asserts against nothing, so a green suite proves the control path ran; it says nothing about whether scratch diagnostics were removed along the way.

A print has no assertion target

Most unit tests pin behavior: the function returns X, the queue receives Y, the error path throws Z. A diagnostic line sits outside all of those. It does not break the return shape, it does not violate a contract, and the test runner never looks at stdout by default. The agent closes its task when the failing test goes green; cleanup of its own tracing is not part of that acceptance condition, so it rarely happens.

The same gap hides every kind of residue: a temporary hardcoded value used to force a branch, a commented-out block from an abandoned approach, a debugger statement left on a hot path. Tests go green for the fix; the scratch layer rides along to production.

Two tiers of leftover diagnostics

The benign tier is pure noise. A console.log that fires on every authenticated request lands in the aggregator beside real errors, buries signal, and slows the request by serializing an object nobody reads. Annoying, but recoverable.

The dangerous tier prints the request value itself: the bearer token, a user's email and address, the raw payment payload, a session cookie. These flow into centralized log retention, where they outlive the request by weeks or months. A secret that appears in a log line is no longer protected by the transport layer; it sits in plaintext on a machine someone else queries, under a retention policy that predates the leak. The token trace that solved the bug becomes the incident after merge.

What to put in front of merge

Three cheap habits catch this class without slowing review:

• Grep for the exact debug phrase after the fix. The agent invented a distinctive trace string; search for that, not for the generic word "log."
• Route runtime output through a leveled logger so scratch calls sit at debug and are stripped or suppressed in production builds, rather than as bare prints that compile into the shipped bundle.
• In review, question any print that names a request value. Noise can wait; a print referencing a token, PII, or payload should be removed or scrubbed before merge, not scheduled for later.

Read the diff for residue instead of trusting green. The suite was never going to tell you the print was there.

A green result is not a clean workspace

A green suite answers whether the fix works. It does not answer whether the workspace was cleaned. Treat scratch diagnostics as part of the change, and make their removal a checkpoint on the path to merge.