docs: F-037, the ingress corrections, and the priority order reversed

HANDOFF section 4 said WORK-ORDER-004 was pending and that CIVICVS could not
see any of this work. It was rewritten thirty-two minutes after 1fdb115 closed
the ingress, in the same session, against the work order's old state rather
than its new one -- so HEAD described a world where the thing you were already
looking at did not exist. Section 11 row 7 carried the same staleness. Both
corrected, and the correction says how it happened, because section 0 was added
to prevent exactly this and did not.

Three things 1fdb115 recorded as unsettled were never promoted into section 11
and are now rows 8 through 10: TLS renewal has never been observed to succeed
for this name and is first due before 2026-12-10; the composer has no
acceptance criteria of its own, only the path to it does; and the service is
world-reachable and unauthenticated, which section 4 item 5 called a conscious
decision to be made before publishing and which publishing has now made due.

Priority items 1 and 2 reversed. The original case for authorship first was
that records made before the field exists can never be attributed. That was too
strong, and too strong because the field is excluded from both hashes: a record
regenerated later keeps its input_id. What it does not keep is build_id, which
covers Shapely and GEOS, and boolean results on near-degenerate geometry shift
between GEOS releases -- the F-034 mechanism. Attribution is recoverable, not
free. The residual argument stands and the field landed first at 48d5665.

Recorded under item 2, because it is the first thing STL export runs into:
length_view is not in COMMON_GROUPS, so the Full Length branch is unreachable
from the composer and every export would silently be a 100 mm preview. The
sweep must equal model_length_mm(p), already published as LENGTH_MM, or the
record's VOLUME_MM3 and MASS_G describe a different object than the file beside
them. Also split the roadmap's STL/STEP bullet: STEP needs the kernel, STL does
not, and one line implying both was left behind by the section 5 correction.

F-037: a tar stream rooted at "." re-owned the repository root. tar x ran as
root and applied the "." entry's ownership to /var/www/mechcomp; the chown that
followed named only src and tests. Everything below the root was correct, so
547 tests passed and only git noticed. Corrected by chown on one path, owner
only, no -R. safe.directory was not added -- that is F-008 and would have
masked this and every later instance.

Two of F-037's three consequences are process defects of mine rather than facts
about the environment. The verification step ran before the landing that
destroyed it, so a git status ahead of the breaking step reads as a pass -- the
F-027 pattern in a new place. And section 7 says record a failure before
correcting it; I corrected first. Both recorded rather than quietly fixed.

PROCESS section 3 gains two REQs, because the delivery path as documented
produces F-037 every time: the chown must name the directory the files land in,
and a tar transport must name its top-level directories rather than root at
".". pct push is simpler for a single file and cannot reproduce it at all.

Section 8 gains the bytecode rule: PYTHONDONTWRITEBYTECODE=1 and clear
__pycache__ between mutations. A stale .pyc masked a real defect once and every
mutation result reported before that was optimistic by an unknown amount. A
mutation surviving on stale bytecode is indistinguishable from one surviving on
a weak test.

Open question 11 is new and is CIVICVS's: ct-baseline.sh exits 0 with the F-037
condition present, so by section 9a the ownership of a service working tree is
not part of the container standard. Whether it should be is a decision about
host property covering three projects.

docs/FAILURES.md

@@ -6,7 +6,7 @@ Compiler environment.
 | | |
 |---|---|
 | Scope | All instances. Staging entries are marked `srv-b`. |
-| Updated | 2026-08-22, closing F-034 |
+| Updated | 2026-09-12, recording F-037 |
 | Method | `PROCESS.md` section 7 |
 | Rule | Append only. Never edit an entry except to add a `Resolution` line. |
 | Numbering | Sequential, never reused. See §0 on the renumbering. |
@@ -1022,6 +1022,56 @@ that exist only as examples; each is a future F-035.
 
 ---
 
+### F-037 — a tar stream rooted at `.` re-owned the repository root
+
+CT 100. Development delivery.
+
+**Observed:** after landing a five-file tarball and running `chown -R
+mechcomp:mechcomp` on `src` and `tests`, every subsequent git command failed
+with `fatal: detected dubious ownership in repository at '/var/www/mechcomp'`,
+and git offered `git config --global --add safe.directory /var/www/mechcomp` as
+the remedy. `stat` showed `/var/www/mechcomp` at `root:root`, while `.git`,
+`src`, `tests` and `Makefile` were all still `mechcomp:mechcomp`. The test suite
+ran green throughout — 547 passed — because pytest does not care who owns the
+directory.
+
+**Cause:** proven. The delivery used `tar cf - -C /root/incoming/unpack . | pct
+exec 100 -- tar xf - -C /var/www/mechcomp`. A tar stream rooted at `.` carries
+an entry for the destination directory itself; `tar x` ran as root and applied
+that entry's ownership to `/var/www/mechcomp`. The `chown` that followed named
+only the payload subdirectories, so nothing corrected the root. Everything
+*below* the root was already correct, which is why the damage was invisible to
+every check except git's own.
+
+**Correction:** `chown mechcomp:mechcomp /var/www/mechcomp` — one path, owner
+only, no `-R`. Mode was already 755 and unchanged. `-R` was deliberately not
+used: everything underneath was already correct, and reaching for it is the
+habit behind F-007. `safe.directory` was **not** added; that is F-008 and would
+have masked this and every later instance.
+
+**Consequence:** three, and two of them are mine rather than the environment's.
+
+1. `PROCESS.md` §3 gains two REQs: the `chown` must name the directory the
+   files land *in*, and a tar transport must name its top-level directories
+   rather than being rooted at `.`. The delivery path as documented produces
+   this every time, so an automation writer following §3 alone lands here.
+2. The verification step ran *before* the landing that destroyed it. A `git
+   status` placed ahead of the breaking step reports a clean tree and reads as
+   a pass. Verification must follow the step it verifies — the F-027 pattern
+   again, in a new place.
+3. §7 says record a failure before correcting it. I corrected first and wrote
+   this afterwards. Recorded as a process defect rather than quietly fixed,
+   because an undisclosed one teaches the next assistant that the rule is
+   optional.
+
+**Open:** `ct-baseline.sh` exits 0 with this condition present — it does not
+check the ownership of a service's working tree, so by §9a the property is not
+part of the standard. Whether it should be is a CIVICVS decision; the script is
+host property covering three projects. Carried as open question 11 in
+`HANDOFF.md`.
+
+---
+
 ## Open, not closed
 
 | # | Status |
@@ -1045,5 +1095,6 @@ that exist only as examples; each is a future F-035.
 | F-034 | **Closed** 2026-08-22. Measured: the port is exact, the reference is noisy. 30 of 113 accepted cases, worst relative error 2.24e-05, confined to `SECTION_AREA_MM2` and its two derivatives. Nothing correctable in the port; resolved in `test_oracle.py` by bounding at eight units in the last place of the oracle's six-significant-figure record. Suite green at 468 passed. Specification in `docs/ACCEPTANCE.md`. |
 | F-035 | **Corrected** 2026-08-19. Use `runuser`, never `su`; `mechcomp` is `nologin`. |
 | F-036 | **Corrected** 2026-08-22. The interpreter is `venv/bin/python`, never system `python3`. Same class as F-035. |
+| F-037 | **Corrected** 2026-09-12. Owner of the repository root restored; `PROCESS.md` §3 amended. `safe.directory` not used. Baseline coverage open — see open question 11. |
 
 Everything else is closed with a proven cause and a proven correction.