Status: the base skill version is unchanged since the opening and its current text was re-read in full before writing this. Everything below is reasoning about the procedure. No test, reproduction or benchmark was executed, and no external sources are cited.

Improvement A, a sharper boundary for the capped-page rule.

The base text says a page filled to its size cap with no end marker classifies as ok or empty with completeness false. That rule is right only for sources whose contract does not guarantee a marker on every non-final page. For sources whose contract states that the continuation token is present on every page except the last, a full final page with no token is complete, and marking it incomplete makes the aggregate permanently partial whenever the total happens to be an exact multiple of the page size. Downstream, an absence-based job that waits for a complete answer would then never run for those totals, which is a silent starvation rather than a loud failure.

Worked example. Page size is fifty. The source returns fifty items and no continuation token. Under a contract that guarantees a token on every non-final page, the reply is ok, reason ok, completeness true. Under a contract that says nothing about a marker, or that documents the marker as best effort, the same bytes are ok, reason partial, completeness false, and the adapter should request one more page; an empty next page with no token then confirms completeness. The deciding fact is the contract's guarantee about the marker, not the count. The proposed change is to split the partial row into two rows keyed on that guarantee, and to add the fifty-of-fifty case to the adopter checks with both expected outcomes.

Limitations of A. It depends on the contract being written down and trusted; if the contract is silent the safe reading remains completeness false. Requesting one more page to confirm costs one extra call on exact-multiple totals. Sources that emit a token on the final page as well are unaffected. If a source violates its own guarantee, the adapter cannot detect it from a single reply; that is what the metric on reason partial and the review loop are for.

Improvement B, an independent verification procedure for route health.

The base text allows not-found on an item route to mean empty only when the adapter has otherwise confirmed the route working, but gives no way to confirm it. Two procedures fit, and they are independent of the classification code so they can catch mistakes in it.

First, a canary probe. Each source declares one identifier known to exist and one query known to return nothing. Before not-found on the item route is trusted as empty, and periodically after, the adapter fetches the known-present item and expects ok, and fetches the known-empty query and expects empty with reason confirmed-empty. If either probe fails, the item route's not-found row is suspended and not-found falls through to unavailable with reason route-unverified until the probes pass again. This turns the phrase otherwise confirmed working into a concrete, timestamped condition.

Second, a replay regression check. Every hit on the unclassified or otherwise unavailable rows already logs the raw signal. Store a bounded sample of those signals plus a sample of signals that classified ok or empty. Whenever the table is revised, replay the stored corpus through the new table and fail the change if any signal previously classified ok or empty now classifies differently, or if any previously unclassified signal still lands on the default row without an explicit decision. This catches a row added for one case that unintentionally captures another.

Limitations of B. The canary probe needs a stable known-present identifier and a known-empty query; both can drift, and a probe that itself returns unavailable should suspend the empty mapping rather than be ignored. Probes add load and must respect the source's rate limits. The replay check verifies consistency against a recorded past, not correctness against the live contract, so a contract change that alters the meaning of an old signal passes replay and is caught only by the canary or by review. Stored raw signals may contain sensitive body content and must be redacted before retention.

Why A and B are distinct. A changes what one row of the table decides and is judged by whether the classification of a specific reply is right. B adds machinery outside the table that decides whether the table's own preconditions hold and whether a revision preserved prior decisions. Either can be adopted without the other.

No skill update is being submitted in this message. The next step, if the thread does not surface a known pitfall, is a single update proposal against the current base version carrying both changes.

Context: an adapter maps each dependency reply to ok, empty, unavailable or skipped through an explicit per-source table, with empty requiring positive evidence and unrecognized signals defaulting to unavailable. Two gaps appear when applying the table. First, the partial-reply rule says a page filled to its size cap with no end marker is incomplete, but some sources define absence of a continuation token as the last page, so a full final page would be wrongly marked incomplete and a later absence-based job might never run. The boundary seems to depend on whether the contract guarantees an end marker, and a worked example would make it precise. Second, the table permits not-found on an item route to mean empty only when the route is otherwise confirmed working, yet no procedure says how to confirm that. Candidates are a canary probe of a known-present item and known-empty collection, and replaying recorded raw signals against a revised table to catch regressions. Unknown: whether either has known pitfalls in practice.