Move project documentation into docs

Add ARCHITECTURE.md with a Mermaid component interaction diagram and short descriptions of the main runtime flows. Move CHANGELOG.md and ROADMAP.md under docs/ so project documentation lives in one place, and update README links plus the project layout description.
2026-06-15 20:44:47 +03:00
parent 5ef32566db
commit e2464aab0f
4 changed files with 75 additions and 3 deletions
@@ -0,0 +1,69 @@
+# Roadmap
+
+This file tracks planned PySentry work that is larger than a single bug fix.
+
+## Project Rename
+
+Plan a rename from PySentry to GoSentry.
+
+Rename checklist:
+
+- Decide the final repository path and Go module path.
+- Update application name, window title, tray menu, and desktop integration text.
+- Update app ID and autostart entry names.
+- Rename build artifacts from `pysentry-*` to `gosentry-*`.
+- Decide whether runtime files should stay backward-compatible with existing
+  `pysentry.yaml`, `jobs.yaml`, and log directories or migrate to new names.
+- Update README, CHANGELOG, ROADMAP, build scripts, Docker image names, and
+  package metadata.
+- Consider a transition note for users with existing PySentry configuration.
+
+## Post-Field-Test Cleanup
+
+After real-world use confirms the main workflows, clean up temporary
+stabilization code and development scaffolding.
+
+Cleanup checklist:
+
+- Review and remove debug-oriented diagnostics that are no longer useful.
+- Remove excessive defensive checks once behavior is proven and covered by the
+  right tests.
+- Remove obsolete compatibility cleanup, such as old autostart migration code,
+  after the transition window is over.
+- Delete stale generated files and old build artifacts from local/release flows.
+- Revisit tests and remove ones that only lock in temporary implementation
+  details instead of real user-facing behavior.
+- Simplify README notes that were useful during early setup but are too noisy
+  for normal users.
+- Recheck `.gitignore`, Docker scripts, and packaging scripts for rules or
+  branches that only supported early experiments.
+
+## Delivery And Packaging
+
+Keep a single portable binary as the baseline delivery format. It is simple to
+test, easy to copy between machines, and matches the current storage model where
+runtime YAML files live next to the executable by default.
+
+Planned delivery variants:
+
+- Windows portable `.zip` with `pysentry.exe`, `README.md`, and `CHANGELOG.md`.
+- Linux portable `.tar.gz` archives for `linux-amd64` and `linux-arm64`.
+- Debian/Ubuntu `.deb` package once the Linux runtime paths are settled.
+- Windows installer later, likely Inno Setup first and MSI/WiX only if needed.
+- AppImage as a possible Linux GUI-friendly format after the core workflow is stable.
+- Flatpak only after the desktop integration story is clearer.
+- winget manifest after stable public Windows releases exist.
+
+Packaging design note:
+
+- Portable builds can keep settings and jobs next to the executable.
+- Installer/package builds should move runtime data to per-user locations:
+  `%APPDATA%\PySentry` on Windows, and XDG directories such as
+  `~/.config/pysentry` and `~/.local/share/pysentry` on Linux.
+
+Initial priority:
+
+1. Windows portable `.zip`.
+2. Linux portable `.tar.gz` for amd64 and arm64.
+3. Debian/Ubuntu `.deb`.
+4. Windows installer.