The central contract is directly supported by Python’s current 3.14.10 tempfile documentation: SpooledTemporaryFile remains in memory until its size exceeds max_size or fileno() is called; rollover() independently forces conversion to an on-disk temporary file. The same documentation explains that a POSIX TemporaryFile may have no persistent visible directory entry and that Linux can use O_TMPFILE, so an empty directory listing is not evidence that rollover did not reach disk.
Primary-source verification
Current CPython source independently exposes the mechanism: check() uses file.tell() > maxsize, rollover() replaces the in-memory object with TemporaryFile, and fileno() invokes rollover() before returning a descriptor. This is why fileno() cannot serve as a passive “has this rolled yet?” probe.
The io documentation confirms that fileno() returns an underlying descriptor when one exists and otherwise raises an OSError-family exception; the os documentation defines os.fstat(fd) as a descriptor-level status query. Those two interfaces underpin the fixture’s negative control and post-rollover disk evidence.
The behavior of max_size=0 remains ambiguous. CPython’s implementation suppresses ordinary size-triggered rollover when max_size is zero, while the long-standing upstream issue records the tension between that implementation and a literal reading of the documentation.
Executed evidence
The recorded runtime was CPython 3.13.5, Linux-6.18.57-x86_64-with-glibc2.41; the fixture SHA-256 was 9a16330020ea0d31272311fe2004f39678c805ac448935e66381132c88ade57d, and the loaded /usr/lib/python3.13/tempfile.py SHA-256 was 58f93535c4a68e5c733bc220b33490373298a4c6b7c087669c0051eeaed5c409.
All eleven independently authored cases passed their manifest. Seven- and eight-byte writes with max_size=8 remained memory-backed; nine bytes rolled. Calling fileno() at zero bytes and at three bytes rolled immediately to _io.BufferedRandom with a valid regular-file descriptor. Explicit rollover() below the threshold did likewise. Repeated rollover retained the same live descriptor within the same object, and writing after fileno() preserved the rolled state and content. Every rolled descriptor returned EBADF after close. No warnings or unexpected exceptions were observed.
Python 3.14.10 was NOT EXECUTED. Its equivalent outcomes are therefore labeled EXPECTED / NOT EXECUTED, even though the current documentation and source remain consistent with the executed 3.13.5 behavior. Python 3.14.10 was released October 25, 2026.
Related validation and learning resources
The ZIP integrity article validates duplicate archive-member occurrence identity and CRC/content evidence; the asyncio.to_thread article validates context-capture timing; the SQLite article validates foreign-key enforcement across connection/transaction state; the PostgreSQL article validates advisory-lock ownership and lifetime; and the SQS article validates receipt-handle binding. This validation uses a different oracle and ledger: backing-store state, byte-boundary behavior, descriptor validity, content preservation, and cleanup.
The Refonte System Administration program page lists a six-month period, 10–12 hours per week, system installation/configuration, troubleshooting, Linux/Windows administration, virtualization, backup/recovery and related competencies; it describes a potential internship and two certificates. The page does not identify SpooledTemporaryFile rollover or fileno() validation as curriculum. The page also contains two differently worded prerequisite statements.
Acceptance decision
For the executed CPython 3.13.5 fixture, the bounded evidence decision is ACCEPT. A workflow that interprets "max_size not exceeded" as "SpooledTemporaryFile cannot have hit disk" requires REPAIR, because fileno() and explicit rollover() are independent documented transition triggers. A release targeting Python 3.14.10, another Python patch, another implementation, or another platform requires RERUN because those environments were not executed here. Any run missing its pre-trigger snapshot, independent expected value, descriptor/content evidence, warning/exception record, or cleanup evidence is HOLD, not a successful release gate.