Samuel CuiandClaude Opus 5.5
6ad3a4c3e2
Jobs and Preview hid their whole form, including the page action row, until values loaded while Library and Devices kept theirs; all four now keep the disabled action row. Draft validation failures used the load/save error and offered "Reload saved settings", which would discard the draft; they are now a separate in-place message without that action. Device discovery uses the shared progress indicator instead of status text. 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.