zeekayandHanzo Dev ee22f0d3b1 guard: fail when a module this fork owns disappears ...

An upstream rebase deletes our files without a conflict. Upstream never had
them, so taking "upstream's version" of a path we invented is a clean delete —
nothing to resolve, nothing red, and the module's own tests leave with it. That
is how e443a4dab removed three on 08-01 and was found on 08-08, by which point
the tree had been rebased twice more on top of it:

  common/redis/base-adapter.ts   the Base/SQLite KV strangle. 0.1.8 is running
                                 it right now — "cdp-kv backed by Base" is in
                                 the live pod's log — and the tree no longer
                                 has the file.
  api/team-access.ts             authorizes :team_id against the principal's org
  api/router.ts                  where the IAM gate was mounted

A ratchet rather than a wishlist: HELD must exist, LOST is what is already gone
with the commit that took it. Green today, red the moment a fourth module goes,
and red again if a LOST one returns without being moved to HELD — a file that
reappears untracked is how the list quietly stops describing the tree.

Verified in all three states: unchanged exits 0, a missing HELD entry exits 1,
a returned LOST entry exits 1.

Co-authored-by: Hanzo Dev <[email protected]>

2026-08-08 22:02:27 -07:00

..

fork-inventory.py

…