43% of estate .affine files are 200-byte Harvard Engine stubs — migration campaigns count deletions as ports

[hyperpolymath]

43% of the estate's .affine files are 200-byte stubs — the migration campaigns are counting deletions as ports

Surfaced while triaging #279 and #244, and verified directly.

The evidence, from panll

.affine files	747
.res / .resi files	0
.affine under 400 bytes	726 (97%)
median .affine size	200 bytes

Tree read with truncated: false, so this is a full census of the repo.

A representative file — clade-portal/src/App.affine, verbatim and complete:

// SPDX-License-Identifier: MPL-2.0
// SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell
// Ported via Harvard Engine bulk-processor

module App;

// TODO: Complete semantic implementation

That is the whole file. There are 726 of them, standing 1:1 against the 726 deleted .res files.

It is not confined to panll

Measured across the estate: 3,138 of 7,180 .affine files (43%) across 158 repos are stub-shaped, with their .res/.ts sources deleted.

repo	stub-shaped .affine
rescript	1,236
panll	726
developer-ecosystem	208
affinescript	155
ssg-collection	143 of 143 — 100%
proof-burrower	143

Why this matters more than any individual ticket

Every migration campaign in this repo measures completion as "0 banned-language files remain." A real port and a bulk deletion satisfy that metric identically. So:

• [campaign] ReScript → AffineScript estate migration (UMBRELLA) #252 (ReScript → AffineScript) reports collapsing file counts — partly because files were deleted, not ported
• [campaign] TypeScript → AffineScript estate migration (UMBRELLA) #239, [campaign #252] STEP 5 — TAIL BATCH: smallest tail-end repos (≤20 files × ~50 repos) #272, [campaign #252] STEP 6 — MID-TIER: 20-100 file repos (~15 repos) #276, [campaign #252] STEP 7 — LARGE REPOS: 100-500 file repos (~6 repos) #278 all inherit the same defect: their "remaining" tiers shrank by deletion as much as by completion
• [campaign #239] STEP 7 — PLUGIN REPOS: ~70 files in 5 repos (post step 6) #246 / [campaign #252] STEP 9 — PLUGIN-HOST: zotero-tools / wordpress-tools (gated on AS host bindings) #280 were closed today on measured zero counts. Those closures stand — there is nothing left to port — but "the work is done" and "the source is gone" are not the same statement, and the campaigns cannot currently tell them apart

This is the estate's documented absence-scored-as-completion pattern, at the largest scale yet measured. The sibling case is wordpress-tools (#662), where 108 source files were deleted and nothing was added.

The good news

Nothing is lost. Every deleted .res is recoverable from git history — the deletions are ordinary commits. This is a bookkeeping and prioritisation failure, not data loss. But recovery gets harder the longer the repos churn, and the campaign counts stay fictional until someone decides what the number is supposed to mean.

What this issue is asking for

1. A completion metric that cannot be satisfied by deletion. For example: a port is complete when the .affine file both exists and exceeds a size/AST threshold, or when its module exports match the deleted source's.
2. A decision on the 3,138 stubs — genuinely port them, restore the sources, or accept them as declared debt and stop counting them as ports.
3. A Debtfile entry or hypatia rule that flags stub-shaped .affine files, so the number is visible instead of inferred. ssg-collection at 143/143 would fail such a rule instantly.

Until (1) exists, closing any migration-campaign issue on file counts alone is unsafe — which is exactly why this is filed rather than folded into #279.

Related: #279, #252, #239, #662, #246, #280.