How the project stays healthy
Explore Tabplate architecture, performance checks, test coverage, local backups, release versions and engineering priorities.
Five priorities for Tabplate
These are engineering priorities for this product, not measured quality scores.
| Practice | Importance | Why |
|---|---|---|
| Backup & restore | Critical | Local content must survive mistakes, failed writes and upgrades. |
| Versioning | Critical | Code releases, data formats and exports must remain compatible. |
| Tests | Very high | Data operations and gestures have many failure paths. |
| Modularity | High | Fast UI iteration should not destabilize storage or other features. |
| Project wiki | High | Explain contracts and decisions so future changes stay safe. |
A small architecture map
model.mjs validates the data model. storage.mjs manages local transactions, checksums and checkpoints. backup.mjs handles portable backup formats. Organizer, motion, tab rail and drag modules provide focused behavior. app.mjs connects UI rendering, dialogs and commands.
The implementation is dependency-light. The main UI module and accumulated style overrides are the biggest maintainability pressure points. The next useful split is rendering → commands → dialogs, with explicit module contracts. More files alone do not make the system more modular.
Test the promises, not the line count
The current audit ran 63 unit tests successfully and separate browser checks for performance and responsive geometry. That is not a coverage percentage or proof that every interaction is tested. Coverage instrumentation and a routine CI gate have not yet been established.
Prioritize corruption recovery, interrupted writes, concurrent tabs, import/export, upgrades, permission denial, drag cancellation and Undo. Then cover keyboard navigation, long names, languages and small screens. Keep an explicit manual smoke checklist for operating systems and the real Chrome permission dialogs.
What the engineering wiki should hold
A module map with ownership and contracts; data shape and migration rules; privacy/network flows; recovery playbook; test matrix; release checklist; and short decision records explaining tradeoffs. User help and engineering notes have different audiences and should stay distinct.
Version three different things
Product release: the Chrome manifest version, currently 0.11.26. Data format: the schema/backup compatibility version. Repository revision: an increasing number for state changes. None of these replaces a source-control commit and release tag.
Recommended next steps: a tracked source repository with an off-device remote; release tags and a changelog; old-backup fixtures for compatibility tests; and migration checkpoints before writing new formats. Downloaded release ZIPs are useful artifacts, but cannot replace source history.
Two independent backup plans
User-content backups protect boards. Source-code backups protect development. Both need a copy outside the local machine, controlled by their owner, plus a tested restore procedure. A checksum detects accidental changes; it does not encrypt or authenticate a file.