Coverage guard: the required side scans ONE assembly, so a SchemaJson.ToJson seam in DeltaSharp.Core or DeltaSharp.Engine is invisible (GREEN 3; identical seam in Storage is RED 1)

[khaines]

Summary

DeltaFooterLogParityCoverageTests.RequiredSites() documents itself as

"Every production method that reaches SchemaJson.ToJson, TRANSITIVELY."

It is not. ProductionMethods() enumerates exactly one assembly:

foreach (Type type in typeof(DeltaWriteTarget).Assembly.GetTypes())

SchemaJson is internal in DeltaSharp.Abstractions and InternalsVisibleTo is granted to DeltaSharp.Engine and DeltaSharp.Core as well as DeltaSharp.Storage. A schemaString-producing call site written in either of those two assemblies is invisible to the required side, so the guard reports full coverage while a real serializer seam is asked about by nothing.

Measurement at HEAD c1a2d03

Identical seam class, two placements, matched controls:

placement	call	result
src/DeltaSharp.Storage/Parquet/ParquetFileWriter.cs (ArchNewSeamE)	SchemaJson.ToJson direct	RED 1 — unreached call sites: ArchNewSeamE.Emit
src/DeltaSharp.Storage/Parquet/ParquetFileWriter.cs (ArchNewSeamF)	via the DeltaSchemaJson.ToJson wrapper	RED 1 — unreached call sites: ArchNewSeamF.Emit
src/DeltaSharp.Core/ArchNewSeamG.cs	SchemaJson.ToJson direct	GREEN — Passed! - Failed: 0, Passed: 3, Total: 3

The seam:

namespace DeltaSharp.Core;

internal static class ArchNewSeamG
{
    internal static int Emit(global::DeltaSharp.Types.StructType schema)
        => global::DeltaSharp.Types.SchemaJson.ToJson(schema).Length;
}

The two Storage placements prove the required-side scan is live and that the transitive widening landed (the wrapper case is the one #740 closed). The only variable between ArchNewSeamE (RED) and ArchNewSeamG (GREEN) is the assembly.

Severity — LESS, not FALSE, today

Everything that currently commits a schemaString lives in DeltaSharp.Storage, so over the actual population the guard's claim holds. What is unbounded is the future: a serializer call site added in DeltaSharp.Core (which owns Sql/ and Plans/, where a CREATE TABLE path could plausibly build and serialize a schema) or in DeltaSharp.Engine would reproduce issue #679's footer/log divergence with the whole solution green — which is precisely the failure mode this guard family exists to prevent, and precisely the reason the required side was widened in the first place.

This is also the eighth prose-totality claim in this PR to be falsified by measurement; the pattern is consistent enough to be worth naming.

Remedy

Derive the assembly set instead of naming one:

// every assembly that can see SchemaJson at all
foreach (Assembly a in AssembliesWithAccessTo(typeof(SchemaJson)))   // IVT-derived, not hand-listed

i.e. read InternalsVisibleTo off DeltaSharp.Abstractions and scan every production assembly named there. That keeps the axis derived rather than hand-listed at one, which is the practice this PR adopted elsewhere, and it is the same shape as the direct→transitive widening in #740: one hop short of the property.

Alternatively, if the intent really is "Storage only", say so in the summary and add an assertion that no other production assembly references SchemaJson.ToJson — so the narrower claim is enforced rather than assumed.

---

Filed by the Security seat, PR #693 final round, HEAD c1a2d03. Gate confirmed at this HEAD: Release 7192/0, Debug 7195/0, builds 0 Warning(s) 0 Error(s) both configs, dotnet format --verify-no-changes exit 0, git diff 0aede31..c1a2d03 -- 'src/**/*.cs' 0 lines.

[khaines]

Disclosed at the site in 8f001e0, applying the #741 precedent so the two residuals are treated identically.

RequiredSites() now carries a second LIMIT paragraph:

LIMIT -- the set is scoped to ONE assembly, DeltaSharp.Storage (ProductionMethods walks typeof(DeltaWriteTarget).Assembly). "The production assembly" reads as though there is only one, and there is not: SchemaJson is internal but IVT-visible to DeltaSharp.Engine and DeltaSharp.Core as well, so a call site in either of those is outside this walk entirely and this guard will stay green while it goes undriven. Widening the scope is the fix, not widening the walk. Tracked by #743.

Verified the two facts the sentence asserts rather than restating your report: ProductionMethods walks typeof(DeltaWriteTarget).Assembly (:237), and DeltaSharp.Abstractions.csproj:62-63 grants IVT to DeltaSharp.Engine and DeltaSharp.Core.

No code change -- the guard's claim is scoped and therefore true; this makes the scope salient. Issue stays OPEN for the actual widening.

Gate at 8f001e0: Release 7192/0, Debug 7195/0, builds 0/0 both configs, format exit 0, git diff 0aede31..8f001e0 -- 'src/**/*.cs' 0 lines.