A rule for the bug that formatted a disk

falls-into-subroutine. The code above a label ends without going anywhere and
the label is one something CALLs, so execution walks into the subroutine,
reaches its RET, and returns to whatever the Stack happens to hold - because
nobody called, there is no caller, and it goes somewhere nobody named.

It is worth a rule because the symptom is nowhere near the cause and changes
with the Stack. In CosmOS's monitor it was usually a byte that does not decode,
in the middle of newLine; once it was inside sbfsFormat, and the machine
formatted the disk it had booted from.

Two exemptions, and both had to exist or the rule would have reported well
written code:

A TAIL CALL IS THE SAME SHAPE AND IS FINE. Falling out of one subroutine into
another means the RET returns to the outer caller, which is real. So it only
fires when nothing since the last branch or return was a call target either -
which is the linter's usual trade of precision for being worth reading.

AND osExit NEVER RETURNS. It is how a loaded program gives the machine back, and
every program here ends with it and then writes its helpers underneath. Without
that, twelve well written programs were reported. It is the one name from the
system this tool knows, and the comment says why it is there.

Also SRET, which stopsFallthrough did not list. It returns from a handler
exactly as RET returns from a call, and leaving it out is a gap in every rule
that asks what reaches an instruction. Load bearing rather than tidy: without it
cosmos.asm reports a handler ending in SRET as falling into the routine written
under it.

A first pass over the file collects call targets, because a subroutine is very
often called from further down than it is written.

The corpus reports none of it, which is the point rather than a disappointment,
and the Test Manual now says so - a baseline entry that is absent is otherwise
indistinguishable from a rule that never runs. Checked against the version of
cosmos.asm from before the fix, where it names the line.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW

SplitBit Test Manual.md

@@ -446,6 +446,13 @@ than reading all of them:
 file across the whole corpus - 33 file-and-rule pairs. It is checked on every run, and it
 is checked **in both directions.**
 
+The corpus holds none of `falls-into-subroutine`, and that is worth saying rather than
+leaving as a gap in the file. It is the rule added after a bug in CosmOS's monitor walked
+into `sayPrompt`, reached a `RET` that had no caller, and returned into the filesystem's
+format routine - which formatted the disk the machine had booted from. A rule whose count is
+zero everywhere is not a rule doing nothing; it is the shape of fault that is worth never
+having again.
+
 A new warning appearing is a regression. A recorded warning *disappearing* is also
 reported, and that is the half people do not expect: it means either that somebody fixed
 something and did not record it, which is fine and takes one command, or that a rule