Verify resource-bounded whole-checkout retirement under the no-archive contract
I maintainer di solito rispondono entro 1 giorno
@atomantic ci sta già lavorando.
Dal 24/10/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Problem
The ordinary held-checkout archive deliberately caps one file at 25 MiB and aggregate captured content at 250 MiB. These hardcoded defensive ceilings date to #12002; they are not user settings. A normal dependency tree can exceed both, leaving a fully delivered checkout held indefinitely. The refusal protects data, but its suggestion to preserve large outputs separately has no integrated proof-bound recovery path.
The native whole-source archive already streams complete bytes with a 20 GiB source budget, bounded manifests, exact metadata verification and a source-size-based free-space requirement. It currently requires initialized modules, so an ordinary checkout cannot legitimately use it. Initializing a module just to change eligibility is not a valid workaround.
Chosen implementation
Add an explicit operator-reviewed whole-checkout mode on macOS, reusing the existing native transaction, reservation, standalone restore, quarantine, rollback and exact-receipt protocol for checkouts with zero initialized modules. Keep the ordinary archive's existing limits unchanged. Correctly represent absent/uninitialized gitlinks without materializing them, and preserve any actual working bytes beneath them. Do not change source Git state to make a backend accept it.
Apply the existing full-source byte/manifest limits and 2 * measured source bytes + 1 GiB writable-space requirement to the new mode. Bind mode, original local inventory/incarnation, measured sources and current review proof to the journal. Preserve compatibility for existing initialized journals/archives; older readers must refuse unsupported new evidence rather than infer success. No implicit cleanup of ignored files, global limit increase or weakened hash/ownership/review guard.
Affected: scripts/lib/initialized_checkout_archive.py (currently initialized-module-required), server/services/initializedCheckoutRecovery.js, process adapter, route/validation and versioned native fixtures. Related to #13334 and the resource work in #13411.
Acceptance
- A synthetic ordinary checkout with a large dependency file and aggregate content above the ordinary caps independently restores every byte and private Git record before supported quarantine/retirement.
- Zero initialized modules, absent gitlinks and populated uninitialized gitlink directories retain their real original state.
- Insufficient capacity, changing bytes/identity, active owners, nested/unknown Git stores and interrupted copy remain safe refusals with originals intact.
- Existing ordinary caps and initialized workflows retain their contracts; exact receipts survive replay without duplicate cleanup.
- Focused validation, required hosted CI, review and merge admission pass. No live cleanup is authorized by filing this issue.
Dispatch: model:heavy for compatible whole-checkout transaction and gitlink semantics; effort:high for preservation, rollback and failure-ordering coverage.
- Lingua principale
- JavaScript
- Stelle
- 38
- Fork
- 32
- Merge medio
- 46m
- PR unite (30g)
- 993
Preparare l'ambiente
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di atomantic/PortOS
-
Extend forge-as-source-of-truth cleanup to branch-reconcile and held-checkout retirementForse già presa @atomantic l’ha presa oggi. Apertacode-quality effort:high in-progress model:heavy plan planner:sonnet-5-5
atomantic/PortOS#13853 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di atomantic/PortOS
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
micromatch/picomatch#243 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
b310-digital/teammapper#1515 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
c1overzz/dsh-bili-scroll#153 ·
I maintainer di solito rispondono entro 1 giorno
-
01 type: bug 21 status: confirmed 41 lvl: easy 62 scope: viewer
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
I maintainer di solito rispondono entro 1 giorno