descriptionAppend returns success right up to the 50000-byte cap, then fails atomically — no result signals the size beforehand.

Impact: on a long team pipeline every node appends to one ticket's description. The 50000-byte cap is enforced silently: descriptionAppend keeps returning success with no size in the result, so nothing hints the wall is near, then the append that crosses 50000 bytes is refused atomically and its content is lost. A warning band would turn an invisible wall into a visible one, and it is independent of any larger fix.

Full report: https://claude.ai/code/artifact/6fff17ef-e68a-4684-aef9-6776e424de39

How I investigated: read the tool docs and re-read the affected tickets read-only; sizes measured with wc -c on the returned description. Same two incidents as the companion request (2026-09-06, 2026-09-08).

This is an enhancement, not a bug: the cap itself is reasonable; the missing thing is any runway before it.

PROVEN: the cap is exactly 50000 bytes UTF-8 (the failure says "max 50000"); the refusal is atomic (nothing written); character count underestimates usage (PT-BR dashes, curly quotes and accents cost 2-3 bytes each), so a client counting characters cannot predict the wall.

INFERRED (why it is cheap): the server already computes the resulting byte size to enforce the cap, so returning that number, or the remaining headroom, adds no new computation.

Filed apart from the off-cap comment request because it is smaller and independent: even if that comment surface takes time, the warning alone removes the surprise and is useful on its own.

Suggested implementations, by return:

1. Return the current description byte size and remaining headroom in every descriptionAppend result.
2. Emit a soft warning in the result once the size passes ~45000 B, while the append still succeeds.

Problem to solve

Today backlog_update({descriptionAppend}) gives no size feedback. Every append returns plain success with no byte size and no remaining headroom, so a long team pipeline appending to one ticket cannot tell it is nearing the 50000-byte cap. The first and only signal is the failure itself, and by then the append that crossed the line is already refused atomically and its content lost. Character counting cannot substitute: PT-BR dashes, curly quotes and accents cost 2-3 bytes each, so the client cannot compute the true byte size cheaply.

Proposed behavior

Two possible returns, either is enough. (1) Every descriptionAppend result includes the current description byte size and the remaining headroom, on success as well as on failure. (2) Once the size passes a threshold (~45000 B), the result carries a soft warning while the append still succeeds, giving the caller runway to redirect its output before the hard cap. It is cheap to add: the server already computes the resulting byte size to enforce the cap, so surfacing that number adds no new computation.

Who benefits

Anyone driving backlog_update programmatically, above all multi-agent team pipelines where several nodes append to one ticket across review cycles. It also helps any client whose content is not plain ASCII (accented languages), where character count diverges most from byte count, so today they have the least ability to predict the wall. And it helps the human reader of the ticket, because the append most likely to be lost is the newest one - typically the final PR link and commit SHA.

Acceptance criteria

A descriptionAppend near the cap returns a size or remaining-headroom value (and/or a warning) before any append fails, and a caller can read that number to decide where to write next. Concretely: append until the description is around 46000 bytes and the result now reports the size or a warning instead of a bare success; the first evidence of the cap no longer coincides with the first failed append. No behaviour change is required below the threshold, so nothing regresses for small tickets.