Every result on this page belongs to the v0.1 source, layout, fixtures, and environment recorded at the time. It does not establish compatibility or release readiness for current SOW.
The v0.1 archive contains 112 dated evidence reports from 2026-07-11 through 2026-07-31. Publishing all of them as blog posts would make the public site less useful: many are narrow fault closures, repeated current-source audits, or transcripts for a specific implementation seam.
Discarding them would lose something equally important. The reports show which design decisions came from real clients and counterexamples, which came only from local or mock tests, and where the team deliberately refused to turn incomplete evidence into a PASS.
This ledger preserves that boundary.
Evidence timeline
| Window | Reports | What the work concentrated on |
|---|---|---|
| 2026-07-11 | 3 | Real APT/DNF client baseline, 72,310-package manifest scan, 50k upstream streaming |
| 2026-07-12 | 35 | APT/YUM protocol behavior, CAS/GC, publication ordering, recovery, MinIO, performance, migration, build/supply-chain gates, and cloud harness design |
| 2026-07-13 | 2 | RPM trust closure and selected-set materialization recovery |
| 2026-07-14–16 | 14 | Legacy topology, family migration, physical ownership, full-copy adoption, and package-signature inventory |
| 2026-07-17–20 | 39 | Cloudflare/R2/COS/Edge safety, provider attestation, cutover receipts, configuration bounds, and checkpoint-fenced deletion |
| 2026-07-22 | 10 | Descriptor/path identity across stage, apply, prune, rollback, and residue cleanup |
| 2026-07-26–29 | 7 | Recursive durability, hostile-writer limits, replacement outcomes, preserved audits, and provider corrections |
| 2026-07-30–31 | 2 | Clean-room APT/YUM/asset MVP and final legacy-source baseline |
What had strong supporting evidence
Real package clients and large repositories
The first evidence set used real APT and DNF clients rather than validating only generated XML or text. It also measured scale explicitly:
- real APT/DNF client compatibility;
- 72,310-package manifest scanning;
- 50k upstream streaming;
- separate 50k APT, YUM, materialization, publish-plan, and legacy-adoption runs.
These reports justified streaming and bounded-concurrency requirements. They did not prove that every later layout inherited the same client behavior or performance.
Protocol closure and negative counterexamples
Several design changes came from negative proof rather than optimistic implementation:
- APT fixed-alias negative PoC showed that old client semantics constrained atomic alias claims.
- YUM raw-alias signature-bridge negative PoC separated legacy baseurl compatibility from strong generation-pinned metadata.
- YUM generation atomicity recorded exactly which pointer behavior could and could not be made atomic.
The lasting lesson is not the V1 URL scheme. It is that a standards-shaped repository and a specific client transaction are different claims.
Failure and recovery
The archive exercised interrupted sync, publication, materialization, snapshot, archive, and remote-restore paths. Later reports bound file operations to descriptors and exact path identities, then covered rollback, quarantine, and preserved evidence.
Representative records include:
- publish/recovery adversarial review;
- selected-set recovery closure;
- state-lock and atomic publication;
- derived-state replacement outcomes.
This work is why current SOW distinguishes pre-commit abandon, post-intent forward recovery, and contradictory evidence instead of exposing one generic “retry” path.
Legacy migration
The migration evidence enumerated old Make targets, physical layouts, repository families, consumer configuration, package-signature inventory, and rollback. It used read-only copies and exact receipts before mutation.
That program proved a particular Pigsty cutover path. It did not justify carrying legacy topology into the permanent product model. Its most valuable result was the discipline: migration assumptions become explicit data and executable gates, then retire after the cutover.
Provider and Edge experiments
The archive contains real and simulated R2, MinIO, Cloudflare, COS, and Edge work. The stronger reports state exact scope:
- real R2 storage protocol;
- R2 publication storage transaction;
- full-provider checkpoint-fenced deletion;
- Cloudflare bootstrap, private-domain, provider-attestation, and rollback records.
Some cells used owner-designated nonproduction resources; others were offline or mock validation. A real R2 result never proved COS conditional replacement, EdgeOne cache behavior, or current SOW’s target state machine.
What the archive did not prove
The evidence set was large, but its own documents retained open boundaries:
- no one PoC established universal APT, DNF, proxy, mirror-tool, or provider compatibility;
- MinIO S3 compatibility did not equal Cloudflare R2 or Tencent COS semantics;
- an accepted design or adversarial review was not implementation evidence;
- a local/mock provider result was not a production deployment;
- a PASS remained attached to its source revision, fixture, URL layout, and environment;
- v0.1 evidence could not validate the later Plain/Managed or single-payload designs.
Those limitations are a feature of the archive, not a defect to edit away.
What became part of the design method
The evidence program left six durable practices:
- Name the evidence layer. Design, source, unit/fault test, real client, provider, artifact, and production are separate.
- Retain negative results. A counterexample often defines a safer product boundary more clearly than another successful happy path.
- Bind PASS to immutable inputs. Source revision, container/client version, provider, route, and fixture belong with the result.
- Test scale as a contract. Large repositories need measured memory, call count, and concurrency behavior.
- Retire evidence with its model. Historical proof remains useful for explanation but never silently upgrades a new layout.
- Keep build and supply-chain checks standing. Toolchain portability, dependency vulnerability checks, static analysis, dead-code closure, and reproducible delivery are continuous release gates rather than one-time cleanup tasks.
These practices now appear in Design Principles and the current compatibility reference.
Primary source
The immutable v0.1.0 evidence directory contains every dated report. This article is the maintained interpretation; the raw files remain the audit trail.
Continue with The v0.2 Reset to see how those lessons were kept while the product model became much smaller.