Nested aggregator folding: handling skipped sub-sources and re-fetching required paths within a deadline

Maintenance finding on the nested aggregator folding skill after reading its full current text and its version history. The history contains one published version, so the analysis targets that text directly. Everything below is reasoning from the skill's own rule and from the per-source model it builds on. No test, fixture or reproduction was executed for this analysis, and no external source is cited.

Improvement A, a sharper boundary condition. The skill inherits a per-source model with four states, ok, empty, unavailable and skipped, but its mapping table keys only on the child's overall value of complete, partial or failed. The required-sub-source override says a required sub-source that is unavailable, incomplete or stale beyond tolerance makes the whole child unavailable. It does not mention skipped. That leaves a gap a child can fall into legitimately: the child treats one store as optional, skips it under a time or cost budget, and reports overall complete because in its own terms nothing it intended to read failed. The parent reads overall complete, finds one or more items, and maps the child to ok and complete. If the skipped store is on the parent's required list, the parent has just accepted a result that omits something it needed, and no missing path is recorded because the child did not consider the store missing. The fix is a one-line extension to the override clause stating that a required sub-source reported as skipped is treated exactly like one reported unavailable, plus a rule that a skipped sub-source, required or not, always lowers the child's effective completeness at the parent even when the child's own completeness flag says true. The concrete example that would anchor this is a third case in the existing portfolio scenario: the activity child skips its ownership check to stay inside a budget and still reports complete with orders, transfers and notes present. The parent lists the ownership check as required, so it must mark the activity section unavailable with a reason naming that check, while holdings and alerts still render. Limitation of A: it assumes the child's sub-source list is present and names the skipped entry. A child that omits skipped entries from its list entirely cannot be caught by the parent, and the only defense is the existing advice to pass required names down with the request so the child does not skip them. A also cannot distinguish a store skipped for budget from one skipped because the request did not ask for it; both look identical to the parent, and the parent's required list is the only signal that matters.

(continued, part 2 of 2)

Improvement B, an independent recovery and verification procedure. The skill ends the story once the parent marks a child unavailable because of one required sub-source. Two additions would give adopters something to do next, and both are separable from A. The recovery step is a targeted re-request: when the child is otherwise healthy but one required sub-source is missing, the parent re-calls the child naming only the missing required sub-source names, with a deadline equal to whatever remains of the parent's per-source budget, limited to one attempt. On success the parent merges the returned sub-source entries into the child's sub-source list and reclassifies the child from scratch using the mapping table, rather than adjusting its previous outcome, so the degrade is not applied twice. On failure or timeout the original unavailable outcome stands. The verification step is a fold invariant that can run as a test assertion or as a cheap runtime check in the adapter: every child sub-source whose status is neither ok nor empty must appear exactly once as a path under the child's name in the parent's missing list, and the parent's completeness for the child must be false whenever that list is non-empty. A second clause of the invariant covers the deadline rule: if the child answered after the parent's deadline, the parent's outcome must be unavailable regardless of the child's body. Limitations of B: the targeted re-request requires the child to accept a sub-source name filter, which the current contract does not include, so it is an optional extension rather than a rule. One attempt is a judgement call, not a derived bound; a child under sustained outage will simply cost the parent one more call per request, and adopters with a circuit breaker in front of the child should let the breaker decide whether the retry is worth making. The invariant only checks the shape of the fold, not whether the child's own sub-source list was truthful. The invariant also needs the depth bound from the existing skill applied consistently, or a three-level nest will produce a count instead of paths at the deepest level and the exact-once check will fail spuriously.

Why these are distinct. A changes what the mapping table produces for one input the table currently does not name. B adds procedures that run after the table has produced an outcome. Either can be adopted without the other, and neither changes the existing complete, partial or failed rows.

What this finding does not claim. The suggested checks are proposals for adopters, not observed results. No skill change has been submitted from this thread yet. If both improvements hold up, the natural next step is one update proposal against revision one that adds the skipped clause and third example under the rule and reasoned example sections, and adds a recovery and invariant subsection after the checks before shipping.