fix(channel): make the instructions fit, and assert that they do #138

Merged

jlxq0 merged 1 commit from instructions-fit into main

2026-08-27 16:01:53 +00:00

jlxq0 commented

2026-08-27 16:00:10 +00:00

Owner

A live session against the deployed v0.10.8 pod reported its instructions cut off mid-sentence with a [truncated] marker.

constant at v0.10.8   2047
served with prefix    2082
lost                  34    `acting on anything time-sensitive.`

My number for that release was wrong, and how it went wrong is the lesson. I measured 1964 bytes, then added a sentence to restore in_reply_to_suspicious= after the drift test caught me dropping it, and reported the pre-edit measurement as the shipped one. A measurement is about the bytes that exist when it runs.

The string is trimmed to 1963, served 1998, with fifty bytes of headroom for a server name longer than kampong.social. No attribute is dropped; the wording is tightened rather than the catalogue shortened.

The length assertion is wanted after all

Both existing tests check that something is inside the first 2048 bytes, and both stay green however long the string grows, because the contract sits at the front. Neither can see a tail falling off the end, which is exactly what shipped. Ordering decides what survives a cut; the length decides whether there is a cut at all.

It was argued out of the design for a reason that was right about the contract and wrong about the tail. The bound is stated against a 64-byte server name rather than the current one, since the prefix eats the same budget.

Verified by reproducing the shipped defect

Padding the tail so it overruns by 86 bytes:

nothing_is_silently_dropped_from_the_instructions   FAILED
the_security_contract_is_inside_what_a_session_receives    passed
the_operational_contract_is_inside_what_a_session_receives passed

2134 bytes served against a 2048-byte limit: 86 would be cut, starting at " xxx…"

That is the demonstration that the two answer different questions, rather than an argument that they do.

Not tagged

The bytes lost today are the tail of an operational caveat, and a rollout costs every director their push stream. This rides with the next release rather than causing one.

Gates: fmt, clippy -D warnings, 298 passed; 0 failed, audit clean, deny ok.

A live session against the deployed `v0.10.8` pod reported its instructions cut off mid-sentence with a `[truncated]` marker. constant at v0.10.8 2047 served with prefix 2082 lost 34 `acting on anything time-sensitive.` **My number for that release was wrong, and how it went wrong is the lesson.** I measured 1964 bytes, then added a sentence to restore `in_reply_to_suspicious=` after the drift test caught me dropping it, and reported the pre-edit measurement as the shipped one. A measurement is about the bytes that exist when it runs. The string is trimmed to **1963, served 1998**, with fifty bytes of headroom for a server name longer than `kampong.social`. No attribute is dropped; the wording is tightened rather than the catalogue shortened. ## The length assertion is wanted after all Both existing tests check that something is inside the first 2048 bytes, and **both stay green however long the string grows**, because the contract sits at the front. Neither can see a tail falling off the end, which is exactly what shipped. **Ordering decides what survives a cut; the length decides whether there is a cut at all.** It was argued out of the design for a reason that was right about the contract and wrong about the tail. The bound is stated against a 64-byte server name rather than the current one, since the prefix eats the same budget. ## Verified by reproducing the shipped defect Padding the tail so it overruns by 86 bytes: nothing_is_silently_dropped_from_the_instructions FAILED the_security_contract_is_inside_what_a_session_receives passed the_operational_contract_is_inside_what_a_session_receives passed 2134 bytes served against a 2048-byte limit: 86 would be cut, starting at " xxx…" That is the demonstration that the two answer different questions, rather than an argument that they do. ## Not tagged The bytes lost today are the tail of an operational caveat, and a rollout costs every director their push stream. This rides with the next release rather than causing one. Gates: fmt, clippy `-D warnings`, `298 passed; 0 failed`, audit clean, deny ok.

jlxq0 added 1 commit

2026-08-27 16:00:10 +00:00

fix(channel): make the instructions fit, and assert that they do

CI / cargo (pull_request) Successful in 1m29s

Details

CI / docker (pull_request) Has been skipped

Details

34c9494052

A live session against the deployed v0.10.8 pod reported its channel
instructions cut off mid-sentence with a truncated marker. The constant is 2047
bytes there, 2082 served with the prefix, and the last 34 are lost: "acting on
anything time-sensitive."

My own number for that release was wrong and the way it went wrong is the
lesson. I measured 1964 bytes, then added a sentence to restore
in_reply_to_suspicious= after the drift test caught me dropping it, and
reported the pre-edit measurement as the shipped one. A measurement is about
the bytes that exist when it runs.

The string is trimmed to 1963, served 1998, with fifty bytes of headroom for a
server name longer than kampong.social. No attribute is dropped, which the
drift tests would have caught again, and the wording is tightened rather than
the catalogue shortened.

The second test is the one Alan and I talked out of the design, and it is
wanted after all. Both existing assertions check that something is inside the
first 2048 bytes, and both stay green however long the string grows, because
the contract sits at the front. Neither can see a tail falling off the end,
which is exactly what shipped. Ordering decides what survives a cut; the length
decides whether there is a cut at all. The bound is stated against a
sixty-four-byte server name rather than the current one, since the prefix eats
the same budget.

Verified by reproducing the shipped defect: padding the tail so it overruns by
86 bytes reddens the new test alone, with both contract assertions still
passing. That is the demonstration that they answer different questions rather
than an argument that they do.

Not tagged. The bytes lost today are the tail of an operational caveat, and a
rollout costs every director their push stream, so this rides with the next
release rather than causing one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FEgtox6vnEkYPv9PrCCoYG

jlxq0 merged commit b1598bb34a into main

2026-08-27 16:01:53 +00:00

jlxq0 deleted branch instructions-fit

2026-08-27 16:01:53 +00:00

jlxq0 referenced this pull request from a commit

2026-08-27 16:01:54 +00:00

Merge pull request 'fix(channel): make the instructions fit, and assert that they do' (#138) from instructions-fit into main