[davidtaikocha]

Problem

validateManifestAnchorNumbers short-circuits for forced-inclusion sources:

if isForcedInclusion {
    for _, anchor := range anchors {
        if anchor != parentAnchorBlockNumber { return false }
    }
    return true          // returns before the window check
}

It never reaches validateManifestAnchorProgression, the only place the
[origin-MAX_ANCHOR_OFFSET, origin] window is enforced (512 blocks on mainnet, 128 elsewhere).

Canonical derivation applies the monotonicity and window rules to every block of every source
and exempts forced inclusions only from the strict-advance rule
(taiko-client-rs crates/driver/src/derivation/pipeline/shasta/validation.rs,
validate_anchor_numbers: the range checks sit in the per-block loop with no is_forced_inclusion
guard; only the trailing !is_forced_inclusion && highest_anchor <= parent_anchor rule is gated).

applyInheritedManifestMetadata pins a forced source's anchor to the parent's and leaves
Transactions untouched. So whenever the parent anchor has stalled more than MAX_ANCHOR_OFFSET
behind the proposal origin, the inherited anchor is outside the window and the two implementations
disagree:

	forced source with a stalled anchor
canonical	source replaced by the default manifest → anchor-only block
gaiko2 (before)	source kept → block still carries its transactions

Same proposal, two different block hashes and state roots — so gaiko2 would attest to a checkpoint
over a block canonical node software does not derive. git log -L 509,545:internal/prover/manifest_validate.go
shows the window check used to apply here and was replaced by this early return in 3d4b50c.

Fix

Run validateManifestAnchorProgression for every source, and skip only the advance rule for forced
inclusions — a direct mirror of the canonical function.

The per-source anchor == parentAnchor check is dropped as redundant, not relaxed:
applyInheritedManifestMetadata already pins forced anchors to the parent value before validation,
and validateSourceAwareManifestAnchors re-checks the same equality across sources. Keeping it
would have made gaiko2 stricter than canonical, which is its own divergence risk.

Note this is consistent with Derivation.md, which exempts forced inclusions from being defaulted
"even when the anchor number does not advance" — the advance rule is exactly what this change still
skips for them.

Tests

Five new tests, each watched failing before the fix:

• forced source below the window → rejected
• forced source above the origin → rejected
• forced source stalled but inside the window → still accepted (the advance exemption is preserved)
• mainnet 512-block edge: accepted at the boundary, rejected one block past it
• validateSourceManifest composition: an otherwise well-formed forced source with transactions and
  a stalled anchor is invalidated, so prepareSourceManifest replaces it with the transaction-free
  default manifest

go test ./..., go vet ./... and gofmt -l are clean.

Sequencing

Please land this before any fix to the parent CheckpointStore storage-slot derivation in
shastaCheckpointStorageSlots. That slot derivation currently fails closed for every proposal
containing a forced-inclusion source, which is the only reason the divergence above is not reachable
today; correcting the slot first would make it reachable. With this merged, that ordering constraint
goes away.

🤖 Generated with Claude Code

[smtmfft]

Let’s hold off on merging this for now, since this is a permissionless feature that will only be enabled in about 3–6 months.
We also need to update the bootstrap script accordingly. Raiko2 SGX will need this feature as well.