publish-new-versionlisted

# Publish a New Public Version ## Overview One public repo, infrequent releases. This is the maintainer's **single entry point** to put the CURRENT folder state — **all features, none of the personal data** ��� onto the public GitHub repo as a clean, versioned update, and to **prove it actually landed**. It does NOT reimplement the privacy machinery; it runs the quality checks the maintainer cares about, then drives the local `security-github` skill (the depersonalized public-release privacy gate), then verifies. ## Context you must hold (the mental model) - **There is ONE project repo: the public flagship** `github.com/PersonalJarvis/PersonalJarvis`. The lowercase `personal-jarvis` (`origin`) is a silent private backup only — never the deliverable. - The local working tree **mixes shippable code with the maintainer's personal data** (config, API keys, Wiki/Vault, real name, `C:\Users\...` paths, machine ids). Personal data must **NEVER** reach the public repo — its history is world-readable forever. - Releases are **infrequent** (≈ every 2 weeks). Each one is a **complete snapshot since the last release**, not continuous pushing. The downloader gets the maintainer's whole folder minus the personal parts. ## Process — run in order; STOP on any failure ### 1. Pre-flight quality gate (what downloaders get must actually work) Verify each, **with evidence**, before anything is shipped: - **Completeness** — no half-built features in what ships. Scan the diff since