# No new mail was not no new feedback

Implementation included in 1.9.3rc17; not included in 1.9.3rc16. Availability
requires the matching public PyPI package and GitHub prerelease.

A saved correction can arrive after a page's last investigation. We asked what an
explicit investigation would do if the mailbox and coding sessions had nothing new.
Two synthetic tests supplied the same empty window: one with a correction, another
with an answered question. Both stopped before the feedback reached a model. The
message said there was nothing new.

Adding assertions to the mail packet would have defeated that shortcut, but it
would also have mixed different kinds of evidence. A correction is attributed
context. It does not establish another contact or a fresh research window, and it
should not disappear into a digest of old messages.

The fallback therefore does one maintenance turn for the declared page, using the
original feedback records. Its result says `feedback_only`. Accepting that turn
records which input reached the page; it leaves the investigation date alone.
An empty window without pending feedback still spends no model call.

Review uncovered a concurrency problem while following that turn. A model could
read one version, reply “no change”, and have that answer acknowledged against a
page another writer changed in the meantime. We reproduced it by changing the
canonical page inside a fake model call. No-change now checks the original page
under the same promotion lock used for an edit before it can become an acceptance
proof. Leaving a file untouched is still a judgment about a particular snapshot.

This is a limited repair to the empty-window path. It does not prove that an
assertion is true, complete the external-agent workflow, or settle receipt handling
for mixed-source and multi-round investigations. Logs keep the distinction so a
feedback review cannot quietly become evidence that new research happened.


The 23 October integration inherits current main's reviewed Python 3.11 minimum
and dependency lock. It does not waive the old dependency audit failure. The
empty-window fallback, accepted-target receipt and native no-change snapshot check
remain the same contract. Matching source and public CLI documentation must be
reviewed together before this candidate can ship. No real model, mailbox or
scheduled maintenance was run for this integration; synthetic acceptance cannot
establish the factual quality of a corrected memory.


## 23 October: a package for a manual correction trial

At this preparation checkpoint the fallback had merged, while the installed
public baseline was rc16.
A saved page cannot show whether a changed writer will use a correction: the
owner needs an installable version and an explicitly chosen investigation of
that page. We are preparing rc17 for that bounded trial, together with the
stricter inherited-claim check. Availability requires its matching public artifacts, not this preparation note.

The useful question is whether the correction remains attributed and either
produces a supported accepted page or stays pending with a reason. An available
source can contain no new material; an unavailable source is a different case.
If raw material is present, a normal investigation does not prove the empty-raw
fallback. Likewise, a receipt proves processing, not that the corrected claim is
true. The owner can compare the resulting statement with its exact original
before judging whether the page helps. No fresh real-data or native UI trial has
been performed in this preparation. The first-run and overnight product goals
remain open even if this narrower manual trial succeeds.

## 23 October: published preview

[1.9.3rc17](https://github.com/openonion/connectonion/releases/tag/v1.9.3rc17) is now a public prerelease with a matching PyPI package. The release workflow passed and verified the public artifacts against its build. This makes the bounded manual trial installable; it does not establish real model usefulness, repair saved pages or complete native product acceptance.