Invio v1.0.0.1.50.1

Invio v1.0.0.1.50.1 — Phase 1–4 Release-Readiness Certification Correction

Parent baseline

• Official parent: Invio v1.0.0.1.50.
• Parent Git commit: b87b412413f8788656c89b3b97a487d855d10d5f.
• Owner-uploaded Final Baseline SHA-256: 80825b8c2c780f5ecf3510e797c76f6cd5a018c14cde6924c32c6746c2f8bde5.

Confirmed acceptance evidence

GitHub Actions run 32109507918 executed the exact parent commit and completed successfully. Linux tests passed. Native Windows executed 642/642 tests PASS, including the Phase-4 Dynamic Tags V1 suite and current schema-v7 migration contracts. Wheel/P14 validation, native PySide6/keyring/resource smoke, Nuitka OneDir startup, protected-credential and Windows-native-TLS smokes, WiX MSI build/install/run/uninstall, P14 release-payload audit, and artifact upload all passed.

Corrections in this hotfix

• Synchronize current documentation/status from “candidate / CI pending” to the now-verified v1.0.0.1.50 acceptance state.
• Remove the tracked trailing whitespace from PATCH_MANIFEST_v1.0.0.1.50.md.
• Advance release identity only to application/wheel 1.0.0.1.50.1, PE 1.0.1.5001, MSI 1.1.5001, future tag v1.0.0.1.50.1.
• Add release-readiness verification/freeze records and current release contract coverage.

Frozen behavior

No production behavior is changed. Phase-1 native TLS trust and fail-closed certificate verification, Phase-2 provider fatal-limit circuit breaker, Phase-3 timeout/retry/delay/rate controls, Phase-4 Dynamic Tags V1, schema v7, provider/Odoo contracts, Task state machine, WorkerManager/QThread architecture, delivery ledger, CredentialStore, OAuth/Easy Onboarding, ProviderManager/IVX, application pages and unrelated UI/UX remain unchanged.

The Git tag is not created by this source correction. Exact v1.0.0.1.50.1 post-push non-tag CI remains the final gate before owner tag/release publication.

Invio v1.0.0.1.49.4

Invio v1.0.0.1.49.4 — Provider IVX Windows Security & Compatibility Correction

Frozen parent

Official parent baseline: Invio v1.0.0.1.49.3 Provider IVX Package System V1 replace-ready delta, SHA-256 416a03130f89dfff27204dbc22b32aaabdb05be24fef0fb53b3196ba163d26e7.

Verified defects corrected

1. Native Windows ZIP-name normalization could hide raw backslashes because the IVX validator inspected ZipInfo.filename; validation now uses ZipInfo.orig_filename before platform normalization.
2. ProvidersPage called the new provider_logo_path() method unconditionally, breaking the frozen legacy manager-collaborator runtime contract; plugin-logo lookup is now optional/additive.
3. Raw path aliases such as ./name and dir//name could normalize to the same extraction target; raw canonical spelling is now required.
4. Windows-unsafe filename components, including NTFS ADS-style : names, trailing dot/space and reserved device names, are rejected before extraction.
5. Unsupported ZIP compression could escape as raw NotImplementedError; it is now normalized to an IVX validation failure.
6. logo.png validation previously checked only the PNG signature. IVX now checks PNG chunk structure/CRC, positive dimensions and a 4096px-per-dimension ceiling before materialization; invalid logos remain non-fatal and use the host fallback.
7. The deterministic IVX builder previously published the final output before final archive validation. It now validates a temporary .ivx first and atomically publishes only after PASS.

Frozen boundaries

No Task state-machine, WorkerManager/QThread, delivery-ledger, database/schema/credential, External Adapter V1, Browser OAuth V1, Easy Onboarding V1, provider Task/send/API behavior, customer/template/report/settings behavior, MSI/WiX implementation, dependency stack or unrelated UI behavior changes.

Verification policy

The owner-supplied Windows v1.49.3 audit is authoritative evidence for the two original failures. v1.49.4 adds platform-independent regression coverage for both boundaries so Linux/CI source-contract runs do not hide them when PySide6 is unavailable. Native Windows and GitHub non-tag CI remain release gates.

Version mapping

• Application/tag: 1.0.0.1.49.4 / v1.0.0.1.49.4
• PE: 1.0.1.4904
• MSI: 1.1.4904
• Wheel: 1.0.0.1.49.4
• IVX Format: 1 unchanged

Final source verification

• Final repository audit: 532 discovered / 513 PASS / 19 SKIPPED / 0 FAIL / 0 ERROR.
• Targeted corrected IVX tests: 23/23 PASS.
• Current external provider companion suites: 42/42 PASS.
• Provider IVX deterministic rebuild comparison: 5/5 byte-identical to the v1.49.3 v1.2.0 artifacts.
• Wheel build: PASS; P14 wheel audit: 58 source modules / 12 exact runtime resources.
• Frozen critical architecture comparison: PASS.
• No TODO/FIXME/fake/demo/mock production endpoint marker was found in the corrected IVX scope/current external provider adapters.

The 19 skipped tests require PySide6, which is unavailable in the Linux delivery container. They are not counted as passes. Native Windows v1.49.4 and non-tag GitHub CI are required before tagging a release.

Invio v1.0.0.1.49.1

Invio v1.0.0.1.49.1 — Persistent Browser OAuth + MSI Launch Integration

Official Parent Baseline: Invio v1.0.0.1.49.

Browser OAuth

• Optional browser_auth interface v1 for trusted executable P13 provider bundles.
• System/default browser authorization; no embedded WebView dependency.
• Cryptographically random state, PKCE S256 when declared, strict redirect/state/callback validation, timeout and cancellation.
• Loopback callbacks for provider-supported desktop flows and validated one-time manual callback completion for providers that require production HTTPS redirect infrastructure.
• Provider organization/tenant/company/location discovery may populate a manifest-declared account credential.
• Browser auth never persists access tokens. Refresh/bootstrap credentials flow into the existing protected account credential store only when the user saves the account.
• Existing manual credentials and External Provider Adapter v1 task behavior remain compatible.

Persistent connection

After initial authorization and account save, provider adapters use the stored refresh token to obtain access tokens without repeated user login. Providers that rotate refresh tokens must save and use the latest token through protected OS storage. Reauthorization remains necessary only when the provider grant is revoked/expired, scopes change, or token persistence fails.

MSI

• Existing per-user %LOCALAPPDATA%\Vib Tools\Invio installation and UpgradeCode preserved.
• Adds Start Menu > Vib Tools > Invio pointing at installed Invio.exe.
• CI verifies shortcut target and shortcut removal after uninstall.
• Signing Option C: no Authenticode certificate/service is added; Unknown Publisher may remain.

CI correction

• Clean GitHub Actions checkouts intentionally do not contain the Git-ignored /project/ forensic workspace.
• The v1.49.1 repository truthfulness contract now validates tracked release evidence unconditionally and checks private baseline/root-cause records only when a full private /project/ workspace is present.
• No runtime, OAuth, MSI, provider, UI, storage, task, or business behavior changes are part of this correction.

Frozen boundaries

No Task state machine, WorkerManager, delivery ledger, database schema, invoice/customer/template/report business logic, provider send semantics, or unrelated UI redesign.

Version mapping: application/tag 1.0.0.1.49.1 / v1.0.0.1.49.1, PE 1.0.1.4901, MSI 1.1.4901, wheel 1.0.0.1.49.1.

Invio v1.0.0.1.49

Invio v1.0.0.1.49 — Provider/Settings Compact Header + Template/Reports Table Layout Fix

Official Parent Baseline: Invio_v1.0.0.1.48.9_Baseline.zip.

This is a UI-only correction. Provider and Settings headers are compacted without changing their controls or behavior. Invoice Templates and Reports retain all existing columns, records and values; table geometry/overflow handling is corrected without changing data representation or report logic.

Provider

• Providers + Load Provider remains the page header.
• Provider Catalog + Search providers... remains the section row with compact control height/width and reduced surrounding spacing.
• Provider cards, descriptions, status, version, Install/Uninstall and Load Provider callbacks are unchanged.

Settings

• Settings + Reset Settings + Save Changes remains the page header.
• Preferences + Search settings... remains the section row with compact search geometry and reduced surrounding spacing.
• All existing settings sections, controls and persistence callbacks are unchanged.

Invoice Templates

• Preserves TEMPLATE / CURRENCY / TYPE / DUE / ITEMS / TAX / ACTIONS and every row value.
• Keeps Edit/Delete callbacks.
• Corrects header alignment, expands the Actions column to safely contain its existing controls, and enables per-pixel horizontal scrolling as needed.

Reports

• Preserves all 9 Task Summary columns and all 11 Recipient Delivery History columns/values.
• Uses ResizeToContents with horizontal scrolling for wide report content instead of hiding/removing columns.
• Search/filter/pagination/export/clear-history behavior is unchanged.

Frozen boundaries

No provider API, ProviderManager, WorkerManager, storage/schema, authentication, task execution/state machine, data model, report-generation logic, validation or dependency changes.

Version mapping: application/tag 1.0.0.1.49 / v1.0.0.1.49, PE 1.0.1.49, MSI 1.1.49, Python package/wheel 1.0.0.1.49.

Invio v1.0.0.1.48.3

Invio v1.0.0.1.48.3

Scope

End-to-End CI/CD & Release Pipeline Forensic Audit and Stabilization over the owner-frozen Invio_v1.0.0.1.48.02_CL_FIx_Baseline.zip baseline.

GitHub failure evidence

GitHub Actions run 31516505105 checked out commit 5ff60fbcc82c0bfbdae7e0aa62a9912beb360069. Both test and windows-build reached the full regression audit. The Linux Qt dependency step succeeded and the four real PySide6 QApplication / QMessageBox.exec() / QTimer popup lifecycle tests passed on both operating systems. Both jobs then failed with the same repository-contract result: 443 tests executed, with 17 errors and 4 failures, all under tests/test_repository_contracts.py.

Root cause

project/ is intentionally private and Git-ignored. The previous v1.48.02 CI correction partially unignored /project/ plus four project/research/ROOT_CAUSE_VERIFICATION_*.md files. A public Actions checkout therefore contained a partial project/ directory. Existing historical repository-contract tests deliberately use if project_root.is_dir(): to run private-record assertions only in a full private baseline. Materializing a partial tree made those tests enter the private branch even though most required planning/specification/research files were absent, causing the 21 failures.

This is a regression of the public/private test boundary already established in v1.0.0.1.26; it is not an application runtime defect.

Correction

• restore /project/ to fully private/Git-ignored with no public-file exceptions;
• keep the existing historical repository tests conditional on complete private-baseline presence;
• change only the four newer v1.47.0/v1.48.0/v1.48.01/v1.48.02 private-record reads to the same conditional pattern;
• retain the existing compatibility test name while asserting that no project/ unignore exception is present;
• preserve the Linux Qt offscreen dependency installation and real PySide6 interaction tests;
• preserve the existing wheel, Nuitka OneDir, compiled keyring, WiX MSI, MSI lifecycle smoke, checksum, artifact upload and exact-tag release workflow.

Version mapping

• Application: 1.0.0.1.48.3
• Tag: v1.0.0.1.48.3
• PE: 1.0.1.4803
• MSI: 1.1.4803
• Python wheel: 1.0.0.1.48.3

Frozen behavior

No UI layout/color/popup semantic, runtime, Task state-machine, WorkerManager, provider, storage/schema, customer/invoice, Settings, dependency or business-logic change is included.

A new post-push GitHub Actions run remains required to certify the Windows Nuitka/MSI/artifact stages remotely; this local candidate does not fabricate that remote result.

Invio v1.0.0.1.40.2

Invio v1.0.0.1.40.2 - First Production Release

Status: PRODUCTION RELEASE ACCEPTED
Official Baseline: v1.0.0.1.40.2
P14: COMPLETE BY EXPLICIT OWNER PRODUCTION ACCEPTANCE
P11 Refrens: IMPLEMENTED / LIVE ACCEPTANCE DEFERRED — NON-BLOCKING FOR THIS RELEASE
Production-ready: YES, with Odoo Provider v1.0.0 as the owner-live-certified invoice delivery path

Production acceptance evidence

The owner completed a real Odoo live test from Invio using the validated external Odoo Provider v1.0.0 and confirmed successful invoice sending. This is the first owner-controlled end-to-end provider acceptance for Invio.

The v1.0.0.1.40.2 Windows CI/distribution pipeline is green. Before the final tag is created, the final plugin-inclusion commit must pass the same non-tag CI because this release additionally ships the validated Odoo bundle with the project.

Final plugin-inclusion CI checksum portability correction

The first non-tag CI run of the final plugin-inclusion commit (796895bdcef829b431e62876d87faed572e57cbf) failed only in test_odoo_bundle_internal_checksums_are_complete. The Odoo bundle checksum file was generated from LF source bytes, while the Windows Git checkout converted text files to CRLF, changing raw-byte SHA-256 values before the test ran.

The correction is intentionally limited to a repository attribute rule: providers/plugins/odoo/** text eol=lf. This preserves the existing raw-byte integrity contract across Windows/POSIX checkouts without changing the Odoo provider manifest, adapter, P13 interface, runtime logic, task execution, dependencies, workflow, or application version. A corrected non-tag CI run is required before the production tag is created.

Odoo provider included with the project

The validated external plugin is stored at:

providers/plugins/odoo/

It remains a P13 interface-v1 trusted external adapter. It is intentionally not auto-installed and does not become a packaged/reserved provider ID. Users explicitly load its provider.json and approve the sibling executable adapter.py through the existing trusted-code workflow.

The plugin provides:

• Odoo API-key authentication over the proven JSON-RPC workflow;
• customer lookup/create;
• currency/country resolution;
• customer invoice creation;
• invoice posting;
• Odoo Send & Print wizard email execution;
• provider-side mail evidence inspection;
• Invio P10 durable provider customer/invoice references;
• fail-closed uncertainty behavior for non-idempotent external mutations.

Provider certification matrix

Provider	v1.0.0.1.40.2 release status
Odoo Provider v1.0.0	LIVE END-TO-END ACCEPTED
Refrens	API Test + invoice creation work; API email returns HTTP 400: Not allowed to send mail; email delivery not certified
Agiled	API Test verified; Task sending fail-closed / not certified
Stripe	Existing implementation unchanged; no new owner-live acceptance claim is made by this release

Production phase interpretation

P14 is marked complete by explicit owner acceptance of the green Windows distribution path plus real Odoo invoice delivery. P11 remains a provider-specific Refrens acceptance item; the owner explicitly makes it non-blocking for this first production release rather than falsely marking Refrens email delivery successful.

Completed acceptance phases are therefore 13/14, with P11 deferred. This exception is intentional and recorded.

v1.40.2 provider-contract corrections retained

The pre-production v1.40.2 correction remains part of this released tree: Agiled API Test uses the owner-supplied safe read GET /public/v1/me with Bearer authentication, while Agiled Task sending remains fail-closed. Refrens HTTP 400: Not allowed to send mail remains classified as a provider-side API mail permission rejection rather than being converted to success.

Unchanged core contracts

• Application version remains 1.0.0.1.40.2.
• SQLite schema remains v5.
• WorkerManager one-QThread-per-active-Task architecture is unchanged.
• P05 immutable Task snapshots are unchanged.
• P08/P09/P10 retry, scheduling, durable-ledger and uncertainty rules are unchanged.
• P13 external adapter interface remains version 1.
• Stripe/Refrens/Agiled built-in runtime behavior is unchanged by this production-finalization step.
• No UI/UX or Settings update is included; those are future separately approved work.

Invio v1.0.0.1.38

Invio v1.0.0.1.38 — P14 WiX Debug-Symbol Release Inventory Correction

Status

• P11: IMPLEMENTED / LIVE ACCEPTANCE PENDING
• P14: CERTIFICATION PENDING
• Completed acceptance phases: 12/14
• Production-ready: NO
• SQLite schema: v5 unchanged
• Runtime dependencies: unchanged
• Provider send/business behavior: unchanged
• WorkerManager / Task architecture: unchanged
• UI/UX and page inventory: unchanged

Audited GitHub failure

GitHub Actions run 31386258538, Windows job 93447256779, checked out commit fca2da3e4bb6d19687f2c85f48911d7ade7501ba.

The Windows job passed the full 383/383 regression audit, workflow version mapping, wheel build/install, native PySide6/keyring/resource smoke, Nuitka OneDir build, portable preparation, compiled OneDir startup smoke, WiX 6.0.2 installation, MSI build, and MSI clean install/run/uninstall smoke.

Failure occurred in Assemble release payloads and checksums. WiX had emitted its default sibling debug-symbol file:

Invio_v1.0.0.1.37_windows_x64_setup.wixpdb

The checksum writer intentionally included every file in dist/release, producing four checksum entries. The distribution auditor intentionally accepts only the frozen release payloads: portable ZIP, MSI and wheel, plus SHA256SUMS.txt. The mismatch was therefore one unexpected .wixpdb sidecar, not four incorrect hashes.

v1.38 correction

The existing WiX build command now adds the documented -pdbtype none option. This prevents the debug .wixpdb sidecar from being emitted beside the MSI while leaving the MSI itself and all release topology unchanged.

The checksum writer and distribution auditor are deliberately unchanged so they continue to fail closed if any unexpected payload enters dist/release.

Certification truthfulness

The v1.37 run provides successful external evidence through MSI build and MSI install/run/uninstall, but it failed before final checksum audit and artifact upload. Therefore P14 remains CERTIFICATION PENDING. The exact pushed v1.38 Windows workflow must complete checksum audit and artifact upload successfully, and owner-controlled Stripe/Refrens live acceptance gates remain required before any production-ready claim.