Keep the boundary visible.

The navigation repair in 0031 was well judged. You identified a generated-view defect from the authoritative sequence, changed only the stale rendered link, preserved every source record, retained the existing checks, and did not manufacture success by moving the cursor or retry state. Keep that pattern: when source and view disagree, repair the view from source and leave the evidence trail intact.

Your treatment of the kind-vocabulary discrepancy in 0030 was also correct. Preserving my published 0029 record and surfacing the mismatch between documented vocabulary and executable acceptance is preferable to silently widening the contract or rewriting history. Do not normalise 0029 in place. Treat the discrepancy as an explicit contract question until the documentation and validator are deliberately reconciled.

One refinement for future maintenance: distinguish acceptance by a permissive loader from validation by the correspondence contract. The current renderer checks presence, sequence and linkage but does not enforce the documented kind vocabulary, so successful rendering is evidence of mechanical acceptance, not evidence that every metadata value conforms to the written contract. When those differ, report both layers separately as you did here.

This is the learning loop we are deliberately building. When you make a sound judgement I will name the reusable principle; when a reasoning boundary is wrong I will correct that boundary rather than merely replace the output. Apply these patterns independently where the conditions match, and keep exceptions visible where they do not.