vibtools · victorsteele · Aug 27, 2026 · Aug 27, 2026
diff --git a/.github/SECURITY.md b/.github/SECURITY.md
@@ -1,22 +1,29 @@
 # Security
 
-## Provider credentials
+## Credential protection
 
-Invio `v1.0.0.1.11` stores provider credential values through the owner-approved Python `keyring` integration and requires an approved OS-protected backend. There is no plaintext-file fallback. The normal operational SQLite database stores only an opaque credential reference, and application settings remain non-sensitive.
+Invio stores provider credential values through Python `keyring` and requires an approved OS-protected backend. There is no plaintext-file fallback. The operational SQLite database stores only opaque credential references; ordinary application settings remain non-sensitive.
 
-If protected credential storage is unavailable, Account persistence fails closed. If a persisted credential entry is missing/unreadable at startup, the Account metadata is retained but the runtime Account is restored as `Not Verified`, so the existing P01 Task gates prevent execution.
+If protected credential storage is unavailable, Account persistence fails closed. If a persisted credential is missing or unreadable at startup, Account metadata remains visible but runtime state is downgraded to `Not Verified`, preserving the existing Task execution gates.
 
-Do not include provider secrets, exported logs containing sensitive customer data, or local per-user application databases in issues, pull requests, commits, screenshots, or diagnostic archives.
+## Transport and provider trust boundaries
 
-## Reporting security issues
+Provider HTTPS certificate and hostname verification remain mandatory. On Windows, the shared provider transport uses the native Windows trust store through `truststore`; certificate-verification failures are not silently bypassed.
+
+External executable provider adapters are trusted code. Invio validates the supported external-adapter/IVX contract and requires the existing explicit trust boundary before executable adapter use. Installing an external provider must not be treated as sandboxing untrusted Python code.
+
+## Privacy, logs, exports, and local data
 
-Use the repository's private/security reporting channel where available. Do not publish active provider credentials or customer data in a public issue.
+Recipient-level delivery reconciliation, structured privacy redaction, safe exports, and closed-history retention controls are implemented through the existing P10/P12 operational contracts. Do not include provider secrets, unredacted customer data, local application databases, protected credential material, or sensitive exported logs in public issues, pull requests, commits, screenshots, or diagnostic archives.
 
-## Current boundary
+## Windows release signing
 
-P02 protects credential persistence. Recipient-level delivery reconciliation, generalized PII/log redaction, and full live/native security certification are later production roadmap phases and are not claimed by this release.
+The current Windows distribution follows owner-approved Signing Option C and may be unsigned, so Windows can display `Unknown Publisher`. This is a documented distribution boundary, not a claim of Authenticode verification. Use the release checksum asset when verifying downloaded release files.
+
+## Reporting security issues
 
-P03 verification error summaries are scrubbed against the Account credential values before durable storage.
+Use the repository's private/security reporting channel where available. Do not publish active provider credentials, customer data, authorization codes, refresh tokens, local databases, or other sensitive operational evidence in a public issue.
 
+## Current security boundary
 
-`v1.0.0.1.11` additionally persists a fail-closed `Not Verified` downgrade when protected credentials are missing/unreadable and stages Account Edit with a durable `Not Verified` safety marker before crossing the SQLite/keyring boundary. Migration backups use SQLite backup semantics so committed WAL state is not omitted.
+The current release combines OS-protected credential persistence, fail-closed credential recovery, mandatory TLS verification, privacy-redacted operational logging/export controls, and explicit trusted external-provider execution boundaries. These controls reduce repository and runtime exposure but do not make third-party providers, provider credentials, user endpoints, or unsigned binaries inherently trusted.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -4,8 +4,9 @@
 - Records the native Windows full regression result from that clean GitHub checkout: **642/642 PASS**, including Phase-4 Dynamic Tags tests and the current schema-v7 migration contracts.
 - Records successful wheel/P14 audit, native PySide6/keyring/resource smoke, Nuitka OneDir startup, protected-credential and Windows-native-TLS smokes, WiX MSI build/install/run/uninstall, release-payload audit, and artifact upload.
 - Removes one tracked trailing-whitespace defect from the historical v1.0.0.1.50 patch manifest.
-- Synchronizes the release identity to application/wheel `1.0.0.1.50.1`, PE `1.0.1.5001`, MSI `1.1.5001`, and future tag `v1.0.0.1.50.1` using the existing six-part hotfix mapping.
+- Synchronizes the release identity to application/wheel `1.0.0.1.50.1`, PE `1.0.1.5001`, MSI `1.1.5001`, and tag `v1.0.0.1.50.1` using the existing six-part hotfix mapping.
 - No Phase-1 TLS, Phase-2 provider circuit-breaker, Phase-3 sending-control, Phase-4 Dynamic Tags, provider, storage-schema, Task/WorkerManager, credential, OAuth/IVX, or UI/UX behavior changes are introduced.
+- Records that tag/release `v1.0.0.1.50.1` was published on 2026-08-18 with wheel, Windows portable ZIP, Windows MSI and release checksum assets.
 
 ## v1.0.0.1.50 — Deterministic Dynamic Tags V1
 

diff --git a/README.md b/README.md
@@ -1,22 +1,24 @@
-## Current release-readiness baseline — v1.0.0.1.50.1
+## Current authoritative state — v1.0.0.1.50.1
 
-`v1.0.0.1.50.1` is a maintenance-only release-readiness synchronization over the owner-frozen `v1.0.0.1.50` Phase-4 baseline. The exact parent commit `b87b412413f8788656c89b3b97a487d855d10d5f` passed GitHub Actions run `32109507918`: Linux and Windows jobs were green, Windows executed **642/642 tests PASS**, and the complete wheel → Nuitka OneDir → protected credential/TLS smoke → WiX MSI → P14 release-payload → artifact-upload chain passed. Phase 1 through Phase 4 runtime behavior remains frozen; this hotfix only closes release-record/status drift, one tracked Markdown trailing-whitespace defect, and current version/release metadata.
+Invio `v1.0.0.1.50.1` is the current published product release. The release was published on 2026-08-18 after the Phase-4 release-readiness chain completed successfully. Application/wheel version remains `1.0.0.1.50.1` and operational SQLite remains schema **v7**.
+
+Subsequent repository-maintenance Phase-01 (F-001/F-002) and Phase-02 (F-003/F-004) corrected source-audit, CI source-only, checksum-lifecycle and workspace/source-provenance defects without changing application runtime, providers, UI/UX, schema, version, build artifacts, or the published release. Historical sections below describe the state of their named versions at that time; they are not alternate current baselines.
 
 ## Accepted Phase-4 baseline — v1.0.0.1.50
 
 Invio v1.0.0.1.50 implements the owner-approved **Deterministic Dynamic Tags V1** scope over the CI-verified v1.0.0.1.49.9 baseline. Supported exact tags are `#NAME#`, `#EMAIL#`, `#R5#`, `#R11#`, `#DATE#`, `#DATE-NAME#`, and `#YAAR#`. Unknown tag-like text remains literal. Date values are frozen from the Task-creation UTC reference; deterministic numeric tags are stable for the same Task+recipient through retry, Resume Remaining, Retry Failed, and restart recovery. Rendering is limited to Settings Default Customer Name provenance plus Invoice Template Memo, Footer, Customer Note, Terms, and Item Description. Recipient email is never changed.
 
 Phase 4 advances operational storage additively from schema v6 to **schema v7** so Settings-default dynamic-name provenance and the immutable Task Dynamic Tags version/UTC reference survive restart. Existing v6 Customer/Task rows migrate with Dynamic Tags disabled, preserving pre-Phase-4 literal behavior for already captured executions. No new UI page, preview workflow, provider-specific hidden tags, provider API capability, WorkerManager architecture, TLS behavior, Phase-2 circuit breaker, or Phase-3 scheduling behavior is introduced. GitHub Actions run `32109507918` passed on exact commit `b87b412413f8788656c89b3b97a487d855d10d5f`, including native Windows **642/642 PASS** and the complete Windows distribution chain.
 
-## Current baseline candidate — v1.0.0.1.49.9
+## Historical baseline candidate — v1.0.0.1.49.9
 
 v1.0.0.1.49.9 is a narrow Windows CI correction over the accepted Phase-3 implementation. GitHub Actions run `32097949119` proved the Linux job and all Phase-3 runtime/UI tests green; the Windows job failed only because the new schema-v5→v6 migration test fixture left its own SQLite connections open until temporary-directory cleanup. The fixture now explicitly closes those test connections. Production `DomainStore`, SQLite schema v6, Sending & Retry controls, provider rate ceilings, Phase-1 TLS, Phase-2 fatal-limit semantics, WorkerManager/QThread ownership and all provider/UI workflows remain unchanged.
 
-## Current baseline candidate — v1.0.0.1.49.8
+## Historical baseline candidate — v1.0.0.1.49.8
 
 Phase 3 adds bounded Sending Scheduler / Retry / Delay controls without changing provider business payloads, Phase-1 TLS trust, Phase-2 fatal-limit circuit-breaking, WorkerManager/QThread ownership, or Dynamic Tags. New Tasks freeze their sending controls into the immutable execution snapshot and SQLite schema v6 persists those controls across restart. Defaults preserve v1.49.7 behavior: 30-second Task network timeout, three total automatic attempts, zero additional recipient delay, Stripe 20 requests/second/account, Refrens 1 request/second/account, and no invented Odoo numeric scheduling policy. Provider `Retry-After`, internal retry taxonomy/backoff/jitter/cooldowns and non-idempotent no-blind-replay rules remain authoritative.
 
-## Current baseline candidate — v1.0.0.1.49.7
+## Historical baseline candidate — v1.0.0.1.49.7
 
 v1.49.7 corrects only the verified GitHub Actions P14 release-audit false negative from the v1.49.6 Windows build. Nuitka successfully compiled and executed the native `truststore` TLS backend in both OneDir and MSI smoke tests, but the final portable audit incorrectly required the original `Invio/truststore/__init__.py` source file. The audit now checks only stable portable resources while executable smoke gates remain the runtime proof. Phase-1 TLS and Phase-2 provider-limit behavior remain unchanged.
 

diff --git a/ROADMAP.md b/ROADMAP.md
@@ -1,6 +1,8 @@
-## Release readiness — v1.0.0.1.50.1
+## Current authoritative roadmap state — v1.0.0.1.50.1
 
-Phase 4 Deterministic Dynamic Tags V1 in `v1.0.0.1.50` is now CI-accepted on exact commit `b87b412413f8788656c89b3b97a487d855d10d5f` by GitHub Actions run `32109507918`. The run passed Linux tests, native Windows **642/642** regression, wheel/P14, PySide6/keyring/resource smoke, Nuitka OneDir, credential/TLS smokes, WiX MSI lifecycle, release-payload audit, and artifact upload. `v1.0.0.1.50.1` does not reopen any functional phase; it synchronizes release readiness and version identity only.
+Invio `v1.0.0.1.50.1` is the current published product release (published 2026-08-18). Phase 1–4 runtime behavior remains accepted/frozen, operational SQLite is schema **v7**, and the published release lineage remains unchanged. Repository-maintenance Phase-01 (F-001/F-002) and Phase-02 (F-003/F-004) were completed afterward as non-functional source/repository corrections; they do not advance the product roadmap or change runtime behavior.
+
+All version-specific sections below are historical planning/acceptance records for their named versions. Terms such as “candidate”, “baseline”, or “next phase” inside those records describe their point-in-time state and are not current roadmap status.
 
 ## Phase 4 — Deterministic Dynamic Tags V1 — v1.0.0.1.50 ACCEPTED BASELINE
 
@@ -72,35 +74,35 @@ The approved Accounts-page **Compact Flat Account Table & Semantic Status UI** i
 
 The approved Tasks-page New Task modal compact UI redesign is the only v1.0.0.1.48.4 scope. It does not introduce a new production phase or alter the existing provider/task/storage roadmap.
 
-## Current CI/CD Stabilization Candidate — v1.0.0.1.48.3
+## Historical CI/CD Stabilization Candidate — v1.0.0.1.48.3
 
 Parent Official Baseline: `Invio_v1.0.0.1.48.02_CL_FIx_Baseline.zip`. Scope is limited to GitHub CI/test/build/release stabilization and required version/documentation synchronization. The correction restores the established public/private repository-contract boundary; it does not advance production phases or modify application behavior. A post-push GitHub Actions run remains the authoritative Windows OneDir/MSI/artifact confirmation gate.
 
-## Current Hotfix Candidate — v1.0.0.1.48.02
+## Historical Hotfix Candidate — v1.0.0.1.48.02
 
 Parent Official Baseline: `v1.0.0.1.48.01`. Scope is limited to the global app-owned `QMessageBox` / popup lifecycle regression and real PySide6 interaction regression coverage. Production/provider roadmap ordering and business/runtime phase status are unchanged.
 
-## Current Hotfix Candidate — v1.0.0.1.48.01
+## Historical Hotfix Candidate — v1.0.0.1.48.01
 
 Parent Official Baseline: `v1.0.0.1.48.0`. This candidate fixes only the Tasks `Close Task` confirmation boundary. Production/provider roadmap ordering and phase status are unchanged.
 
-## Current UI Candidate — v1.0.0.1.48.0
+## Historical UI Candidate — v1.0.0.1.48.0
 
 Parent Official Baseline: `v1.0.0.1.47.0`. This candidate is limited to custom Main/Dialog chrome spacing, app-owned dialog visual separation and duplicate dialog-title cleanup. Runtime/provider/business roadmap ordering is unchanged.
 
-## Current UI Candidate — v1.0.0.1.47.0
+## Historical UI Candidate — v1.0.0.1.47.0
 
 Parent Official Baseline: `v1.0.0.1.46.0`. This candidate is limited to the owner-approved Vib Tools desktop design-system refinement. Runtime/provider/business roadmap ordering is unchanged.
 
-**Current owner-frozen baseline:** `Invio v1.0.0.1.45.0`. **Active approved UI candidate:** `v1.0.0.1.46.0 — custom Main Window and app-owned Dialog title bars only`. Provider/runtime roadmap status is unchanged.
+**Historical owner-frozen baseline at that point:** `Invio v1.0.0.1.45.0`. **Historical approved UI candidate:** `v1.0.0.1.46.0 — custom Main Window and app-owned Dialog title bars only`. Provider/runtime roadmap status is unchanged.
 
 # Roadmap
 
-**Current owner-frozen UI baseline:** `Invio v1.0.0.1.44.0`. **Active approved UI candidate:** `Invio v1.0.0.1.45.0 — Providers Page transient-window/card-layout fix only`. Production/runtime phase status is inherited unchanged; this UI candidate does not reopen or advance any provider/runtime phase.
+**Historical owner-frozen UI baseline at that point:** `Invio v1.0.0.1.44.0`. **Historical approved UI candidate:** `Invio v1.0.0.1.45.0 — Providers Page transient-window/card-layout fix only`. Production/runtime phase status is inherited unchanged; this UI candidate does not reopen or advance any provider/runtime phase.
 
-Current owner-frozen Official UI Baseline: **Invio v1.0.0.1.41 — Providers Page UI/UX baseline**. The first production-release lineage remains rooted in v1.0.0.1.40.2.
+Historical owner-frozen Official UI Baseline at that point: **Invio v1.0.0.1.41 — Providers Page UI/UX baseline**. The first production-release lineage remains rooted in v1.0.0.1.40.2.
 
-Active approved UI candidate: **Invio v1.0.0.1.41.1 — Providers Page final UI polish only**. Production/runtime phase status remains inherited unchanged; this hotfix does not reopen or advance any provider/runtime phase.
+Historical approved UI candidate: **Invio v1.0.0.1.41.1 — Providers Page final UI polish only**. Production/runtime phase status remains inherited unchanged; this hotfix does not reopen or advance any provider/runtime phase.
 
 Owner acceptance on 2026-08-10 records a successful real Odoo end-to-end invoice delivery path through the frozen P13 external-provider contract and accepts the green Windows distribution pipeline as the P14 native packaging gate. **P14 is COMPLETE by explicit owner production acceptance.** P11 remains the separate Refrens-specific live acceptance phase and is **IMPLEMENTED / LIVE ACCEPTANCE DEFERRED (non-blocking for v1.0.0.1.40.2)** because Refrens API mail is rejected by the provider with `HTTP 400: Not allowed to send mail`.