gitea: stop a real npm retention when a file was not read whole
mesh/merge-gate pass: builds gitea → novox; no bus step; every machine composes with the change as it did without (4 of 4 compose)
mesh/repo-check pass: its merge-check.sh passed
mesh/delivery superseded: a newer head of the same pull request

A lockfile that could not be read is one of its repository's files that
could not be read (hq ADR 0251 §4): a version only it pins would be deleted
while in use. A real run now refuses on files_not_read as it does on
repositories_unread; a dry run still reports.
This commit is contained in:
jochen
2026-10-08 13:52:07 +02:00
parent a9960d7a1b
commit d69c0db4fc
3 changed files with 34 additions and 4 deletions
+3 -2
View File
@@ -35,8 +35,9 @@ why under `keeps_all`.
**Nothing is deleted on partial knowledge.** A repository whose files could not be listed, or a
manifest or lockfile that could not be fetched, is named under `repositories_unread` in every answer,
and a real run then deletes nothing at all. A file that was fetched but is not readable (broken JSON) is
named under `files_not_read`; what it would have named is not known, and the operator reads that list
before a real run. Under `node_modules` nothing is read: that is what a lockfile already says. An empty
named under `files_not_read`, and so is a lockfile entry of a shape the reader does not know (the rest of
that file is still read); what it would have named is not known, so a real run then deletes nothing at all
either. Under `node_modules` nothing is read: that is what a lockfile already says. An empty
repository, or one without its default branch, holds nothing to read and is not a failure.
A real run deletes each version through the forge's own interface (`DELETE