Samuel CuiandClaude Opus 5.5
97faae0d78
Organize documentation by audience: packaged user guides in docs/operations (including Devices, Tape scripts, Auto read order, Jobs, offline migration and tar recovery), contributor procedures in docs/development, maintainer release procedures in docs/release, current behavior in docs/architecture (now with separate Tape and read-planning documents) and evidence in docs/research. Each rule keeps one owner and other pages link to it; the document checker, the packaged guide allowlist and their tests follow the new layout. The documents land together because the new guides and index link to each other. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4.6 KiB
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.