Samuel CuiandClaude Opus 5.5
42881b1679
The ARMv5 matrix entry could only fail: the build refuses GOARM=5 before compilation and the candidate set never contains an ARMv5 archive. Drop it and its allowed-failure setting so a failed job always means a real failure. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Developer Documentation
This is the implementation and contributor entry point. For installation, configuration and daily operation, start with the separate User Guide.
Architecture and operations describe the current YATM v1 development line; research records the evidence and open questions behind further work. Published versions and their change notes belong to GitHub Releases; this tree is not a release archive.
Start with the contributor rules, the domain vocabulary and the documentation rules. Component guides live beside their code: frontend, Preview helper and its build recipes, the LTFS file backend adapters and the cartridge memory fixtures.
Pre-stable Compatibility
The required compatibility baseline is the supported v0.1.x migration/import path. Until the first
stable v1 release, changes to data formats, APIs, entities, schemas, Job bundles and metadata backups
between unpublished or pre-stable v1 builds require no compatibility layers or version/revision bumps.
The persistence contract owns the current artifact
identities and versions independently of software release numbers.
Configured Tape scripts have a separate, long-term compatibility requirement. Upgrades preserve user adapters wherever possible; a necessary incompatible change requires explicit approval and an actionable notice before upgrade, including pre-stable releases. The Tape script contract owns that boundary.
Known incompatible installations are rejected before writes. Their data is retained until the operator chooses backup, migration, conversion or reinstallation; YATM never clears databases or physical files automatically. Disposable development fixtures are regenerated only through an explicit reset. Remove this temporary rule when preparing the first stable v1 release and replace it with the published stable upgrade policy.
Current Architecture
- Overview and ownership
- Persistence and recovery
- Library identities, organization and backups
- Jobs and execution
- Media backends and file I/O
- Tape devices, lifecycle and formats
- Tape read planning
- Preview storage
- Interface contracts
- APIs and services
- User interface
User Documentation
- User Guide entry
- Installation and service configuration
- Upgrade from v0.1.x
- Offline migration and repair
- Locations
- Library and mounted Volumes
- Archive, Restore and Scan
- Devices and Tape operations
- Tape scripts
- Faster Restores with Auto read order
- Command-line reference
- Independent tar Tape recovery
Contributing
- Documentation rules
- Development checks and test environments
- Code layout and test ownership
- Automated E2E
- Performance acceptance
- Local Demo
Release
- Release process
- Package acceptance
- Physical Tape E2E
- Physical Tape host runbook
- Physical tar acceptance
- Physical Tape measurements
Research
Research is published with the repository. Each study states its objective, source versions, confirmed findings, community observations, unresolved questions and criteria for evaluating possible approaches. A study describes the current state of knowledge; it does not establish implemented behavior or authorize experiments and production changes.