# Staff platform validation

Updated locally on 2 October 2026. This is a development milestone, not a production release.

| Check | Result |
| --- | --- |
| Clean dependency install (`npm ci`) | Passed |
| Web and mobile TypeScript checks | Passed |
| Next.js production compilation | Passed |
| iOS and Android Hermes bundle exports | Passed for both platforms |
| Backend tests | 180 passed |
| Chrome browser tests | 39 passed |
| Shared web/mobile input contracts | 8 passed |
| npm dependency audit | 0 known findings after the attachment dependencies were installed on 26 September |
| Desktop and 390px-wide web screenshots | Visually reviewed |

Backend coverage includes hashed/expired/revoked sessions, role checks, account creation, duplicate emails, company persistence, audit entries, search escaping, stale edits, archive counts, input validation, disabled users, login throttling and password whitespace. Browser coverage includes login, create/edit/reload persistence, activity, HttpOnly cookies, logout, read-only permissions, narrow-screen navigation, overflow and cross-origin rejection. Trading checks include owned stock/offer/wanted entry, exact and near matches, decimal price differences, no implicit FX, expiry and review status, archived companies, changed company relationships, role restrictions, conflicting edits and shared record visibility. Shared input checks cover calendar validation, exact price text and preserving an existing expiry timestamp. The incremental preview migration preserved existing staff/company counts after a database backup. Tests use isolated local databases and never send messages or use live hosting credentials.

The mobile build tooling's `xcode` dependency uses UUID v4. The root override pins UUID 11.1.1 to address GHSA-w5hq-g745-h8pq; clean installation, UUID generation and both platform exports were verified. npm 11's `npm ls` still marks the upstream xcode range as invalid despite applying the override. This diagnostic is distinct from successful installation and the clean audit; recheck compatibility when upgrading Expo.

Catalogue checks cover administrator-only writes; normalized duplicate prevention; archived duplicates; search, restore and stale versions; immutable definitions; canonical server values; partial/wrong-kind references; archived selection restrictions; legacy record preservation, explicit linking and matching behavior. A migration test upgrades the previous schema and checks every old trading field and password hash. Browser tests cover catalogue creation, duplicate errors, archive/restore, trading selection and read-only browsing at 390px width. Catalogue screenshots were visually reviewed. The existing preview database was backed up before upgrade; every value in every pre-existing business table and the preview credential file was verified unchanged afterward. No catalogue entries or inferred links were added to the preview.

The Python tests currently emit a Starlette deprecation notice about its httpx-based test client. All assertions pass; this test-tool migration should be handled with a future dependency update.

Inventory tests cover IMEI checksum/format, global primary/secondary uniqueness, role restrictions, lot capacity, retirement, hold/release/allocation, duplicate actions, expired-hold reassignment, active customer checks, matching availability, remaining demand, deadline bounds, immutable history and protected trading edits. File-backed SQLite tests with independent connections verify one successful reservation when two requests compete for one device and when separate lots compete for one remaining wanted unit. Browser tests perform registration, release, allocation confirmation, retirement and viewer access at 390px width. Shared contract checks ensure inventory response metadata is excluded when saving a trading form. The preview inventory migration was preceded by a database backup and followed by comparison of every pre-existing table value and the credential file; all were unchanged. New inventory tables remained empty. SQLite foreign-key checking and Alembic schema comparison passed. The corrected desktop and narrow-screen inventory layouts were visually reviewed. No PostgreSQL server was available locally; PostgreSQL contention tests remain pending.

Device-care checks cover administrator-only corrections/receipts/inspection, trader transfer restrictions, identifier validation and conflict rollback, historical aliases, original reservation snapshots, lot capacity, persistent zero availability after the last device leaves, partial/full returns, quarantine, inspection/retirement, stale requests, new allocations after returns, and a transfer-versus-reservation race using independent SQLite connections. A populated migration test preserves all old columns and allocations and verifies backfilled IMEI snapshots. Browser tests exercise receipt, secondary IMEI correction, reclassification and inspection, plus read-only details at 390px width. Web/native TypeScript checks, the production web build and both native bundle exports passed. Device-care screenshots were visually reviewed. The local preview upgrade was backed up first; every pre-existing table value and the credential file were verified unchanged, with no maintenance events inferred. SQLite foreign-key checks and Alembic schema comparison passed after migration.

Private evidence checks cover authenticated reads, viewer upload/archive rejection, Unicode filenames, original-byte downloads, retry deduplication and conflicting retry payloads, invalid/empty files, image type mismatch, encrypted and active PDFs, claimed and streamed upload size limits, parent scope, pagination, quotas, archive/restore versions and retained originals, storage failure cleanup, corrupt/missing-file responses, and device evidence surviving a transfer. Two-connection SQLite tests verify competing uploads cannot exceed the active quota and identical concurrent retries produce one record. Browser tests verify upload/download/archive/restore, malformed-file errors, unauthenticated and cross-origin rejection, and viewer access at 390px width. Both attachment screenshots were visually reviewed. Web/native type checks, the web production build and both Hermes exports passed after the new picker/filesystem/sharing packages were installed. The attachment milestone had 62 passing tests (46 backend, 13 browser, 3 contracts). The preview migration to `1d37ee1468d3` followed a private SQLite backup; every value in every pre-existing table and the preview credential bytes remained unchanged. The new attachment table is empty in the preview. Foreign-key and Alembic schema checks passed. The API snapshot and local development database are updated.

The attachment tests additionally emit a pypdf deprecation notice for the intentionally unsafe JavaScript fixture generator; active PDFs are rejected by the upload validation. Real malware scanning is not implemented. Filesystem crash recovery, coordinated file/database backup restores, native picker/permission/share-sheet behavior and actual PostgreSQL contention require validation before a hosted pilot. See ATTACHMENTS.md.

Reviewed-import validation adds 10 backend tests for non-mutating previews, exact decimal storage, whole-file row errors, source values, CSV/XLSX parsing, workbook restrictions and limits, role/owner checks, supplier/customer scope, retry deduplication, duplicate warning acknowledgement, identical batch protection, stale references, expiry, rechecks, cancellation, mid-batch database rollback and concurrent confirmation using separate SQLite connections. The full backend suite passes 56 tests. Browser coverage adds template download, invalid-row blocking, reviewed draft creation, idempotent confirmation/history, supplier selection, warning acknowledgement and viewer history at phone width. The full browser run passed the existing 13 tests and two new tests; an exact-label issue in the remaining supplier-import flow was fixed, then all three import tests passed together. This gives **75 passing tests** across 56 backend, 16 browser and 3 shared-contract tests. The adjusted import dialog layouts were visually inspected on desktop and 390px width. Web/native TypeScript checks, the production web build, both Hermes bundle exports and Python dependency consistency checks passed.

Migration `40ac5692f4a0` was applied to the preview only after a private backup. Every pre-existing table value and the preview credential file were verified unchanged; import history remained empty. Foreign-key and Alembic schema comparisons passed. The development database and OpenAPI snapshot were updated. Real PostgreSQL runtime/concurrency checks, representative supplier-file trials, native picker behavior, malware scanning and signed-device testing remain pending. The import source bytes are not retained; parsed row values, file hash, review results and record provenance are retained. See IMPORTS.md.


Warehouse validation adds six backend tests covering roles, unique codes, search escaping, archive/restore versions, initial physical confirmation, in-transit matching/reservation exclusion, blocked correction/lot transfer/retirement/inspection, source/destination archive guards, per-location device lists, stale and duplicate receipt, quarantined dispatch/return-to-origin, preserved original IMEI history, pagination and independent stock-lot movement. A two-connection SQLite dispatch-versus-reservation race permits one winner. A populated previous-schema migration preserves every old column and allocation, introduces no inferred location and passes foreign-key checks. The inspection test found and fixed a path that allowed inspection of quarantined devices in transit.

The full suite now passes **83 tests: 62 backend, 18 Chrome browser and 3 shared-contract tests**. Browser tests cover warehouse creation, initial assignment, dispatch and receipt, blocked archive during transit, restored availability, viewer incoming-device history at 390px width and server-side viewer rejection. Explicit accessible names were added to the warehouse selects after the initial browser checks. Web/native type checks, the Next production build and both native Hermes exports pass. Desktop and narrow-screen warehouse views were visually inspected; the heading styling was aligned with the existing device-care view.

Preview migration `4590e182b3e6` was applied after a private backup. Every pre-existing business-table value and the preview credential bytes stayed unchanged. Warehouse and movement tables remain empty until staff enter real locations. SQLite foreign-key and Alembic schema comparisons pass; the development database and OpenAPI snapshot are updated. See WAREHOUSES.md for physical attestation, customer-return location and fulfillment limitations. Actual PostgreSQL contention, native device operation, signing and deployment remain pending.


Shared-inbox validation adds six backend tests for manually recorded email limits, per-staff creation retries, conflicting retry content, role enforcement, limited assignee discovery, active company/staff selection, filtered lists, retained assignment/company changes, unavailable assignees, draft revisions/clearing, close/reopen behavior, stale edits and history pagination. An independent-connection SQLite race permits only one draft save at a given conversation version. A populated migration preserves all previous columns and introduces no conversations.

There are now **91 passing tests across 68 backend, 20 Chrome browser and 3 shared-contract tests**. The full browser run passed the existing 18 tests and the new viewer test; the remaining inbox editor test exposed an unstable textarea label after a value was saved. Explicit accessible names fixed it, and both inbox tests then passed together. Browser coverage verifies manual recording, literal HTML display without execution, company linking, assignment, shared drafts, server-side conflicts, retention of local text during reload, explicit discard handling, close/reopen, absence of a send endpoint, cross-origin rejection and read-only phone-width browsing. Desktop and 390px inbox screenshots were visually inspected. Web/native TypeScript checks, both Hermes exports and the production web build passed.

Migration `bb8573e901e2` was applied to the local preview after a private backup. Every old table value and the preview credential bytes were compared and preserved. Both conversation tables remain empty until staff record real correspondence. Foreign-key and Alembic schema comparisons passed, and the development database/OpenAPI snapshot were updated. Mailbox sync, email transport, automatic extraction, WhatsApp and real delivery testing are not part of this milestone. The native inbox still needs simulator/physical-device testing, and PostgreSQL contention remains a pilot gate. See INBOX.md.

## Incoming mailbox validation

The suite now has **107 passing tests: 82 backend, 22 Chrome browser and 3 shared-contract tests**. Fourteen new backend cases cover new-only activation and refusal to reset, disabled/no-network behavior, source metadata, sender/reference threading, reopening without changing drafts, exact-byte duplicates, skipped messages, per-message checkpoints across failure, exponential retry/five-failure stop, explicit retry, pause/lease revocation, stale administrator controls, read-only permissions and secret redaction, identity/UIDVALIDITY/owner changes, bounded batches/gaps, expired worker recovery, MIME/plain/HTML parsing, attachment names, text limits, verified TLS/read-only/partial PEEK behavior and populated migration preservation. An independent-connection SQLite test demonstrates that a second worker cannot claim the active lease and pausing during a network fetch prevents its later import. Owner revocation during fetch also prevents import.

The complete browser suite passed. The two mailbox cases passed again after the final attachment-label clarification. These tests use a fake mailbox adapter and test-only credentials on an isolated database; no real mailbox is contacted. They exercise genuine API/database source records, import/skip history, original-mail metadata, administrator pause/resume/request controls, persistence after reload, and viewer access/denial at 390px. Desktop and phone-width screenshots were visually inspected. Web/native type checks, the production web build and both Hermes exports pass.

Preview migration `0144d5c97475` followed a private SQLite backup. Every old business-table value and the preview credential bytes stayed unchanged. The new mailbox tables are empty; no account was activated. Foreign-key and Alembic schema comparisons passed. The development database and OpenAPI snapshot are updated. Live authentication/receiving tests, PostgreSQL contention and native hardware checks remain pending. No outgoing mail, mailbox flags, deletion or moves are implemented. Attachment bytes are discarded after MIME processing; filenames and warnings are retained. See MAILBOX.md for setup and limits.

## Email-to-trading review validation

There are **118 passing tests: 90 backend, 25 Chrome browser and 3 shared-contract tests**. The complete backend run passed 89 tests; all eight email-review cases then passed with the added imported-mail integration case. The complete browser run passed 24 tests; the three email-review cases then passed with the added stale-review/discard case. Web/native type checks, Next production compilation and both native Hermes exports passed.

New backend coverage checks manual and simulated-IMAP sources, draft-only offer/wanted creation, canonical catalogue values, explicit review, active company relationships, role/source-kind/scope enforcement, decimal precision, bidirectional source links, immutable review snapshots after edits, idempotent retries, changed-content retries, duplicate item numbers, multiple items, stale/closed conversations, atomic failed validation and previous-schema migration preservation. Two independent SQLite connections competing to review one email create exactly one trading draft and one source link. No live mailbox connections or outgoing messages are used.

Browser tests exercise catalogue/company selection, confirmation tied to reviewed values, offer and wanted creation, duplicate rejection, opening linked records, preservation of original values after edits, source HTML displayed literally, viewer/source visibility at 390px, viewer and cross-origin mutation denial, and stale-review value retention with explicit discard handling. Desktop and phone-width screenshots were inspected. The existing React/Next patterns were reviewed for hook ordering, cleanup, role guards and accessible controls.

Migration `e72b7ce57908` was applied after a private preview backup. Every pre-existing business-table value and the preview credential bytes were compared and preserved; no source links were inferred. Foreign-key and Alembic schema checks passed. The development database and OpenAPI snapshot were updated. Live email testing is explicitly deferred at the user's request. Native hardware/simulator operation and PostgreSQL runtime/contention checks remain pending. See EMAIL-TRADING.md.

## AI-assisted email extraction validation

There are **131 passing tests: 100 backend, 27 Chrome browser and 4 shared-contract tests**. The complete backend and browser suites passed. The populated migration test was then strengthened to include an existing email-to-trading review and passed again. Web/native TypeScript checks, the Next production build and both iOS/Android Hermes bundle exports passed. Desktop provenance and 390px queued-review screenshots were visually inspected.

Ten new backend cases cover role/source enforcement, disabled/no-network behavior, queue caching, exact local catalogue resolution, strict response/evidence validation, decimal and word boundaries, provider request/schema settings, sanitized errors, refusals/incomplete/oversized outputs, daily limits, explicit retries, lease expiry, requester revocation, preserved human corrections and previous-schema data/provenance preservation. Independent SQLite connections show that a second worker cannot issue a duplicate provider request while the first holds the lease. A shared-contract case verifies that applying incomplete suggestions clears unsupported defaults and preserves explicit company/notes/expiry values.

Two new browser cases exercise ready suggestions, source evidence, catalogue prefill, missing-currency blocking, invalidated confirmation, corrected quantity, draft-only creation, retained AI provenance, durable queue status after leaving/reopening and viewer rejection. Browser fixtures use the real worker state transitions with a simulated provider function; the standalone worker is never launched by the browser suite, and no OpenAI requests are issued. An initial browser setup error was fixed by adding the required creator to the test supplier before the successful full run.

Migration `398f72f2f7de` was applied after a private SQLite preview backup. Every pre-existing business-table value and the preview credential bytes were verified unchanged. The extraction table remains empty in the preview, and foreign-key/Alembic schema checks passed. The development database and OpenAPI snapshot were updated. Existing PHP site files and credentials remain separate.

The preview has no configured AI key/model. Live model compatibility, real extraction accuracy, representative supplier-language evaluation and production PostgreSQL contention remain unverified. Exports do not establish native hardware behavior. Live email tests remain deferred at the user's request. See AI-EXTRACTION.md for private setup, data boundaries, limits and worker operation.

## Local open-weight model validation

There are **141 passing automated tests: 109 backend, 28 Chrome browser and 4 shared-contract tests**. All full suites passed. Web/native TypeScript checks, Next production compilation and both native Hermes exports passed. Local-provider evidence views were visually inspected on desktop and at 390px width. The React review retained the existing component/hooks structure and accessible controls.

New backend cases verify key-free local configuration, loopback-only destinations, absence of authorization headers/tools, metadata checks before sending message content, cloud/missing-model rejection, response-size and input-byte limits, sanitized failures, no automatic retries, provider disclosure confirmation, pinned queues across configuration changes, local-provider review provenance with human edits and previous-schema OpenAI job preservation. Browser tests verify the local destination/provider label, evidence display, missing values and applying local suggestions; the entire suite runs with local-provider API configuration while retaining old OpenAI cached-result coverage. Automated tests use mocked model responses.

Separately, the actual downloaded Qwen3 4B model passed six synthetic examples through the production local adapter and validator. Cases cover complete details, missing fields, two items, non-trading text, an instruction embedded in the body and a lot total that must not become a unit price. The first exploratory call exposed a decimal-formatting omission; clearer local numeric instructions resolved it before the six-case run. Timings were 0.5–14 seconds on an Apple M5 with 16 GiB memory. These cases informed prompt development and are not held-out production accuracy evidence. The opt-in evaluator and private report are documented in LOCAL-AI.md. No real mailbox was contacted, no commercial message was sent and no fine-tuning occurred.

Migration `ca617294ce01` followed a private preview backup. All pre-existing column values and the preview credential bytes were preserved; old extraction jobs gain the OpenAI provider label. Foreign-key and Alembic schema checks passed, and the development database/OpenAPI snapshot were updated. The existing local preview is now configured for Ollama/Qwen with its worker running. Model files remain ignored under `.local/ollama-models`; cloud mode is disabled and the model server binds to loopback port 11435. Restart instructions are in LOCAL-AI.md.

Real supplier examples, longer/multilingual layouts, cold-start/load testing, held-out evaluation, any later fine-tuning, native hardware operation and hosted PostgreSQL/model deployment remain to be validated. Staff continue confirming every draft. Live email testing remains deferred.

## Reviewed learning validation

There are **162 passing automated tests: 128 backend, 30 Chrome browser and 4 shared-contract tests**. The full backend and browser suites passed. Web/native TypeScript checks, Next production compilation and both iOS/Android Hermes exports passed. Learning review dialogs were visually inspected on desktop and at 390px width. Native device operation is still unverified.

Backend coverage adds automatic candidate capture/creation-retry deduplication, manual-review exclusion, administrator permissions, exact source/evidence and byte bounds, contact guards, confirmation, version conflicts, approved edits, immutable holdouts, retirement, active approver eligibility, conversation/copied-content exclusion, bounded selection and exact prompt snapshots. Local worker tests verify the default-off flag, complete OpenAI exclusion and failure when a selected example is retired/edited or its approver is disabled/demoted during generation. Prompt tests use the real local adapter with an HTTP mock; they make no model calls.

Evaluation tests cover correct/missing/wrong/unsupported field counts, numeric equality, item count errors, null denominators, partition isolation, all-holdout-conversation exclusion and actual demonstration-size trimming. An explicit run against an isolated database with no holdouts was verified to make no model requests, write no report and leave database bytes/directory unchanged. The evaluator has no model promotion or weight-training path.

Browser tests verify candidate capture from AI-assisted review, unsupported-label rejection without losing input, invalidated confirmation, approved edits/history, stale/cross-origin rejection, retirement, frozen evaluation values and administrator-only access at phone width. The shared contracts and existing workflows remain passing.

Two separate live local calls used synthetic data only: baseline and one checked demonstration, with changed quantity, price and color in the new input. Exact expected-field comparison scored baseline 9/10 and assisted 10/10, in 23.6 and 16.1 seconds respectively. This is a single prompt-development integration check, not an independent business accuracy benchmark. The private summary contains metrics rather than source text. No live emails, outgoing messages, fine-tuning or business training runs occurred.

Migration `7915a1de337c` followed a private preview backup. Every pre-existing column value and the preview credential bytes remained unchanged; the new learning table is empty. Foreign-key and Alembic schema checks passed. The development database/OpenAPI snapshot were updated. The local preview API and worker were restarted with `PB_AI_LEARNING_ENABLED=true`; no model-generated examples were seeded or auto-approved. See LEARNING.md and LEARNING-EVALUATION.md for operator controls and limitations.

## Still required before a hosted staff pilot

- Run migrations and integration/concurrency tests against an actual PostgreSQL server. Current runtime tests use SQLite.
- Test native sign-in, SecureStore persistence, logout, editing, keyboard/safe-area behavior, session expiry and connectivity failures on iOS and Android simulators and physical phones. Bundle export does not verify those behaviors.
- Configure HTTPS hosting and its explicit web origin, production secrets, backups, monitoring, staff invitations/recovery, MFA and account lifecycle controls.
- Confirm bundle ID ownership and signing/distribution accounts; build and test signed mobile binaries.

Live email, WhatsApp, arbitrary-format/IMEI imports, financial returns, allocation cancellation without receipt, customer/carrier dispatch, broader AI assistance, quotes and customer/wholesaler app access are future roadmap work. Matching does not itself allocate stock; explicit reservations and allocations are now implemented for registered owned devices. Existing PHP website credentials and data have not been migrated into this platform.


## Incoming email attachment validation

There are **171 passing tests: 135 backend, 32 Chrome browser and 4 shared contracts**. Both full backend/browser suites passed. The attachment parser test was then strengthened with a text-bearing PDF fixture; the seven attachment tests passed again. Web/native TypeScript, Next production build and iOS/Android Hermes exports passed. Desktop and 390px attachment review screenshots were visually inspected. React changes were checked for stable hook ordering, effect cleanup, accessible confirmation controls, escaped source text, role guards and preservation of existing conversation edits.

Seven backend cases cover bounded TXT/CSV/XLSX/PDF validation, plaintext markup, malformed/unsupported/empty/oversized inputs, formula rejection, scanned versus text-bearing PDF behavior, active PDFs, child-process timeout, MIME attachment count bounds, authenticated originals, viewer mutation denial, stale/closed conversation rejection, original-byte hashes, corruption rejection, duplicate mailbox imports, immutable source release, draft trading provenance and a two-connection SQLite confirmation race. The race creates one source entry and one conversation version increment.

Two new browser cases cover actual synced fixture attachments through the authenticated proxy: original download, explicit confirmation, stale version recovery, a separate reviewed source entry, reviewed draft creation and retained filename/hash provenance, viewer access and blocked files at phone width. Existing mailbox fixtures now include a supported CSV and a deliberately invalid PDF. No IMAP network, SMTP send or model call was used in these tests.

Migration `d7a42c0f981e` was applied after stopping preview writers and creating a private database backup. Every pre-existing table value and the preview credential bytes were preserved, the new attachment table remained empty, and SQLite foreign-key/Alembic schema checks passed. The development database and OpenAPI snapshot are updated. No historical mail was refetched and the live site/configuration was not changed. Preview API, local Ollama extraction worker and web server were restarted with their existing settings.

Live mailbox receiving, production malware scanning/isolation, PostgreSQL runtime contention, storage/retention operations and physical-device sharing tests remain pending. See EMAIL-ATTACHMENTS.md. These exports are not signed mobile builds.


## Incoming WhatsApp validation

There are **182 passing tests: 144 backend, 34 Chrome browser and 4 shared contracts**. The full backend suite passed. The browser regression run passed 33 tests and found one outdated email-only disclosure expectation; after updating it to source-text wording, all three extraction browser tests passed. The two WhatsApp tests passed again when regenerating desktop/390px screenshots for visual inspection. The nine WhatsApp backend tests passed again after strengthening invalid-Unicode rejection. Web/native TypeScript, Next production build and both iOS/Android Hermes exports passed.

Coverage includes disabled ingress, private configuration, verify-token handshake, raw-body signatures, wrong account/number scope, body and batch limits, malformed envelopes, old-message exclusion, unsupported media/oversized/invalid text, escaped source content, immutable message identity, conflicting retries, sender isolation, conversation reopening and unsent-draft preservation, channel search/filtering, forged manual-received rejection, unsupported-source guards, opt-in AI queueing, reviewed draft provenance, admin-only pause/resume and stale controls, inactive owners and changed configured identity. Independent SQLite connections verify concurrent callbacks produce one message, one history entry and one duplicate count. A populated previous-schema migration test preserves all old column values/password hashes and defaults existing conversations to email.

Browser tests exercise synthetic signed callbacks through the actual ingress handler, WhatsApp source display, media notices, unsent draft saving, trading draft creation, source IDs, channel filtering, phone-width overflow, viewers and cross-origin controls. No Meta account, real phone number, public tunnel, live mailbox, outbound message or model call was involved. React changes were checked for hook ordering, cleanup, role guards and accessible controls. One misleading email attachment-history label was corrected to say attachment names, since retained originals now exist.

Migration `f93ac16b20d8` was applied to the preview after pausing writers and taking a private backup. Every pre-existing business-table value and the preview credential bytes were preserved. New WhatsApp tables remained empty, no number was initialized, existing conversations defaulted to email, and foreign-key/Alembic checks passed. The development schema and OpenAPI snapshot were updated. Preview services retain their existing local AI and learning settings; WhatsApp stays disabled.

The user selected an existing WhatsApp Business number and confirmed that Meta setup is not ready. Existing-number onboarding compatibility, live receiving, PostgreSQL load/contention, production perimeter/logging/retention and physical-device operation remain pending. No number registration/migration, app disconnection or signed mobile distribution took place. See WHATSAPP.md for activation preparation and the next independent quotation/approval milestone.

## Quotation approval and PDF validation

The quotation milestone has **207 passing tests: 165 backend, 36 Chrome browser and 6 shared contracts**. The complete backend suite passed 162 tests before the final three concurrency/migration cases were added; all 21 quotation cases then passed together. The full browser suite passed all 36 tests. Both TypeScript checks, the Next production build, iOS/Android Hermes exports and Python dependency consistency checks passed. These exports are not signed native builds.

Quotation coverage checks exact cents and large totals, required review acknowledgement, a separate approving administrator, role restrictions, immutable history, revision/approval reset, return/cancellation, optimistic versions, duplicate request keys, unavailable/changed sources and customers, source expiry, quantity/currency validation, disabled approvers, escaped PDF markup, unsupported glyph errors and exclusion of supplier/private source fields. Two independent SQLite connections verify duplicate creation produces one quotation and competing approval/edit has one successful result. The populated previous-head migration preserves every old column value, including password hashes, with no inferred quotations.

Browser tests exercise trader drafting, administrator approval, authenticated PDF download, revision reset, self-approval prevention, current-source refresh after a conflict, retained unsaved terms and viewer access at 390px width. Shared contracts preserve price strings and timezone values and reject fractional quantities/sub-cent prices. The PDF was rendered and visually reviewed as both a one-page synthetic example and a four-page, twenty-line maximum-quantity/large-total example. A quantity-column wrapping issue found during visual review was corrected.

Migration `a4bd108e59c2` was applied to the preview after pausing API/worker processes and creating a private SQLite backup. Every pre-existing table value and the preview credential-file bytes were verified unchanged. Quotation/history tables remained empty; no users or business fixtures were added. Foreign-key checks and Alembic schema comparison passed. Development schema and OpenAPI documentation are updated.

Separate-admin approval is mandatory with no environment override. No live customer message, email test, Meta setup or deployment took place. WhatsApp remains disabled and uninitialized. Physical-device share-sheet/cache lifecycle, production PostgreSQL contention and multilingual PDF typography still need validation/implementation before their respective release. Follow-up ownership/due dates and quote-to-order acceptance are the next independent milestones. See QUOTATIONS.md.

After restarting preview services with their existing local AI/learning settings, an authenticated Chrome smoke check passed sign-in, the empty quotations workspace, shared inbox, disabled/uninitialized WhatsApp, attachment routing and logout. No fixture records were added to the preview. Stable quotation desktop/390px screenshots were visually inspected after disabling transition animations in the screenshot capture.


## Quotation follow-up validation

The complete local suites pass **227 tests: 180 backend, 39 Chrome browser and 8 shared contracts**. Follow-up coverage adds 15 backend cases, three browser cases and two shared-contract cases. Web/native TypeScript checks, the Next production build and both iOS/Android Hermes exports passed. Desktop and 390px task screenshots were visually inspected. Native exports are not signed physical-device builds.

Backend checks cover task lifecycle, owner eligibility, explicit timezone/deadline bounds, reason/outcome requirements, viewer mutation rejection, stable history snapshots, reopening, unchanged overdue dates when editing notes, mine/team/overdue/search/pagination filters, escaped search wildcards, unavailable owners and revised/expired/cancelled quotation warnings. Task changes leave quotation content, version, approval and stock unchanged. Independent SQLite connections verify duplicate retries create one task and concurrent completion/edit permits one winner. The populated previous-head migration test preserves all original column values, including quote snapshots and account password hashes.

Browser checks cover task creation inside quotations, reassignment, completion, reopening, fetching current quotation context, global my-task visibility, retained unsaved input after a conflict, explicit discard/reload, overdue filtering, cancelled-quote warnings, viewer history at phone width and cross-origin rejection. One ambiguous test selector initially matched both current notes and the history snapshot; narrowing it to the current notes resolved that test. The full 39-test browser run then passed, including the previous quotation approval/export flow. Shared contracts preserve overdue timestamps and require timezone-aware due values and owners.

Migration `b67e24930ad1` was applied after pausing preview writers and taking a private SQLite backup. Every existing table value and the preview credential-file bytes were preserved. New task/history tables remained empty; no users or business fixtures were created. Foreign-key and Alembic schema checks passed. Development schema and OpenAPI documentation were updated.

The task queue refreshes while open; it does not send email/WhatsApp or background notifications. Physical-device nested sheets/keyboard flows and PostgreSQL runtime contention remain pending. Live email testing remains deferred and WhatsApp remains disabled/uninitialized. See FOLLOWUPS.md for the workflow and release boundaries.

After service restart, the authenticated preview smoke check passed sign-in, empty follow-up and quotation queues, shared inbox, disabled/uninitialized WhatsApp, attachment routing and logout. Existing preview accounts and business data remain in place; no synthetic task or quote was added.

## Customer acceptance and order holds validation

The complete local suites pass **250 tests: 199 backend, 41 Chrome browser and 10 shared contracts**. This milestone adds 19 backend cases, two browser cases and two shared-contract cases. Web/native TypeScript checks, the production web build and both iOS/Android Hermes exports passed. Order screens were visually inspected on desktop and at 390px; the two order browser flows passed again after scoped spacing adjustments. Mobile workspace actions now share a horizontal row to preserve room for the main screen. Native exports are not signed device builds or proof of native interaction behavior.

Backend coverage checks frozen customer/terms/evidence snapshots, acceptance timestamps and review, quote validity/source/customer changes, roles and separate-administrator confirmation, exact device quantities, unavailable devices, unregistered stock/supplier-offer refusal, all-or-nothing multi-line reservation, stock-bounded common deadlines, legacy inventory action rejection, active-order quotation guards, cancellation history and expired-device reassignment protection. Independent SQLite connections test duplicate acceptance retries, simultaneous confirmation/cancellation and confirmation versus a wanted-list hold. The duplicate race caught an early conflict before the request-key retry lookup; rechecking after acquiring the quote lock fixed it. The populated previous-head migration preserves every existing column value, including quotation snapshots, password hashes, wanted IDs, reservations and device associations.

Browser checks exercise trader acceptance inside an approved quotation, unchanged availability before confirmation, administrator IMEI selection/reservation, cancellation restoring availability, immutable history, self-confirmation prevention, viewer evidence/history at phone width and cross-origin denial. Shared contracts preserve evidence text and explicit timezone values while rejecting missing contact/reference/evidence and ambiguous timestamps. The full suite includes existing quotation export/approval, follow-ups, inventory and warehouse flows.

Migration `c81f9045a7d2` was applied after stopping preview writers and creating a private SQLite backup. Every existing table value and the preview credential-file bytes were verified unchanged. Order/history tables remain empty, existing reservations have null order IDs, and no staff or business fixtures were added. Foreign-key and Alembic schema checks passed. Development schema and OpenAPI documentation are updated.

Acceptance evidence is staff-recorded text with a source reference, not an uploaded signed document or verified customer signature. Confirmation creates expiring holds only; fulfilment, allocation, customer dispatch, payment, renewals and partial orders are not implemented. Actual PostgreSQL contention and physical iOS/Android selection, nested sheets and keyboard flows remain release gates. No deployment or outbound messages occurred; live mailbox tests remain deferred and WhatsApp remains disabled/uninitialized. See ORDERS.md for the workflow and limits.

After restarting the API, extraction worker and web preview with the existing local AI/learning settings, authenticated Chrome checks passed sign-in, empty Orders/Follow-ups/Quotations, shared inbox, disabled/uninitialized WhatsApp, attachment routing and logout. The existing preview account worked and no business fixtures were added.

## Order fulfilment validation

The complete local suites pass **277 tests: 222 backend, 43 Chrome browser and 12 shared contracts**. Fulfilment adds 23 backend cases, two browser cases and two shared-contract cases. Web/native TypeScript checks and both iOS/Android Hermes exports passed. Desktop and 390px dispatch screens were visually inspected. The React review covered hooks, cleanup, review resets, stale-input preservation, stable keys, action permissions and accessible field/checkbox names. Native exports are not signed builds or physical-device verification.

Backend coverage verifies permanent allocation of exact held devices; refusal after expiry, reassignment, returns, quarantine, changed identifiers, wrong quantities/prices, archived customers or missing warehouses; all-or-nothing multi-line validation; unchanged accepted snapshots; retained original warehouse/IMEI snapshots; dispatch removing devices from on-hand counts; delivery retaining allocated availability; chronological event times and required evidence; admin-only actions and explicit review; immutable shipment notes/history; rejection of cancellation after allocation; and continued inventory protection after the original hold deadline. An expired quotation does not undo an already confirmed commitment, and archiving a customer after dispatch does not prevent recording actual delivery. Independent SQLite connections permit one winner for allocation versus cancellation, duplicate dispatch and duplicate delivery.

Browser tests exercise administrator allocation, physical dispatch, warehouse count changes, a delay update, stale delivery rejection with notes retained, explicit discard/reload and completed delivery. Viewers can inspect shipment origins at phone width without fulfilment controls; API mutation and cross-origin attempts are denied. The first full regression run passed 42 tests and exposed an existing WhatsApp assertion that matched both the loading status and saved-draft notice during refresh. Narrowing the assertion to the saved notice fixed it; the complete 43-test run then passed. Shared contracts retain evidence/timezone values, omit fields from unrelated actions and label departed customer stock distinctly.

A populated previous-head migration test preserves every prior column, including accepted orders, reservation/device associations, snapshots, histories and password hashes. Preview migration `d92a1068bc43` followed paused API/worker services and a private SQLite backup. Every existing table value and credential-file byte was verified unchanged. Orders/history remain empty in the preview, no fulfilment was inferred and no accounts or business fixtures were added. Foreign-key and Alembic schema comparisons passed; development schema and OpenAPI documentation are updated.

See FULFILMENT.md for administrator controls, warehouse prerequisites, physical attestation and exact boundaries. This milestone supports one complete shipment and staff-recorded evidence only. Order returns, reversals, partial shipments, carrier API tracking and payment processing remain unimplemented. PostgreSQL contention, native physical-device flows, signing and deployment remain release gates. Live email testing stays deferred; WhatsApp remains disabled/uninitialized in the preview. No outbound message, booking or production deployment took place.

The production web build also passed. After restarting the preview API, local extraction worker and web server with the existing AI/learning settings, authenticated Chrome checks passed sign-in, empty allocated/dispatched/delivered order filters, empty follow-ups/quotations, shared inbox, disabled/uninitialized WhatsApp, attachment routing and logout. No business fixtures were added and the existing account still works.

## Order return and recall validation

The complete local suites pass **300 tests: 241 backend, 45 Chrome browser and 14 shared contracts**. This milestone adds 19 backend cases, two browser cases and two shared-contract cases. Both client TypeScript checks, the production web build and iOS/Android Hermes exports passed. The return receipt and entry screens were visually inspected on desktop and at 390px. Hermes exports are not signed builds or physical-device interaction tests.

Backend coverage verifies partial/full physical receipts from allocation, dispatch and delivery; required review/evidence/timezone and chronological bounds; administrator-only mutations; stale order/warehouse versions; different-warehouse shipment receipts and original-warehouse recalls; archived-warehouse rejection; valid receipts despite archived customers or expired stock; exact original device/IMEI membership; all-or-nothing rejection of quarantine, retirement, transfer, reassignment, changed identifiers, existing custody or already-returned devices; quarantine until a separate inspection; immutable accepted sale, receipt, device and order histories; receipt pagination; completed-return price changes while preserving other commitments; and protection against reclaiming a resold device. Independent SQLite connections permit one winner for duplicate receipts, different selected devices against the same version, and dispatch versus recall.

The first targeted backend run exposed a test fixture whose wanted price was below the newly edited stock price. Correcting its budget allowed the intended resale/history assertion; the complete 241-test suite then passed. The first targeted browser run passed the desktop flow and completed the phone return flow but timed out at sign-out because mobile navigation was closed. Opening navigation in the test fixed that step; the complete 45-test run passed. Browser coverage verifies exact IMEI selection, warehouse search/selection, partial/full return counts, immutable receipts after inspection, restored availability only after inspection, retained input on conflict, explicit discard/reload, read-only phone-width access and server rejection of viewer mutations. Shared contracts preserve warehouse versions, selections, evidence and timezone values while rejecting duplicate devices and incomplete receipt input.

React review checked client boundaries, hook dependencies/cleanup, stable IDs, permission gates, physical-review reset on edits and accessible input/radio/checkbox names. The browser-verification skill was used as a checklist; its `agent-browser` executable is not installed, so installed Playwright/Chrome supplied the visual and interaction verification.

A populated previous-head migration test preserves every existing column value, including delivered orders, shipment snapshots, reservation/device associations, histories and password hashes. Migration `e03b2179cd54` was applied to the preview after stopping its writers and creating a private SQLite backup. Every previous table value and the credential-file bytes were verified unchanged. The new receipt table and existing preview order tables remain empty; no returns, users or business fixtures were inferred or added. Foreign-key and Alembic comparison checks passed. The development schema and OpenAPI snapshot were updated.

See ORDER-RETURNS.md for the workflow and boundaries. Partial returns stop the complete-order dispatch/delivery workflow; mixed shipment/return closure remains future work. Invoices, taxes, credits, refunds and payment tracking are not implemented by this milestone. PostgreSQL contention and native physical-device/signing checks remain release gates. Live email testing remains deferred, WhatsApp remains disabled/uninitialized, and the live PHP site is unchanged.

After restoring the preview API, local extraction worker and web server with the existing AI/learning settings, authenticated Chrome smoke checks passed sign-in, empty fulfilment/return order filters, empty follow-up/quotation queues, shared inbox, disabled/uninitialized WhatsApp, return/attachment proxy routing and logout. No browser exceptions or framework error overlays were detected. Existing credentials still work and no preview business fixtures were created.

## Invoice draft and receipt-ledger validation

This milestone has **330 passing tests: 267 backend, 47 Chrome browser and 16 shared contracts**. It adds 26 backend cases, two browser cases and two shared-contract cases. The complete backend and browser suites passed; the 26 billing cases and both billing browser flows passed again after the final PDF/pagination adjustments. Web/native TypeScript checks and both iOS/Android Hermes exports passed. Native exports are not signed physical-device builds.

The user chose formal tax invoices and will provide issuer/tax details. Invoice issuance remains disabled in the preview and defaults off. Only isolated synthetic tests enable it. The current generic tax calculations, required fields and manually entered invoice number are not a country-specific compliance implementation. No real issuer, tax rate, registration or numbering series was entered, and no live tax invoice or payment transaction was created.

Backend checks cover pending tax versus explicit zero, exact line rounding and large totals, unchanged accepted order prices/terms, disabled issuance, different-administrator issuance, role/review/version enforcement, immutable issued content, unique retained numbers, partial/full receipts, overpayment/currency/date rejection, duplicate reference and request-key protection, reversed-entry retention and balance restoration, void restrictions, return-related financial review without inferred credits/refunds, overdue/search filters, private escaped PDFs and unsupported-glyph rejection before issue. Independent SQLite connections verify identical creation/receipt retries, competing receipts, duplicate reversal, issue versus edit and receipt versus physical return. A populated previous-head migration preserves all previous column values, including orders, return history, inventory associations and password hashes, with no inferred financial records.

Initial targeted backend failures were test-fixture issues: comparing role-specific order action flags from different roles, and regenerating a due timestamp during an allegedly identical retry. Using the same role and exact payload corrected those assertions. Initial browser failures matched both the current total and hidden history snapshots; explicitly selecting the current summary fixed the selectors. The full 47-test Chrome run passed afterward.

Browser checks exercise order-linked draft entry, pending tax, explicit rate revision, draft PDF download, separate-admin issue, partial/full payment, stale receipt rejection with input retained, explicit reload, retained reversal evidence, unchanged order state, viewer access at 390px and API/origin denial. Visual inspection found narrow-page billing pagination clipped by the panel; scoped wrapping/padding fixed it, and the repeated browser tests explicitly verify both pagination buttons fit inside the viewport. React review checked hook dependencies/cleanup, busy locks, unsaved-input guards, stable document/payment IDs, review resets and labelled keyboard-accessible controls.

PDFs were rendered with Poppler and visually inspected with synthetic issuer/customer details: a one-page draft, a one-page issued-layout test and a twenty-line large-total draft. Wider numeric columns fixed a wrapping tax amount. Compact two-column addresses and row spacing removed an orphan final notice; the final long draft is three pages, with repeated table headers and draft markings. Text extraction confirms literal markup escaping, totals, no supplier cost/source IDs and no draft label on the isolated issued example. These sample PDFs do not represent a real invoice.

Migration `f14c328ade65` followed paused preview writers and a private SQLite backup. Every previous table value and credential-file byte was verified unchanged. New billing document/payment/history tables remain empty. Foreign-key and Alembic schema checks passed; the default development database and OpenAPI snapshot are updated. Issuance remains false and WhatsApp remains uninitialized. Live email tests remain deferred; the legacy PHP site and its accounts are unchanged. See BILLING.md for pending jurisdiction setup, numbering, inclusive/mixed tax, deposits, credits/refunds and reconciliation. PostgreSQL contention and native interaction/signing remain release gates.

The production web build passed. The final billing backend tests also passed after tightening request-key conflict handling and hashing normalized receipt-reference keys. Preview API, extraction worker and web services were restored with existing local AI/learning settings and invoice issuance explicitly disabled. Authenticated Chrome smoke checks passed existing sign-in, empty billing/payment status filters, empty order/task/quotation queues, shared inbox, disabled/uninitialized WhatsApp, billing/return/attachment proxy routes and logout. No browser exception or framework error overlay was detected and no business fixtures were added.

## Operations overview validation — 2026-10-05

Added the first Phase 5 reporting milestone while formal issuer/tax setup is pending. The read-only `/v1/operations` endpoint provides 15 counts in one SQL aggregate statement, with one captured time and authenticated-user personal scope. Web and native clients share metric definitions, show a timestamp and explicit overlap guidance, clear obsolete counts when refreshing or failing, and open the existing workspaces. There is no schema migration or business-record mutation.

This turn passed **275 backend tests** (the complete suite, including eight new operations cases), **16 contract tests**, and **three new Chrome operations tests**. The previous 47 browser cases were not rerun this turn. TypeScript checks, production web build and iOS/Android Hermes exports passed. Physical-device interaction, signing and PostgreSQL runtime validation remain pending.

API cases verify all roles, empty records, deadline equality/24-hour boundaries, signed-in-user scope, closed/completed/cancelled exclusions, retired devices, pending tax, paid/void exclusions, overlapping billing review, revoked/inactive sessions, no writes and fresh reads. Browser checks compare all displayed counts with the real API after adding a synthetic received-message record only to the isolated test database, exercise all six workspace links, verify viewer layout/button bounds at 390px, recover from a simulated outage and clear the view on session expiry. Desktop and phone screenshots were visually inspected with no clipped metrics or controls. React review covered hook cleanup, stable keys, typed navigation, accessible buttons and loading/error states.

The first browser start encountered the already-running preview Next.js server; stopping that exact preview process resolved the lock. An initial error test matched both the Next route announcer and the visible error panel; scoping the assertion to Operations fixed the selector, and all three cases then passed. `agent-browser` is unavailable, so equivalent page/content/console/overlay/navigation checks used the installed Playwright Chrome runtime.

The preview API and web services were restored with the existing database and local AI settings; the existing extraction worker was left running. Formal invoice issuance is explicitly disabled. No company/tax values, Meta settings or credentials were changed. OpenAPI and the roadmap are updated; see OPERATIONS.md for exact count semantics and remaining reporting work.

Final authenticated Chrome smoke on the restored preview passed existing-account sign-in, all 15 displayed operations counts against the API, existing empty billing/order/follow-up/quotation views, shared inbox, disabled/uninitialized WhatsApp, private proxy checks and logout. No business fixtures were added and no browser exception or framework error overlay appeared.

## Relationship workload validation — 2026-10-05

Added the second Phase 5 reporting milestone: six company-linked workload categories with inspectable, paginated source rows, directory search and type/status filters on staff web and native mobile. Each endpoint executes one reporting statement with a single captured time; count definitions and source lists reuse the same selectors. No schema migration or business data backfill is required.

This turn passed **286 backend tests** (complete suite, including 11 new relationship cases), **16 shared-contract tests**, and **six Chrome tests** (three new relationship flows plus all three operations flows). Other browser cases were not rerun. Web/native TypeScript checks, production web build and iOS/Android Hermes exports passed. Native exports do not establish physical-device interaction or signing; PostgreSQL runtime/performance validation remains pending.

The new API checks cover role access, empty/missing companies, all six categories, snapshot expiry/due boundaries, cross-company and unlinked isolation, archived records, literal `%`/`_`/backslash searches, stable pagination including out-of-range totals, invalid input, revoked sessions and single-statement read-only behavior. Source responses exclude message bodies, contact addresses, internal notes and prices. Browser coverage uses real API-created synthetic companies and received-message records only in the isolated browser test database: 21-row source pagination, 21-company pagination, retained filters, all category switches, archived viewer access, literal markup, phone-width bounds, source workspace navigation, delayed stale-response rejection, outage recovery and session expiry. All six browser flows passed on the first run.

Desktop and 390px screenshots were visually inspected; long company names, category controls, record IDs and pagination fit. React review covered typed category/navigation definitions, stable keys, query/revision keyed results, effect cleanup, hook ordering, preserved list state on back, accessible controls and error/empty/loading states. Existing React and Next conventions were retained. Installed Playwright Chrome provided browser verification because `agent-browser` is unavailable.

Preview web was temporarily stopped to avoid the Next dev lock while tests ran. The API and web preview were restored with the existing database, local AI/learning configuration and invoice issuance explicitly disabled; the extraction worker was left running. No credentials, company/tax configuration, Meta connection or live website files were changed. Documentation and OpenAPI were updated. See RELATIONSHIPS.md for the exact attribution rules and reporting limits.

Final authenticated Chrome smoke on the restored preview passed existing-account sign-in, relationship list/source categories, operations counts, existing billing/order/task/quotation queues, inbox, disabled/uninitialized WhatsApp, private proxy checks and logout. No business fixtures were added and no browser exception or framework error overlay was found.

## Reviewed opportunity ranking validation — 2026-10-05

Added the third Phase 5 milestone on staff web and native mobile: live customer requests, ranked eligible supply with reasons and differences, original source inspection, explicit staff review and preparation of an unsaved quotation draft. Ranking evaluates the complete filtered selection before pagination, with an explicit 250-candidate bound requiring narrower filters. Review revalidates recorded versions and quantities. Preparation performs no writes and leaves sale price and terms blank. There is no schema migration or persistent wanted-to-quotation attribution; see OPPORTUNITIES.md for the exact boundaries.

The complete backend suite passed **298 tests**, including 12 new opportunity cases. **17 shared-contract tests** passed. **Five Chrome browser tests** passed: three new opportunity flows and both existing quotation flows. Other browser cases were not rerun this milestone. Web/native TypeScript checks, the production web build and both iOS/Android Hermes exports passed. Physical-device interaction, signing and PostgreSQL runtime/load validation remain pending.

API checks cover exact/near ranking across pages, stock evidence before supplier reports, quantity coverage, missing budget and mixed-currency uncertainty, unavailable devices, committed demand and expired holds, inactive/expired companies and records, changed versions or quantities, explicit review, viewer and revoked-session denial, read-only preparation, literal searches, pagination and the candidate bound. The contract test preserves source/customer versions, currency, quantity and validity while requiring staff to supply a selling price.

Browser flows verify real source inspection, explicit confirmation, reviewed draft prefill, blank-price enforcement, exact totals and no reservation; changed-supply rejection and cleared review; filter/refresh resets, outage recovery, unsaved-draft discard confirmation, viewer access at 390px and session expiry. Existing quotation tests confirm separate-administrator approval/export, revision invalidation, source-change rejection and viewer history. Desktop and phone screenshots were visually inspected with no clipped controls. React review covered hook cleanup, keyed request state, stable IDs, permission gates, busy locks, unsaved input and labelled controls. Installed Playwright Chrome supplied equivalent browser verification because agent-browser is unavailable.

One initial backend assertion compared equivalent timestamps serialized with Z and +00:00; comparing parsed datetimes corrected the test. An initial viewer browser test installed an expiry interceptor during the source-close automatic refresh, signing out before its intended manual refresh click. Waiting for refreshed candidates and the enabled refresh control corrected the test timing. The final complete backend and five-browser-test runs passed.

The local preview API and web were restored with existing database and AI/learning settings; the extraction worker was left running. Final authenticated Chrome smoke passed existing-account sign-in, opportunities list/ranking proxy, relationship list/source categories, operations counts, existing empty billing/order/task/quotation queues, inbox, disabled/uninitialized WhatsApp, private proxy checks and logout. No browser exceptions or framework error overlays appeared, and no business fixtures were added. OpenAPI and roadmap documentation are updated. Invoice issuance remains explicitly disabled, live email testing remains deferred, and credentials and the legacy live website are unchanged.

## Reviewed staff assistant validation — 2026-10-05

Phase 5 milestone 4 adds local question-to-lookup suggestions, staff-reviewed scope/search, deterministic company/trading/workload answers and refreshed source inspection on web/native. Manual lookups work without AI. No business records are sent to the model, no commercial writes or chat-history tables are added, and no migration is required. See ASSISTANT.md for supported searches, source fields and limits.

The complete backend suite passed **322 tests**, including **24 new assistant cases**. All **17 shared-contract tests** passed. **Six Chrome tests** passed: three new assistant flows and the three existing operations flows. Other browser cases were not rerun. Web/native TypeScript checks, the production web build and both iOS/Android Hermes exports passed. Exports do not establish physical-device interaction or signing; PostgreSQL runtime/load validation remains pending.

API tests cover all staff roles, revoked sessions during inference, no-write lookup, exact workload reuse, active/expired/archived record filtering, current inventory/commitments, missing budget and exact prices, pagination, literal search wildcards, omission of notes/contact fields, current source versions, unknown source kinds, strict bounded inputs, disabled interpretation, busy/cooldown handling, sanitized failures, loopback-only model calls, question-only input, local metadata checks and rejection of fabricated excerpts, extra fields, tools and incomplete output. The model only proposes a reviewed lookup; these checks do not certify semantic understanding of every question.

Browser checks use real isolated company records and mocked interpretation responses. They verify ten-row pagination, literal markup rendering, changed/archived source inspection, explicit lookup confirmation, unsupported questions, failed-answer clearing/recovery, same-origin and route restrictions, no-AI manual lookup, viewer access at 390px, Operations navigation and expired-session logout. One initial browser assertion also matched the hidden Next.js alert; scoping it to the assistant corrected the test. The final six-test run passed. Desktop and phone screenshots were visually inspected with readable wrapping and no horizontal clipping. React review covered component boundaries, typed scopes, stable IDs, hook cleanup, response invalidation, busy locks, error states and accessible labels. Playwright Chrome supplied equivalent verification because agent-browser is not installed.

The installed local Qwen3 4B model also passed seven synthetic interpretation examples, covering company/stock/offer searches, workload and three unsupported action/financial/instruction requests. Calls took approximately 0.6–3.2 seconds. This is a development evaluation, not a production accuracy claim. scripts/evaluate-assistant.py reproduces it without reading business records; ignored output is stored privately under .local.

The local API/web preview was restored with the existing database and local AI/learning settings; the extraction worker was left running. Final authenticated Chrome smoke passed actual local-model interpretation of a synthetic workload question, explicit review before lookup, all five lookup scopes, available source routes, opportunities, relationships, operations, existing empty billing/order/task/quotation views, inbox, disabled/uninitialized WhatsApp, private proxy checks and logout. No browser exception or framework error overlay appeared. No business fixtures or credentials were changed. Invoice issuance remains disabled and live mailbox testing remains deferred; the live legacy website is unchanged. Roadmap, local AI guidance and OpenAPI are updated.

## Company trading history validation — 2026-10-06

Phase 5 milestone 5 adds dated quotation/order activity inside Relationships on web/native. Company attribution comes from saved quotation-event snapshots or the frozen accepted order, retaining cancelled-order history even after its quotation is reassigned. A single reporting statement returns company metadata, filtered event/distinct-record counts and stable paginated rows. Event inspection reloads company-scoped saved details. No migration, commercial writes or inferred financial totals are added; see COMPANY-HISTORY.md.

The complete backend suite passed **336 tests**, including **14 new company-history cases**. All **18 shared-contract tests** passed, including one new date/default validation case. **Six Chrome tests** passed: the three new history flows and all three existing relationship flows. Other browser cases were not rerun. Web/native TypeScript checks, production web build and iOS/Android Hermes exports passed. Native interaction/signing and PostgreSQL runtime/load checks remain pending; PostgreSQL JSON expressions were compilation-tested only.

Backend checks include actual order cancellation followed by quotation reassignment, immutable event attribution, cross-company detail denial, archived-company access, exact inclusive UTC boundaries, stable equal-time ordering, event versus distinct-record counts, empty/out-of-range pages, omitted sensitive fields, strict date/type/page validation, unknown attribution exclusion, authentication/revocation and no-write single-statement reporting. Browser tests use genuine synthetic quotation revisions in the isolated test database: 21-event pagination, exact saved total/revision inspection, unapplied/applied dates, invalid ranges, archived viewer access at 390px, literal markup, stale-filter response rejection, outage clearing/recovery and session expiry. All targeted tests and browser flows passed on their first runs.

Desktop and phone screenshots were visually inspected; date controls, references, navigation and event cards wrap without horizontal clipping. React review covered typed filters, hook ordering/cleanup, complete query keys, immutable source IDs, preserved parent list state, explicitly applied dates, accessible controls and loading/error/empty states. Installed Playwright Chrome supplied browser verification because agent-browser is unavailable. Existing preview API and web were restored with the original database and AI/learning settings; the extraction worker was left running. Invoice issuance remains disabled, live email testing remains deferred and WhatsApp remains uninitialized. No credentials, company/tax configuration or live PHP files were changed. Documentation and OpenAPI are updated.

Final authenticated Chrome preview smoke passed existing-account sign-in, company history and type-filter API routes, current Relationships/Operations, the actual local assistant flow, opportunities, existing billing/order/task/quotation queues, inbox, private proxy routing and logout. No business fixtures were added, and no browser exception or framework error overlay appeared.

## Assistant-to-history integration validation — 2026-10-06

Connected the existing staff assistant and company history on web/native. History interpretation proposes a company search only. Staff review explicit UTC dates, run a candidate lookup including active/archived companies, then choose a company ID before any events load. Duplicate names remain separate choices. The existing company history screen receives the reviewed dates and preserves its immutable attribution/source rules. No new schema, commercial writes, training, provider fallback or chat memory is introduced.

The complete backend suite passed **348 tests**, including **12 new history-lookup cases**. All **18 shared-contract tests** passed. **Eight Chrome tests** passed: two new integration flows plus all three assistant and all three company-history flows. Other browser cases were not rerun. Web/native TypeScript checks, production web build and iOS/Android Hermes exports passed. Device interaction/signing and PostgreSQL runtime/load validation remain pending.

New API coverage checks every staff role, duplicate names, archived candidates, exact date preservation, company-only reads before selection, existing active-only directory behavior, empty pagination, required date pairs, malformed/numeric/reversed/oversized dates, rejection of dates on other scopes, and model output limited to a company excerpt without dates. The initial new fixture attempted to set archive status during company creation, which the existing API rejects; creating then archiving via the update API corrected the fixture. The 50 targeted assistant/history cases and complete backend suite passed afterward.

Browser checks use genuine synthetic quotes and companies in the isolated database. They verify model suggestion without automatic lookup, prominent manual-date guidance, duplicate-name selection including an archived buyer, exact range handoff, saved event totals/revisions, return to preserved candidate results, cleared results after date edits, empty historical periods, invalid-range rejection, no-AI phone-width viewer access and session expiry. All eight browser tests passed on the first run. Desktop/phone screenshots were visually inspected without horizontal clipping. React review covered hook order/cleanup, typed scopes, response invalidation, date/result consistency, stable company IDs, back-navigation state and labelled controls. Installed Playwright Chrome provided browser verification because agent-browser is unavailable.

The expanded local Qwen3 4B synthetic evaluation passed all ten cases, including history with/without dates and unsupported company-profit questions. Calls took approximately 0.6–3.3 seconds. This is a small development evaluation, not representative production accuracy. Dates in a question are intentionally not interpreted; only reviewed date controls determine the range. Evaluation uses synthetic text and never reads business records.

Preview API/web were restored with the existing private database and AI/learning configuration; the extraction worker was left running. Invoice issuance remains disabled, live mailbox tests deferred and WhatsApp uninitialized. No credentials, issuer/tax configuration or live PHP files changed. Roadmap, assistant/history guidance and OpenAPI are updated.

Final authenticated Chrome preview smoke passed actual local-model history suggestion using a synthetic question, date review, available company selection, range preservation and return navigation, plus existing lookup/source routes, opportunities, relationships/company history, operations, billing/order/task/quotation queues, inbox, private proxy checks and logout. No browser exceptions or framework error overlays appeared, and no business fixtures were added.

## Staff access lifecycle validation — 2026-10-06

Added Phase 6 milestone 1: reviewed administrator disable/reactivate and all-session revocation on web and native mobile. Actions require the current administrator password, an explicit confirmation, a complete audit reason and the current access version. Last-active-admin and self-deactivation guards preserve administration. Disabling access retains passwords, roles, assignments and history. Server CLI password reset now shares the target lock and increments the access version. See STAFF-ACCESS.md for exact behavior and limits.

The complete backend suite passed **363 tests**, including **15 new staff-access cases**. All **18 contract tests** and **six Chrome tests** passed (three new staff-access flows plus the three existing workspace/sign-in flows). Other browser cases were not rerun. Web/native TypeScript checks, production web build and iOS/Android Hermes exports passed. Native device interaction/signing and PostgreSQL runtime/load validation remain pending.

API checks cover disabled sign-in, old-token rejection before/after reactivation, new sign-in after revocation, preserved credentials/work/audit, self-sign-out, last administrator, role denial, stale versions, explicit confirmation and reason/password validation, password throttling, literal searches, pagination, full-length audit reasons and a populated previous-head migration. Independent SQLite connections exercise simultaneous cross-administrator disable, duplicate target changes and sign-in versus disable.

Chrome checks create only synthetic isolated-test accounts. They verify genuine token access before revocation and rejection afterward, disable/reactivate, audit visibility, stale-review rejection, retained reason with cleared password/confirmation, fresh reload/review, self-revocation, viewer denial and phone-width controls. Review strengthened the initial token assertion to use access_token and verify it works before revocation. Visual inspection caught a clipped Cancel button in the phone dialog; scoped button wrapping and per-button bounds assertions fixed it. The final six-test run passed. Desktop and corrected phone screenshots were visually inspected. React review covered role gates, selected version snapshots, secret clearing, double-submit locks, unmount response guards, stable IDs and labelled controls. Installed Playwright Chrome provided equivalent verification because agent-browser is unavailable.

Preview API and worker were paused; private SQLite backups were created before migrating preview and development databases to a25d439bef76. Alembic schema checks and SQLite foreign-key checks passed, every preexisting column/value was compared unchanged, and the preview credential file remained byte-identical. No preview account access actions were performed. The API/worker/web were restored with the existing local AI/learning settings and invoice issuance disabled. WhatsApp remains uninitialized and live mailbox testing deferred. No live PHP files, credentials or issuer/tax configuration changed. OpenAPI and roadmap were updated.

Final authenticated preview smoke passed read-only staff listing/detail, unchanged active administrator/version and disabled self-deactivation control, plus the actual local assistant/history flow, source lookups, opportunities, relationships, operations, billing/order/task/quotation queues, inbox, disabled WhatsApp and logout. No business fixtures or access changes were made, and no browser exception or framework error overlay appeared. Database backups are retained under ignored .local paths with owner-only file permissions.

## Authenticator and controlled recovery validation — 2026-10-07

Added Phase 6 milestone 2 on staff web and native mobile: optional manual-key TOTP enrollment, encrypted seeds, hashed one-time backup codes, verified factor/password changes and server-issued password recovery tokens. Sign-in and administrator access actions require the factor once enrolled. Recovery requires the token and existing MFA, preserves MFA and signs out all sessions. No account is automatically enrolled and no recovery email is sent. See ACCOUNT-SECURITY.md for the exact operator process, key handling and remaining production gates.

The complete backend suite passed **380 tests**, including **17 new MFA/recovery tests**. All **18 contract tests**, **nine Chrome tests**, web/native TypeScript checks, the production web build and both iOS/Android Hermes exports passed. Dependency consistency check passed. Other browser suites were not rerun. Native device interaction/signing, actual authenticator-app interoperability trials, PostgreSQL runtime/load tests and independent security review remain pending.

Backend cases cover encrypted pending/enrolled seeds, no secret audit output, enrollment revoking other sessions, password-only rejection, replay rejection including enrollment codes, current/expired time windows, setup replacement/expiry, backup replacement/consumption, protected administrator access changes, password changes, single-use recovery retaining MFA, invalidated/expired/replaced/inactive recovery tokens, missing-key fail-closed behavior, per-email throttling, own-account viewer scope, stale versions not consuming codes, and a populated prior-head migration. Independent SQLite connections prove that concurrent attempts cannot consume the same backup code or recovery token twice.

Chrome flows use only synthetic isolated accounts and keys. They cover enrollment and one-time backup display/acknowledgment, password-only denial, backup sign-in, genuine CLI-issued recovery and subsequent MFA sign-in, viewer enrollment at 390px, stale security review with cleared sensitive fields, cross-origin recovery denial and invalid-token errors. All six existing staff-access/workspace cases also passed. One initial public-recovery test matched Next's hidden route-announcer alert as well as the visible error; scoping the selector fixed the test, and all nine passed on rerun. Desktop and phone screenshots were visually inspected without clipped controls. React review covered hook order and cleanup, scoped secret state, response invalidation, submit locks, role gates, labelled fields and wrapped actions. Installed Playwright Chrome supplied browser verification because agent-browser is unavailable.

Preview API/worker were paused and private SQLite backups created. Migration b36e540cf087, Alembic schema checks and foreign-key checks passed on preview/development databases. Every original table column/value and the preview credential file were compared unchanged. The three new tables were empty after migration. A private owner-only local Fernet key was created without printing it, and the API/worker/web restored with the existing AI/learning settings and invoice issuance disabled. No preview enrollment, access changes, live mail tests, Meta activation, issuer changes or legacy PHP changes were made. OpenAPI, setup documentation and roadmap were updated.

Final authenticated preview smoke passed read-only Account security status and the enrollment entry point, unchanged unenrolled administrator status, staff access, the actual local assistant/history flow, reporting/source lookups, existing business queues, inbox, disabled WhatsApp and logout. No account factors or business records were changed, and no browser exception or framework error overlay appeared.

## PostgreSQL regression, concurrency and restore validation — 2026-10-07

Completed Phase 6 milestone 3 locally using PostgreSQL **17.11**. Added a guarded runner, opt-in database fixture, portable independent-connection scenarios, seven target-isolation guard cases and a PostgreSQL-only populated migration/backup-restore case. No new production schema migration or public API contract is required. See POSTGRES-VALIDATION.md for reproducible commands and boundaries.

The final PostgreSQL-mode suite passed **388 tests**. Of these, **349 cases** used disposable PostgreSQL schemas and one additional storage test used disposable PostgreSQL databases; remaining cases are pure unit checks or intentional SQLite file/migration checks. The SQLite-mode suite passed **387 tests**, with only the PostgreSQL storage case skipped. A further **five repetitions of 34 PostgreSQL concurrency cases** passed (**170 additional executions**). These are bounded correctness checks, not capacity/load certification. No UI changes were made; browser/native builds were not rerun this milestone.

The first PostgreSQL run found one application portability defect and two test-helper assumptions: malformed company-history JSON caused a PostgreSQL cast error, and two learning-evaluation tests assumed SQLite files/backup methods. The history query now uses a CASE guarded by IS JSON before casting. Learning tests keep the explicit SQLite byte-preservation check and use real read-only PostgreSQL snapshots for the portable evaluation case. The focused 21-case rerun, full suites and repeated concurrency passes succeeded afterward.

The PostgreSQL runner applied all Alembic migrations from an empty database and passed alembic check. The storage test separately upgraded populated revision a25d439bef76 to the current head, preserving every original table value. It then created synthetic approved quotations, a confirmed order reserving two IMEIs and MFA state through actual API calls. pg_dump/pg_restore into a second disposable database preserved all table contents. With the corresponding test encryption key supplied, restored API checks retained the order/reservations, rejected password-only login and accepted a backup code only once. This does not validate production key escrow or external attachment storage restoration.

Concurrent PostgreSQL cases exercised inventory/demand contention, quote approval versus edits, order/warehouse/return mutations, billing balance/duplicate actions, worker leases, imports and webhook retries, staff access revocation, sign-in versus disable and one-use MFA/recovery credentials. The fresh local cluster used SCRAM authentication and loopback-only port 55437; neither the shared hosting nor the preview database was used. PostgreSQL binaries were installed locally; no system service was registered or started. The runner stopped its cluster successfully after the final pass (pg_ctl reported no server running). Existing preview API/web processes remained running throughout. No live email/WhatsApp actions, issuer changes, preview credential/enrollment changes or legacy PHP changes were made.

Hosted staging, least-privilege runtime roles, TLS/network configuration, representative load measurements, monitored workers, production backup retention/restore drills, physical devices and independent security review remain required before the staff pilot. Roadmap, architecture and current security/history guidance now distinguish completed local PostgreSQL checks from those remaining gates.

## Private staging preparation — 2026-10-07

Prepared Phase 6 milestone 4 deployment sources and the operator runbook in STAGING.md. Added separate web/API Dockerfiles, an allowlisted build context, Compose services for PostgreSQL/migrations/API/web/optional worker/Caddy, private per-installation secret generation, an IP-restricted HTTPS proxy, persistent attachment/certificate volumes and separate database owner/runtime credentials. AI, live integrations and invoice issuance remain disabled in the staging defaults. No staging secrets or real hostnames were generated; configuration checks used disposable synthetic values.

Added detail-free `/ready` checks for database access and exact release migration heads, keeping `/health` as liveness. The API startup wrapper loads the generated database password and validates the mounted MFA key without logging secrets. Runtime grants are applied after migrations; API containers do not receive owner credentials. The existing local development Compose file and application schema are unchanged.

Validation: **19 focused SQLite-mode tests passed**, then **20 focused PostgreSQL-mode tests passed**, covering readiness, secret generation/overwrite refusal, configuration injection rejection, existing login/company authorization and actual least-privilege role behavior. Seven PostgreSQL cases used disposable schemas, and an additional staging-role case used a fresh disposable database plus non-superuser owner/runtime connections. The shipped grant script allowed staff login, company creation/read and logout while rejecting table creation/drop, truncation, role creation and migration-version writes. The isolated PostgreSQL cluster stopped afterward. These focused counts are not a rerun of the previous full 388-case suite.

`npm run build:web` passed with Next standalone output. `scripts/check-staging.py` passed Compose resolution and Caddy adaptation/validation, then launched an isolated standalone server against a synthetic API. Root/static/logo delivery, omitted framework disclosure header, Secure/HttpOnly/SameSite cookies, missing/wrong Origin rejection, token suppression in login JSON and authenticated API proxying passed. It stopped both temporary servers and removed its private fixtures. A YAML temporary-filesystem list quoting issue found during inspection was fixed; the checker now asserts the complete mount option and passed again. Shell syntax and generator CLI checks also passed.

Caddy 2.11.7 and Docker Compose 5.6.0 were installed locally for syntax validation; no system service was enabled. **Docker Engine is unavailable, so images/full container startup, Linux volume ownership/networking, proxy access enforcement over real TLS, real DNS, hosted monitoring/backups/restore and physical-device checks remain unverified.** No server has been deployed. This preparation does not close the hosted staging gate.

At final verification, the previous preview processes were no longer listening. Restarted its API/web, local-only Ollama model server and extraction worker using the existing preview database, credential file, MFA key and prior AI/learning configuration. Web returned HTTP 200 and the new API readiness endpoint returned ready. No password reset, account enrollment, database migration, live email/WhatsApp activation, invoice issuance or legacy website change was performed in this milestone.

## Personal security activity and session control — 2026-10-07

Completed the local Phase 6 milestone 5 while hosting confirmation, container deployment and physical-device testing are deferred at the user's request. Web/iOS/Android Account security now shows active-session count and curated personal account events, with reviewed password/MFA verification to sign out other sessions. The action retains the current session and credentials, revokes other sessions/recovery tokens, increments the access version and records an audit event. Existing locks serialize it with sign-in, revocation and access changes. No migration or default account change is needed.

Personal events expose only fixed labels, time, event identifier/action and actor category. Private operator reasons, raw summaries and actor names are excluded. Cursor anchors must belong to a visible event for the current user, and newer events do not shift older-page results. Shared audit/dashboard feeds now exclude all session/security/user namespaces, including unknown future actions, preventing those feeds from bypassing personal-history redaction. Original database audit records are retained; shared business events still display.

The initial focused SQLite and PostgreSQL suites each passed **44 tests**, including independent-connection races for same-session/different-session revocation and concurrent sign-in. After adding the shared-feed privacy regression, the final SQLite run passed **52 tests** across security activity, MFA, staff access and workspace behavior. The final affected PostgreSQL subset passed **20 tests** (19 used isolated PostgreSQL schema fixtures; the remaining production-configuration case needs no schema). This is focused verification, not a new full-suite run. The isolated cluster was stopped after the checks.

**10 browser scenarios passed**, covering the new personal feed and second-session revocation alongside existing MFA, recovery, staff-access and workspace flows. The **4 affected activity/workspace scenarios passed again** after the shared-feed fix. Checks included keeping the requesting session signed in, denying the revoked token, cross-origin rejection, retained activity during a temporary load failure, successful refresh, and phone-width overflow. Desktop and phone screenshots were visually inspected; controls/history remained readable without clipped content. React review checked hook order, pending-request invalidation/unmount cleanup, duplicate-submit locks, cleared credentials, page deduplication and accessible controls. Native hook behavior mirrors the verified web controller; physical interaction has not been tested.

Workspace typechecks, **18 shared-contract tests**, the Next production build and both iOS/Android Expo exports passed. An initial native typecheck caught an invalid shared style name; it was corrected to the existing history style and all subsequent checks passed. OpenAPI, account-security guidance, architecture, README and roadmap were updated. Build/export success does not constitute signed mobile distribution or device validation.

The preview API/web were restarted with existing configuration. An authenticated read-only smoke verified personal status/activity plus business feeds. Every user's ID/email/password hash/active flag/access version and the private credential/MFA key file hashes compared unchanged. Only the temporary smoke-test login was created and signed out; no sign-out-others action, password change, factor enrollment, live message or commercial mutation was performed against the preview. Hosting/device prerequisites remain deferred without blocking this local feature.


## 2026-10-08 — Staff invitations (Phase 6 milestone 6)

Built reviewed administrator issuance/reissue/revocation and public recipient acceptance on web/iOS/Android. Tokens are displayed once, hashed at rest, single-use and valid for 24 hours; the reviewed issuer access version remains authoritative. Existing accounts cannot be overwritten and acceptance does not sign in automatically. No live invitation email or preview invitation was sent/issued.

The selected SQLite invitation/MFA/security-activity/staff-access regression passed **62 tests**, including **17 invitation cases**. The matching isolated PostgreSQL regression plus staging-role/storage coverage passed **64 tests**, including independent-connection races, restricted-role checks and populated migration/logical restore. Schema consistency passed. These are targeted suites, not a rerun of every platform test.

The selected invitation/security-activity/security/staff-access Chrome suite passed **nine tests**. One older staff-access test incorrectly expected private operator reasons in shared activity; it now checks their exclusion and checks the affected user’s curated personal history. Both new invitation browser cases passed again after layout adjustments. Desktop and 390px screenshots were inspected. Tests cover acceptance/sign-in, single use, viewer restrictions, stale-review secret clearing, reissue/revoke, same-origin rejection and request size limits.

Web/native typechecks, **18 shared-contract tests**, production web compilation and both iOS/Android exports passed. A TextField type mismatch found in the first typecheck was corrected. OpenAPI and workflow/roadmap documentation were refreshed. Native exports do not constitute signed builds or physical-device validation.

Private backups were made before migrating preview and development databases to `c47f651da198`. Migration/schema/FK checks passed; every original table value (apart from the migration version) was preserved. The new invitation tables are empty. Private credential/MFA-key hashes were unchanged. No legacy PHP/live website files or accounts were modified. Hosting selection, deployment and physical-device validation remain deferred.

The production web build passed again after the final layout adjustments. Preview API, web and the existing local extraction worker were restored. An authenticated read-only smoke passed for the empty invitation list, personal security status/activity, Operations and API readiness. Only the temporary sign-in session was created and signed out; account IDs/emails/password hashes/active flags/access versions and private credential/MFA-key hashes remained unchanged.


## 2026-10-08 — Authenticator key maintenance (Phase 6 milestone 7)

Implemented optional previous-key decryption and the offline `phonebuzz.rotate_mfa_key` command. It defaults to non-mutating inspection, requires explicit maintenance/backup attestations and a reviewed reason to apply, validates every active/pending ciphertext and atomically rotates only old-key fields plus private per-account audit events. It preserves passwords, MFA seeds, replay/setup metadata, sessions, backup codes, recovery tokens, invitations and access versions. No schema migration or client-source change is required. See MFA-KEY-ROTATION.md for exact maintenance, retirement and failure-recovery instructions.

The initial targeted SQLite security/rotation/staging suite passed **73 tests**. After strengthening rollback coverage, adding previous-key startup validation and redacted CLI configuration handling, the selected SQLite rotation/staging/staff-access/workspace suite passed **50 tests**. The PostgreSQL run passed **77 tests**, including the shipped non-superuser runtime grants and both ordinary and rotated logical backup/restore with subsequent MFA sign-in. The final **17 rotation tests** passed again on PostgreSQL after the CLI import/error-boundary adjustment. These were targeted suites, not the entire platform suite.

Coverage includes mixed-key and expired pending state, preservation of encrypted timestamps and all other stored values, malformed/unrelated/missing/duplicate keys, failure after flushed database writes, idempotent repeated runs, independent-connection rotation, MFA replay, TOTP/backup sign-in and pending setup confirmation after retiring the old key, audit privacy, CLI guard flags, and invalid environment errors without secret-bearing tracebacks. The operator CLI now defers database initialization until inside its redacted error boundary; help works even with invalid database settings. PostgreSQL schema checks reported no migration changes.

A read-only inspection against the existing preview passed with zero enrolled/pending MFA rows. Every database table value and both private credential/key hashes compared unchanged. No actual preview key rotation was performed. The API was restarted with its original key/database/AI settings, and authenticated sign-in, security status/history, invitations, Operations and readiness checks passed. The temporary smoke session was signed out; existing account/password/access-version values and private files remained unchanged. The web preview and worker were retained. No live emails, deployment or legacy website changes occurred.

No web/native source or API response schema changed, so client builds, browser screenshots and OpenAPI regeneration were not repeated for this server-maintenance milestone. Hosted key/mount/restore drills, mandatory MFA policy, live integrations, formal invoice activation, physical-device validation and distribution remain pending. Docker Engine remains unavailable locally; container execution is not claimed.


## 2026-10-08 — Reviewed staff roles (Phase 6 milestone 8)

Added administrator-reviewed colleague role changes on web/iOS/Android through the existing staff-access endpoint. New-role selection requires current password, enrolled MFA, explicit review, reason and current target version. Self-role changes, unchanged-role submissions and demotion of the last active administrator are rejected. Changes preserve passwords, MFA, backup codes, name/email, account status and work/history; revoke target sessions and recovery tokens; and invalidate old-version pending setup/issued invitations. Personal history shows a curated role-change event. The private audit retains old/new roles, revoked session count and reason.

The selected backend role/access/MFA/security-history/invitation regression passed **82 tests on SQLite and 82 on PostgreSQL**, including **20 new role cases**. Independent-connection checks cover simultaneous administrator demotions, duplicate changes, sign-in and deactivation races. The focused 20-role-case SQLite suite passed again after adding session counts to the private role audit summary. No schema migration was needed; PostgreSQL schema checks remained clean.

All **seven selected Chrome tests** passed (two new role flows, three existing staff-access flows and two invitations). The two role flows passed again with viewport screenshots for visual review. Desktop and 390px forms were inspected: selection and review text wrap, horizontal content fits, the long dialog scrolls, and confirmation controls remain reachable. Tests cover promotion/demotion, old-session revocation, new-session permissions, self-control disablement, current-role reload after stale errors, confirmation clearing and foreign-origin rejection.

Web/native TypeScript checks, **18 shared-contract tests**, the production web build and both iOS/Android native exports passed. Exports are not signed/device-tested builds. Shared action types, OpenAPI, account-security/staff-access guidance, architecture, README and roadmap were updated. This was targeted validation, not a complete platform-suite rerun.

The local API/web preview was restored with the original database, key and AI settings. Read-only authenticated staff access, personal history, invitations, Operations and readiness checks passed; the temporary smoke-test session was signed out. Existing user roles/password hashes/names/emails/active flags/access versions and private key/credential hashes compared unchanged. No existing preview roles were changed, no live messages were sent and the legacy PHP website remains untouched. Hosting/deployment, formal invoice activation, live integrations and physical-device/distribution checks remain pending.


## 2026-10-08 — Supplier-offer expiry review (Phase 5 milestone 6)

Continued independent business reporting while deployment/integration prerequisites remain deferred. Added Operations → Review supplier offer expiry on web/iOS/Android: five non-overlapping expiry windows, supplier/brand/model search, search-scoped counts, paginated active-offer records and fresh source inspection. Archived/missing suppliers remain visible; inactive offers can be inspected after a list snapshot changes. Recorded quantity and exact price text do not imply confirmed availability. There are no renewals, outbound messages or other mutations. See OFFER-EXPIRY.md.

The selected offer-expiry/Operations/Relationships suites passed **28 backend tests on SQLite and 28 on PostgreSQL**, including **nine new offer-expiry cases**. Coverage includes deadline equality at now/24 hours/7 days, null expiry, excluded kinds/statuses, literal wildcard search, pagination totals, archive/missing-supplier handling, exact source prices, revoked sessions, one reporting SQL statement and unchanged database values. PostgreSQL migration/schema checks remained clean; no new migration is required.

The selected Chrome suite passed **nine tests**, including three new offer-expiry flows. An initial error-recovery test tried to click Refresh after the automatic back-navigation refresh had already received 401 and correctly signed out. Waiting for the successful back-navigation load before injecting the expired-session response fixed the test; the complete nine-case selection passed on rerun. Tests use real synthetic offers for pagination, changed/withdrawn source inspection, preserved search, archived-supplier viewer access, literal source markup, failed-refresh clearing and sign-out. Desktop and 390px screenshots were visually inspected with readable wrapping and no horizontal overflow.

Web/native TypeScript checks, **18 shared-contract tests**, the production web build and iOS/Android exports passed. The first typecheck identified nullable report data inside a render callback; the guarded access was corrected and subsequent checks passed. Native exports are not physical-device or signed-distribution evidence. Shared report contracts, OpenAPI, README, architecture and workflow/roadmap documentation were updated.

API/web preview were restarted with the original database/key/AI settings. An authenticated read-only smoke passed all five report windows, Operations, personal history, staff access and readiness. Business/account/security-table values and private credential/MFA-key hashes compared unchanged; only the temporary authentication session/audit events were produced and the session was signed out. No preview business fixtures, live messages, legacy website edits, migration or key/role/password changes occurred. Hosting/deployment, live integration tests, formal invoice activation and native-device/distribution checks remain pending.

## 2026-10-12 — Offline worker recovery rehearsal (Phase 6 milestone 13)

Added `scripts/check-worker-recovery.py` and a documented operator runbook. The CLI launches with a clean environment, creates/migrates a temporary SQLite database, blocks Python socket connections/DNS lookup, simulates worker time and removes temporary state. It accepts no external database target and writes unique owner-only JSON reports. The internal scenario refuses populated databases and restores patched clocks/configuration and API dependencies after success or failure.

The complete rehearsal passed **56 checkpoints** on SQLite and PostgreSQL, including administrator acknowledgements through authenticated API calls, reconnection persistence, worker exceptions, duplicate observations, stalled passes, completion fencing, clock skew, suspension/re-enable, idle evidence, missing monitor observations and recovery. Injected SQL execution failures prove that failed start writes prevent synthetic business work, failed monitor writes invent no history, and failed completion writes leave pending evidence without replaying work. These are synthetic faults, not hosted infrastructure failure drills.

The focused SQLite regression passed **29 tests**. The PostgreSQL runner passed **6 tests**, of which three used disposable PostgreSQL schemas and three used isolated SQLite subprocesses for CLI checks. A deliberately incorrect monitor success result produces a failed report; inherited private configuration and a sentinel database are ignored; an intercepted network attempt causes failure even when caught by scenario code. Migration/schema checks passed in the PostgreSQL runner.

No application runtime, clients, contracts or migrations changed; web/native builds and browser checks were not repeated. The local preview, live website, external services and deployment were not touched. No continuous monitoring, provider connection, delivery or recovery automation was enabled. See WORKER-RECOVERY-DRILL.md for scope, evidence and pending hosted checks.

## 2026-10-13 — Consolidated release-readiness review

Created RELEASE-READINESS.md with phase/capability status, dated evidence, explicit release gates and responsibilities, pending owner inputs and the next independent feature: reviewed outbound email preparation with live sending disabled. Phase 6 remains in progress; the report is not a new product milestone or release sign-off.

Reviewed roadmap/workflow sources, deployment and mobile configuration, documented security findings and saved recovery reports. Confirmed local build/export/OpenAPI artifacts are present and the documented acknowledgement route exists. Artifact presence is not release-candidate reproducibility or a fresh test pass. No regression, model evaluation, registry security audit or live integration test was rerun for this documentation review.

Reconciled stale roadmap statements about already-built push foundations, the received owner guidance, local PostgreSQL billing checks and local-model process instructions. Historical test counts remain dated and scoped rather than summed. No source runtime, credentials, database, deployment, integration activation or mobile signing state changed. Documentation links were checked locally.

## 2026-10-13 — Outbound email preparation and review (Phase 3 milestone 8)

Added one frozen outbound snapshot per email conversation, immutable version history, separate-administrator approval, cancellation/repreparation and effective invalidation on conversation/sender/staff-access changes. The approver cannot be either the original saved-draft author or the preparer. Read-only viewers retain shared inbox visibility. No queue, sending endpoint or live transport is implemented; status is always not sent.

The focused SQLite suite passed 24 cases. The PostgreSQL selection passed 31 cases (26 using private disposable schemas, with separate restricted-role and SQLite migration/CLI cases); the restricted-role test was then extended to create/read the new outbound records/history and passed again. Concurrency includes identical preparation retries, approval/cancel conflicts and approval versus draft save. The worker rehearsal remains compatible with the new migration head, without counting its older report revision as the current head.

Five browser workflows passed, covering shared inbox regression, frozen reply preparation, separate admin approval at phone width, invalidation, original history, literal markup, viewer/origin denial, unavailable refresh and expired sessions. Typechecks, 21 contract tests, the production web build and iOS/Android exports passed. Phone-width approval was visually checked. This does not establish physical-device or live SMTP behavior.

Migration db40d28e1865 was backed up and applied locally; all original table digests and FK checks were preserved, and both new tables remained empty. OpenAPI, workflow docs, roadmap and release readiness were updated. Existing accounts, credentials, business content and the live PHP website remain unchanged. Next: a simulated delivery ledger, with actual sending still unavailable.

## 2026-10-13 — Email delivery simulation (Phase 3 milestone 9)

Added a durable simulation ledger tied to exact immutable approved email revisions, one claim per approval, pure network-free outcomes, 60-second claim deadlines, completion fencing and context/authority rechecks. Expired claims recover as uncertain without replay; uncertainty blocks new exercises until an administrator records a review. Resolution never retries a revision or establishes real delivery. Web/native show retained snapshots/events, paginated history, explicit simulation labels and no-send status.

The focused SQLite run passed 43 cases (25 simulation and 18 outbound-review cases). The final PostgreSQL selection passed 44 cases: 41 in private disposable PostgreSQL schemas, two SQLite migration cases and a separate restricted-runtime-role PostgreSQL case, including reads/writes of both new tables. Covered duplicate/identical concurrent claims, approval edits during the simulated boundary, role/access/session loss, uncertain errors, expiry/recovery, stale completion, cross-conversation isolation, immutable history and non-destructive populated migration.

Six browser workflows passed (three simulation and three outbound approval regressions). Covered phone-width review, administrator resolution, interruption display, lost-response retries using the same key, no duplicate attempts, viewer and origin restrictions, escaped content, failed refresh and expired sessions. The phone screenshot was visually inspected. Client typechecks, all 21 shared contract tests, production web build and both iOS/Android exports passed. No physical-device, live SMTP or fresh full-platform/security acceptance is claimed.

Local preview and development databases were backed up under `.local/backups/before-email-simulation-20261012T222512Z/` before migration `ec51e39f2976`; the exact directory is also recorded in the migration tool output. Both migrations and schema comparisons passed; all 53 original table digests and FK checks were preserved, and the two new tables started empty. Existing accounts, passwords, business records and public PHP website files were unchanged. OpenAPI, workflow docs, roadmap and release readiness were updated. Next: private sender configuration and offline preflight, with live email tests still deferred.

## 2026-10-13 — Private outbound configuration and offline preflight (Phase 3 milestone 10)

Added an optional private JSON-file selector on the API server, a bounded POSIX file reader, fixed redacted check results, an offline CLI and administrator-only System Health panels on web/iOS/Android. Checks cover file ownership/mode/link traversal, strict JSON format, hostname syntax, encrypted mode/port pairing, ASCII sender syntax, credential presence and matching the proposed reply address. Authentication, DNS, TLS certificates, sender ownership and delivery always remain unverified; sending remains unavailable. The report never returns configured values or writes to the database. No SMTP or public-site credential was copied or activated.

56 focused SQLite cases passed for preflight and System Health. The PostgreSQL runner selection passed 62 cases, including 17 using private disposable PostgreSQL schemas; the remainder cover local file/CLI behavior and worker recovery checks. After adding malformed-path and additional public-directory rejection, all 43 preflight cases passed again. These counts describe overlapping scoped runs, not a combined platform total. Tests include no-DNS/connection guards, read-only SQL inspection, unauthorized file-read denial, secret/error redaction, live file rotation, strict field types, file-size bounds, special files/links/owner modes and CLI exit codes.

Nine distinct browser workflows passed across the initial run and a focused rerun of one test after correcting its ambiguous alert selector (eight initially passed; the remaining case then passed). Real isolated private-file fixtures exercise a passing report, sender mismatch, unsafe file mode, restored configuration and no credential leakage. Existing System Health permission, refresh, worker-history and administrator-review flows passed. The phone-width preflight panel was visually inspected; there was no horizontal overflow.

Client typechecks, all 21 shared contract tests, production web build and iOS/Android exports passed. OpenAPI, configuration examples, workflow docs, roadmap and release readiness were updated. No database migration or existing account/password/business-record change was required. Actual preview outbound configuration remains unset; no live email test, provider request, deployment or physical-device test occurred. Next: offline reply threading and outgoing message formatting/identifiers, with live transport still unavailable.

## 2026-10-13 — Offline email formatting and reply threading (Phase 3 milestone 11)

Added immutable UTF-8 plain-text MIME previews to prepared outbound snapshots, with preparation-time identifiers/dates, exact serialized bytes, SHA-256 and conservative reply headers. Imported messages retain bounded validated threading evidence; missing, ambiguous or conflicting evidence produces visible warnings and omitted reply headers. Changed threading evidence invalidates a current preparation. Old snapshots remain readable without rewriting history. Web/native current and historical review panels show escaped source and metadata. No transport or live sending was enabled.

The selected SQLite regressions passed 57 cases; the new formatter suite passed 25 cases after correcting malformed multi-ID handling to inspect raw headers rather than a normalized structured header. The PostgreSQL selection passed 83 cases, including 61 using private disposable PostgreSQL schemas. Other cases cover pure formatting/parsing, SQLite migration and a separate restricted-role database. Coverage includes Unicode round trips, exact CRLF/digests, injection rejection, no-network guards, cross-conversation evidence, stale approvals, retry stability, historical compatibility and migration preservation. These are scoped runs, not a full-platform total.

Eight distinct browser workflows passed across formatting, outbound review and simulation. The imported-reply case passed again after strengthening expanded-source visibility assertions. The 390px screenshot was visually inspected with readable wrapping and no horizontal overflow. Web/native typechecks, 21 shared-contract tests, the production web build and both iOS/Android exports passed. Exports do not establish physical-device or signed-distribution behavior. OpenAPI and workflow/readiness documentation were updated.

Both local databases were backed up under `.local/backups/before-email-format-20261013T185833Z/` and migrated to `fd62f4a03887`. All 55 original tables' original-column projections remained unchanged; existing imported rows have null new threading metadata. Foreign-key and schema checks passed. Existing accounts/passwords/business content and public PHP website files were preserved. No real credentials, provider connections, live messages or hosted deployment were used. Next: a test-only SMTP adapter against a local fake server using synthetic messages, with real sending disabled.

Local API/web previews were restored with the existing database/key/AI settings. Read-only readiness and web requests returned 200; the protected outbound route returned 401 without authentication. No outbound private configuration was activated.

## 2026-10-14 — Synthetic SMTP protocol rehearsal (Phase 3 milestone 12)

Added a test-only adapter and fake SMTP peer under `scripts/smtp_rehearsal/`, with `scripts/check-smtp.py` as a repeatable operator command. The adapter owns a private Unix stream socket, supports STARTTLS and implicit TLS with certificate/hostname verification, uses fixed synthetic AUTH PLAIN identities and accepts only bounded digest-checked plain-text messages with fixed synthetic envelope headers. It never reads private SMTP configuration or application records and is not imported by the runtime. Explicit refusals, pre-body failure, uncertain post-body outcomes and fake-server acceptance remain distinct; no result permits automatic retry or claims delivery.

The final focused suite passed **70 tests**. Coverage includes missing/refused TLS, untrusted certificates, hostname mismatch, authentication failure, sender/recipient rejection, pre-DATA rejection, partial body writes, server acceptance with lost/delayed acknowledgement, malformed/unexpected replies, QUIT failures after acceptance, exact MIME preservation and dot transparency. Invalid digests, controls/newlines, headers/recipients, duplicate headers, multipart and oversized messages are rejected before protocol exchange. TCP socket input and unverified TLS contexts are refused. Command checks cover clean inherited settings, untouched sentinel files, rejected live inputs, redacted timeout failure reports, false-success detection and blocked network attempts even when the attempted operation catches its error. Verification uses explicit runtime checks so Python optimization cannot remove rehearsal assertions.

The final independent CLI passed **48 scenarios** (25 STARTTLS, 22 implicit TLS, one dot-transparency case), with zero external-network attempts and confirmed temporary-file cleanup. Evidence: `.local/smtp-rehearsal/rehearsal-20261013T204602Z-42536ef2.json` (UTC filename; this entry uses the user's Asia/Karachi date). Reports are created exclusively with mode 0600; ephemeral test certificates/keys are removed with their temporary directory. The initial synthetic peer comparison incorrectly assumed uppercase SMTP command arguments; matching the library's case-insensitive command syntax corrected the first rehearsal failure before successful validation. Later tests strengthened lost-acknowledgement scenarios to confirm that the fake peer had accepted internally while the adapter retained uncertainty.

No runtime source, API contract, UI, schema, preview database/account, real credential, public website, live provider or deployment changed. PostgreSQL suites, client builds and physical-device checks were not rerun for this scripts/tests/docs-only milestone. Local documentation links passed. Existing simulation and approval records remain independent of this laboratory adapter; no real send endpoint or worker was introduced. Next: disposable-database rehearsal of durable approved-revision handoff, interruption recovery and duplicate prevention against the fake peer. Live email testing remains deferred. See [SMTP-REHEARSAL.md](SMTP-REHEARSAL.md).

## 2026-10-14 — Durable synthetic SMTP handoff (Phase 3 milestone 13)

Added `scripts/check-smtp-handoff.py` and a disposable-database handoff prototype under `scripts/smtp_rehearsal/`. Real inbox/preparation/separate-administrator approval APIs create synthetic frozen replies. Laboratory-only attempt/event tables retain exact approval identity/content, idempotent request identity, a durable pre-I/O handoff fence, token/deadline fencing, protocol evidence and administrator review attribution. They are separate metadata, not production migrations or application routes. Installation refuses populated application databases.

The final combined SQLite/local selection passed **104 tests** (34 handoff and 70 existing protocol cases). The final PostgreSQL selection passed **34 tests**, including **29 backed by private disposable PostgreSQL schemas**; the remaining five use isolated SQLite/CLI subprocesses. PostgreSQL migration and schema comparison passed with no new operations. The initial sandboxed PostgreSQL startup was denied; the same isolated local runner then succeeded with approval. Both suites emitted the existing Starlette/httpx deprecation warning; it did not fail validation.

Coverage includes concurrent same/distinct request claims, one dispatcher per approval, frozen history, role/current-source/version checks, no-format/bad-digest/changed-history refusal, write failures before claim/handoff and after fake acceptance, missing completion, stale token/deadline rejection, uncertainty across new approvals and administrator resolution without replay. Post-acceptance changes preserve the actual fake-peer result with a context-change flag, rather than mislabeling it as blocked. A final review identified the paused-worker interval after durable handoff. The adapter now supports a laboratory guard immediately before DATA body transmission; it rechecks authority/state/token/deadline under the existing conversation/account locks across the bounded fake body exchange. Added recovery/logout/draft-change race cases passed on both database backends with zero body submissions. This lock strategy remains a laboratory design requiring production latency review.

The independent command passed **14 checkpoints**, including actual abrupt subprocess exits after claim, before peer invocation and after fake-peer acceptance but before DB completion. Separate synthetic receipt evidence establishes acceptance in the last case. Reconnection/recovery preserves blocked or uncertain state, fences late completion and never replays. The report `.local/smtp-handoff/rehearsal-20261013T233752Z-6cefc4d5.json` records zero blocked external-network attempts, temporary-database cleanup and schema revision `fd62f4a03887`. The UTC filename differs from this Asia/Karachi-dated entry. Inherited settings/sentinel isolation, unsupported live arguments and an intentionally caught DNS attempt causing report failure were also tested.

No live provider, real email, existing database/account/credential, preview server, public PHP website, runtime API, client contract or UI was changed. No production migration, browser/mobile rebuild, physical-device or deployment test was required or claimed. Documentation links were checked locally. Next: add durable outbound attempt history and administrator recovery review to the staff application, keeping provider dispatch disabled. See [SMTP-HANDOFF.md](SMTP-HANDOFF.md).

## 2026-10-14 — Staff outbound attempt history and recovery review (Phase 3 milestone 14)

Added authenticated paginated attempt history and administrator-only recovery/review APIs, with matching web/iOS/Android panels. Frozen approval/content, protocol outcome, context-change evidence and ordered reviewer events are preserved. Expired untouched claims become blocked; expired handoffs become uncertain. Pending records containing protocol evidence retain that evidence. Reviewing uncertainty never marks delivery or retries. Strict note/confirmation/version requirements, renewed administrator checks under locks, idempotent request keys and generic private-note-free audit summaries protect mutations. Claim tokens remain private and are cleared by review/recovery. There is no create/send/retry endpoint, provider worker, SMTP import or automatic attempt creation; existing users see empty history.

The selected SQLite run passed **65 tests** (22 new attempt-history cases plus 43 approval/simulation regressions). The PostgreSQL selection passed **66 cases**, including **62 private-schema cases**, three SQLite migration cases and a separate restricted-runtime-role case. The restricted role creates, reads and recovers the new tables using the shipped grants. Migration/schema comparison passed. Tests cover exact expiry boundaries, strict payloads and confirmations, staff/session/administrator permissions, post-lock role changes, cross-conversation denial, retained snapshots/outcomes despite later edits, concurrent identical/distinct reviews, duplicate event prevention and populated downgrade refusal. These are targeted runs, not a full-platform suite.

**Nine distinct browser workflows passed**, including three new attempt-history flows and six approval/simulation regressions. Phone-width recovery/review, literal message/note content, viewer inspection without controls, preserved acceptance without delivery claims, same-origin protection, lost-response idempotency, failed-refresh clearing and session-expiry sign-out were verified. After clarifying the preparation-preview label to avoid implying no historical submission, the three new flows passed again and the final phone screenshot was visually inspected with readable wrapping and no horizontal overflow. The standalone browser seeder is pinned to `.local/e2e.db`, requires a synthetic conversation prefix and test staff, and is never a runtime endpoint.

Web/native TypeScript checks, **21 shared-contract tests**, the final production web build and both iOS/Android exports passed. OpenAPI, workflow/roadmap/readiness documentation and the web proxy allowlist were updated. Existing Starlette/httpx, Node module-type and color-environment warnings were non-failing. Exported bundles are not signed or physical-device-tested builds.

Preview and development databases were backed up with private file permissions under `.local/backups/before-email-attempts-20261014T000131Z/`, then migrated to `0a73b5d14998`. All **55 original tables** compared unchanged in each database; FK checks and schema comparisons passed, and both new tables remained empty. No rehearsal data was backfilled. Existing accounts/passwords/business records, private settings and the live PHP website were preserved. Provider dispatch, live tests, hosted deployment and physical-device checks remain pending. Next: final outbound message identity and reply-thread matching, with dispatch still disabled. See [EMAIL-ATTEMPTS.md](EMAIL-ATTEMPTS.md).

The API/web previews were restored with the original database/key/AI settings. Read-only API readiness and web requests returned 200; the new history route returned 401 without authentication. Documentation links passed. No private SMTP configuration or dispatch capability was activated.


## 2026-10-14 — Sealed outbound identities and incoming reply matching (Phase 3 milestone 15)

Approval now atomically seals final Message-ID, UTC Date, MIME bytes, size and digest alongside its immutable history and outgoing identity index. Preparation previews remain unchanged. Exact retries and reads preserve sealed bytes; new approvals get new IDs. Old approvals are not backfilled. Web/native approval and attempt views distinguish preparation from final identity and explicitly retain sending-disabled/delivery-unverified wording.

Incoming routing now validates raw, bounded References/In-Reply-To and incoming Message-ID values. Outgoing anchors require matching mailbox, correspondent, approval/version, exact frozen attempt snapshot and accepted/uncertain/handoff evidence. Ambiguous/colliding/cross-thread/cross-sender/unsupported references remain separate; known unsent outgoing references cannot fall back to earlier incoming anchors. Evidence is refreshed after the conversation lock. A received reply can reopen its thread and invalidate stale approval but cannot modify delivery evidence or authorize another submission.

**169 distinct selected SQLite/pure backend cases passed** across approval, formatting, mailbox, attempt recovery, simulation, handoff laboratory and **31 new identity/routing cases**. The initial PostgreSQL selection passed **109 cases**, including **79 private-schema cases** and the restricted-runtime-role check; the two subsequently added evidence-refresh/malformed-fallback regressions passed separately in PostgreSQL private schemas (**111 total selected cases, 81 private-schema cases**). Migration/schema checks passed. These are targeted checks, not a full-platform suite. The existing script-only handoff remains a prototype and is not connected to production attempt creation.

**Eight Chrome workflows passed** across email formatting, approval and attempt review. Added browser assertions confirm sealed source contains the final ID and imported parent and remains identical after refresh; the preparation preview is preserved. The 390px final-identity screenshot was visually inspected with readable wrapping and no horizontal overflow. Shared web/mobile typechecks, **21 contract tests**, production web compilation and iOS/Android exports passed. Existing Starlette/httpx, module-type and color warnings remain non-failing. Exports are unsigned and do not replace physical-device tests.

Both local databases were backed up with private permissions under `.local/backups/before-email-identity-20261014T003408Z/` and migrated to `1b84c6e25009`. All **57 original tables** compared unchanged in both databases; foreign keys and schema checks passed, and the new index remained empty. OpenAPI, workflow documentation, roadmap and readiness were updated. No real credentials, message delivery, public PHP website change, hosted deployment or integration activation occurred. Next: connect sealed formats to actual durable attempt/handoff behavior and the synthetic SMTP rehearsal, with dispatch disabled. See [EMAIL-IDENTITY.md](EMAIL-IDENTITY.md).

Preview restoration was completed on **2026-10-15 (Asia/Karachi)**. API readiness and the web page returned 200, and the protected outbound endpoint returned 401 without authentication. Existing preview database/key/local-model settings were retained; no private outbound configuration was activated. Changed documentation links passed.

## 2026-10-15 — Linux VPS pilot package and host preflight (Phase 6 milestone 14)

The owner selected Linux VPS preparation and asked to prioritize the server pilot. Added a source-only deployment packager with an explicit file/type allowlist, symlink and overwrite refusal, bounded input/expanded archive sizes, normalized ZIP metadata, per-file and aggregate SHA-256 identity, migration-head capture and a separate trusted archive checksum. Verification rejects corrupt manifests, unsafe/duplicate members, inappropriate file modes and incomplete migration chains without extraction. Local configuration, databases, caches, installed dependencies, credential-named files and mobile bundles are excluded. This is not a general source secret scanner or a signed release.

Added a read-only Linux/Docker/Compose preflight and optional private-configuration/Compose validation. It suppresses process diagnostics and never prints credential contents, installs software, pulls/builds images or starts services. Passing prerequisites explicitly does not mark deployment verified. The actual Mac check correctly failed the Linux/Docker gates; deployment sources passed. Existing Compose/Caddy configuration validation passed using disposable synthetic settings.

The focused package/staging/readiness selection passed **38 cases**, including **25 new package/host cases**; the 25 new cases passed again after archive-member validation and private-mode tightening. The **full backend suite passed 915 cases, with 7 skipped and no failures**, using isolated test settings with live integrations disabled. Non-failing warnings cover Starlette/httpx, existing pypdf fixture APIs and intentionally duplicated ZIP entries. No full PostgreSQL/browser/native rebuild was needed for these scripts/docs-only changes; earlier scoped results remain dated evidence rather than being claimed as rerun.

An actual-source trial package contained **271 files**. Its manifest/archive verified, then a disposable extraction successfully ran all API migrations, schema comparison and fresh staging setup. The temporary database and generated secrets were removed with the trial directory. Deployment documentation links and Python compilation passed. API readiness and the web preview both returned 200; no preview restart, existing database migration, password change or live website edit occurred.

The delivery artifact is `.local/releases/pilot-20261015-01/phonebuzz-pilot-20261015-01.zip`, with adjacent checksum and release manifest. Its immutable contents identify the upload candidate; Linux image builds and actual hosting remain unverified. No server, DNS record, paid account, model provider or external integration was activated. Next: container-compatible model connectivity/evaluation preparation and, once the VPS exists, actual hosted build, recovery, security and staff acceptance checks. See [PILOT-PACKAGE.md](PILOT-PACKAGE.md).

## 2026-10-15 — Private VPS model connection and probe (Phase 6 milestone 15)

Added validated `PB_OLLAMA_HOST` with only the existing loopback default and fixed private service name `ollama`. Assistant interpretation and email extraction share the destination/local-model checks; arbitrary hosts/URLs and model-copy destination bypasses are refused. Existing redirects/proxy/cloud-fallback restrictions and source validation remain intact. No API contract, database schema or client UI changed.

The opt-in Compose model overlay connects only API/worker/Ollama to an internal network, publishes no model port, disables cloud features, sets bounded model concurrency/queue settings and requires operator-selected image/resources. AI and both teaching features remain disabled by default. A separately named provisioning overlay temporarily permits model downloads; documented recreation removes that network before business use. Base staging remains unchanged. Linux network enforcement, image startup, resource sizing and volume behavior remain unverified until the VPS exists.

Added an explicit-run model probe: metadata-only checks send no prompts; optional evaluation uses three fixed synthetic cases and records the selected model digest before and after. Reports omit raw outputs and private error details, and fail on changed weights, unavailable/remote models or wrong expected answers. No DB records, jobs, examples or model weights are written by the probe. These smoke checks are not a real staff accuracy benchmark.

The targeted SQLite/pure selection passed **124 tests, 1 skipped**, including **20 new model-hosting/probe tests** and existing assistant, extraction, learning and package checks. An earlier extraction/assistant selection passed 45 tests. Compose/Caddy plus both optional overlays passed actual local configuration resolution using synthetic values; no images/weights were pulled or containers started. Changed documentation links passed. PostgreSQL and client builds were not rerun because this change adds no database, contract or UI behavior.

The laptop model was initially stopped; a failed connection returned a sanitized provider failure. The existing installed Ollama was started temporarily with cloud features disabled and the existing private model directory. The real Qwen3 4B smoke report passed metadata, stock lookup (2.86s), unsupported delete request (0.56s), non-trading extraction (3.26s) and unchanged-digest checks. Model digest: `359d7dd4bcdab3d86b87d73ac27966f4dbb9f5efdfcc75d34a8764a09474fae7`. The report is `.local/model-hosting-smoke.json`; timings are laptop observations, not VPS capacity estimates. The temporary model server was stopped afterward. No model download, weight training, real business content or cloud inference occurred.

Refreshed server source package: `.local/releases/pilot-20261015-02/phonebuzz-pilot-20261015-02.zip`; the previous immutable package is retained. It includes the model overlays, probe and DevOps instructions in SERVER-AI.md. No provider/server was purchased, no deployment or live messaging was activated, and existing business data/passwords/private configuration remain unchanged. Next: a repeatable pilot acceptance/recovery rehearsal, followed by actual hosted build, security, restore and staff/model acceptance once the VPS is ready.

## 2026-10-15 — Staff pilot and coordinated recovery rehearsal (Phase 6 milestone 16)

Added `scripts/check-pilot.py`, shipped in the immutable server-source allowlist. Its isolated child creates a fully migrated temporary SQLite database, synthetic administrator/trader/viewer accounts and business fixtures, blocks outbound socket connections and produces a private report before removing all temporary data. It has no configurable server/database target. Fifteen checkpoints pass through catalogue/stock/wanted matching, private attachment upload, exact quotation totals, separate approval/confirmation, acceptance retry, IMEI warehouse custody/allocation/dispatch, MFA enrollment, coordinated database/files/key restoration, restored authentication, delivery and return quarantine. Full table snapshots and file/key equality are checked before restored API writes; the original checkpoint remains unchanged afterward.

Validation performed:

- **10 new rehearsal tests passed**: complete workflow, missing/changed attachments, changed database/key, populated database refusal, no-overwrite restore, inherited settings/dotenv isolation, unsupported target arguments and blocked network attempts even when caught by application code. App dependency overrides and MFA configuration patches are restored after success/failure.
- **92 existing focused tests passed** across packaging, attachments, fulfilment, order returns and MFA. Warnings were existing HTTPX/Starlette/PDF deprecations and the deliberately duplicated ZIP member case.
- **2 PostgreSQL storage integration cases passed** using PostgreSQL 17.11 with SCRAM and an isolated local cluster. These tests create their own temporary databases, apply migrations, dump/restore and verify exact records, reserved IMEIs and preserved/rotated MFA keys. The runner's generic schema-backed counter reports zero because these cases own separate disposable databases; both tests actually use PostgreSQL. Migration/schema comparison also passed.
- The standalone SQLite rehearsal passed **all 15 checkpoints**, with no outbound connection attempts and successful temporary-data cleanup. Its JSON report is retained privately under `.local/pilot-rehearsal/`.

No application runtime, database schema, UI, existing account/password, preview data, real provider configuration or public PHP website was changed. The new workflow is an API-level synthetic rehearsal; it is not browser/device/staff acceptance. The SQLite/files/key backup is coordinated under quiescent test conditions. PostgreSQL logical restore above remains a distinct check; actual hosted coordinated backup/restore, Linux builds, security/access/load checks and model/staff acceptance remain open. Client builds and full-platform regression were not repeated for this scripts/tests/docs-only change.

The next source candidate is `pilot-20261015-03`, retaining the earlier immutable packages. Next: final release-candidate validation and operator handover; hosted checks follow when the VPS is available. See [PILOT-REHEARSAL.md](PILOT-REHEARSAL.md).

## 2026-10-15 — Release source comparison and DevOps handover (Phase 6 milestone 17)

Added `package-staging.py compare`: it verifies a trusted ZIP digest/manifest before comparing selected extracted source, reports missing/changed/unexpected allowlisted paths without file contents, and returns nonzero on drift. Settings, databases, installed dependencies and build outputs remain excluded. No source is executed or changed. Creation still requires the complete source layout; comparison can report missing files/trees. Added a DevOps handover covering release identity, first installation, staff acceptance, hosted recovery, update continuity and sanitized evidence return. Nothing was sent externally.

Current validation:

- **Full backend: 945 passed, 7 skipped**, in 171.45 seconds. The skips require PostgreSQL-specific coverage. This run collected before the seven new comparison tests were added; those are covered by the focused run below, not retroactively included in 945.
- **Package/source comparison: 32 passed**, including seven new cases for clean extraction with private local state, changed/missing/new selected source, missing required files/trees, trusted-digest ordering and CLI exit status. Actual development source correctly failed comparison against the prior immutable candidate after this milestone's changes.
- **PostgreSQL release selection: 47 passed** on PostgreSQL 17.11: readiness, restricted runtime grants, populated migration/logical restore, accepted orders and fulfilment. The runner records 43 private-schema cases; two storage cases create their own disposable databases. Migration/schema comparison passed. This is a focused PostgreSQL selection, not a full PostgreSQL run.
- **Browser: 107 passed and one timing failure in the first full 108-scenario run.** The failing email-format test could assert old content before refresh replaced the review, then attempt to scroll a detached element. It now waits for both review/history responses and the loading indicator to clear, reopens refreshed details and checks both preserved message sources. **Both email-format tests passed on the focused rerun**, covering the previously failing case. Thus all 108 distinct scenarios have passing evidence across the two runs; there was no second full-suite run. The 390px screenshot was inspected and remained readable without horizontal overflow. No application behavior was changed to accommodate this test.
- **Web/mobile typechecks and all 21 shared contract tests passed.** Production web build and both iOS/Android JavaScript bundle exports passed. Native exports are unsigned and not physical-device checks.
- **Compose/Caddy, private model overlays and standalone production-web smoke checks passed**, including page/assets, secure cookie flags, origin rejection and authenticated API proxy against a synthetic local API. No Linux image/container startup or model download occurred.
- **Fresh npm audit:** web/contracts/root selection has zero advisories. Full workspace retains 15 high affected dependency entries from the two previously documented Expo/Metro advisory sources, zero critical. Dependencies/lockfile were not modified; mobile remediation remains open.

Initial browser/standalone attempts hit the sandbox's loopback restriction; authorized reruns used isolated local test servers. Browser startup also correctly refused to share Next's build directory with the existing web preview, which was paused and restored after browser checks/build. These environmental attempts were not counted as passing test results. Existing Starlette/HTTPX, PDF fixture and Node module/color warnings remain non-failing. The deliberately duplicated ZIP fixture emits its expected warning.

The next immutable source candidate is `pilot-20261015-04`, with a source manifest and adjacent checksum; the prior three candidates remain intact. Private audit/build/browser/SQL logs are retained under `.local/release-*-20261015.*`. No runtime API, UI, schema, existing credential/account or public PHP website change was made. Build outputs and synthetic e2e state are local only. Remaining gates are actual Linux builds/startup, deployed network/security/load/restore checks, staff/model acceptance, mobile dependency remediation, signing and physical devices. See [DEVOPS-HANDOVER.md](DEVOPS-HANDOVER.md) and [RELEASE-READINESS.md](RELEASE-READINESS.md).

## 2026-10-15 — Container-ready reviewed assistant comparison (Phase 6 milestone 18)

Added `phonebuzz.assistant_benchmark` to the packaged API modules and moved the laptop assistant-feedback evaluator onto the same implementation. It uses the existing private loopback/Compose model transport and validated digest identity, replacing the assistant wrapper's dependency on an extraction evaluator's loopback-only helper. The extraction evaluator itself is unchanged. No new endpoint, database schema or UI behavior is introduced.

The explicit operator command compares baseline and approved-example routing on active-administrator-reviewed holdouts, alternating arm order. It checks the frozen dataset/example snapshot and model identity before and after each inference and before producing results. Changed or unavailable provenance discards partial scores. Empty holdouts generate no model request/score; inference failures remain counted and return a nonzero exit. A completed measurement does not approve teaching or certify quality. Model requests already in flight cannot be recalled by a later review change.

Every snapshot transaction is database-enforced read-only. The standalone SQLite connection requires an existing file and `mode=ro`, preventing accidental creation. Configuration/import/SQL/provider failures are sanitized, including malformed database URLs. Reports omit question/answer/source text and private diagnostics, preserving IDs, versions, hashes, timings and metrics only. No model training, teaching activation or database write occurs.

Validation:

- **63 SQLite/pure cases passed, 1 PostgreSQL-only case skipped** across assistant benchmark, existing feedback and shared model-hosting tests. This includes **22 new benchmark cases** for read-only enforcement, both private destinations, provider/host/limit refusal, empty holdouts, redaction, model changes at multiple checkpoints, withdrawn examples, counted failures, no-example comparisons, alternating arms, original flag preservation, safe SQLite filenames/no creation and explicit CLI opt-in.
- **43 cases passed** through the isolated PostgreSQL 17.11 runner before the final pure CLI-redaction case was added: 22 cases used private schemas, including actual read-only transaction enforcement and concurrent review protection. Migration/schema comparison passed. The subsequent change only moved configuration-sensitive imports inside the error boundary; the complete 63-case local selection passed afterward.
- The existing Qwen3 4B was started temporarily on loopback with cloud features disabled. The disposable four-question synthetic comparison completed with **baseline 3/4, assisted 4/4**, one improvement, zero regressions and zero inference failures. Digest: `359d7dd4bcdab3d86b87d73ac27966f4dbb9f5efdfcc75d34a8764a09474fae7`. Its private report is `.local/assistant-feedback-evaluation-6abc732d184f46e39ff0bbad674cf9f0.json`. The model process was stopped and the temporary database removed afterward. This small previously used fixture is integration evidence, not independent real staff accuracy or weight training.

The next immutable server-source candidate is `pilot-20261015-05`; it automatically includes the new API module. Earlier packages remain unchanged. No preview account/business data, private configuration, public PHP site, live integration or feature activation was changed. Client builds/full browser regression were not repeated because there are no UI/contracts changes; the previous milestone's dated results remain in this ledger. Linux image execution, hosted evaluation, representative staff material, acceptance thresholds, signing/device testing and mobile dependency remediation remain open. See [ASSISTANT-BENCHMARK.md](ASSISTANT-BENCHMARK.md).

## 2026-10-15 — Container-ready supplier extraction comparison (Phase 6 milestone 19)

Added `phonebuzz.extraction_benchmark` to the API image sources and made the laptop extraction evaluator delegate to it. Both model identity and extraction use the shared validated private transport. Database snapshots use enforced read-only transactions; standalone SQLite connections require existing files and use `mode=ro`. Entire-holdout conversation/duplicate exclusion remains intact, including holdouts outside the selected limit.

Dataset/example and model identities are checked before/after every arm and before reporting. Changed/unavailable provenance discards partial scores. Empty holdouts/examples make no model requests and return explicit nonzero statuses. Inference failures remain in field/item-count denominators and return nonzero. Timings exclude surrounding provenance checks; arms alternate. Reports contain metrics/identifiers, not supplier values, credentials or raw provider diagnostics. The command does not activate AI/teaching or train weights.

Validation:

- **92 focused SQLite/pure checks passed** across extraction benchmark, learning metrics/review/worker, local extraction transport, model hosting and assistant benchmark. New coverage checks frozen-review/model changes, alternating arms, disabled flags, empty datasets, failure denominators/redaction, private loopback/Compose transport, real read-only enforcement and CLI opt-in/configuration failures. Existing partition isolation now also checks selection with limit one.
- **41 checks passed** through isolated PostgreSQL 17.11; **14 used private disposable schemas**. Migration/schema comparison passed. This includes extraction read-only enforcement and reviewed-example partition isolation. The first runner attempt could not start a socket inside the sandbox; the authorized local rerun passed and shut down its temporary server.
- These are synthetic tests and mocked HTTP transport, not a new real-model accuracy run. Existing Starlette/HTTPX deprecation warning remains non-failing. No UI/contracts/schema change required new browser/mobile builds; earlier dated evidence remains separate.

Candidate `pilot-20261015-06` includes the API module and operator guide; previous packages remain intact. Package verification and extracted-source/database smoke evidence are retained adjacent to the archive in `evaluation-package-check.json`. No preview accounts/business records, private settings, public PHP files or live integrations were changed. Actual Linux image execution, hosted performance/acceptance, representative supplier samples, agreed thresholds, mobile dependency remediation, signing and physical-device checks remain open. See [EXTRACTION-BENCHMARK.md](EXTRACTION-BENCHMARK.md).

## 2026-10-16 — Combined offline release check (Phase 6 milestone 20)

Added `scripts/check-release.py` and [RELEASE-CHECK.md](RELEASE-CHECK.md). The explicit operator command checks a bounded, trusted archive copy before extracting, compares extracted source, starts an isolated clean-environment subprocess and verifies every installed API dependency against the archive's lock. It then migrates disposable SQLite, checks both evaluators reject empty holdouts without database changes, runs the archived 15-checkpoint staff/coordinated-recovery rehearsal, rechecks source and removes temporary assets. The private receipt records source/ZIP hashes, migration identity, Python/OS and fixed checkpoints, with hosted/staff/model-accuracy acceptance explicitly false.

**62 focused checks passed** across the new release checker, existing pilot rehearsal and staging packaging. Coverage includes exact-archive execution with hostile inherited configuration and preserved existing files, locked dependency mismatch, required opt-in, report overwrite refusal, incorrect checksums, malformed/incomplete/failed child results, timeout handling, wrong schema, network attempts, post-execution source drift, coordinated restore damage and archive safety. New optional-tool packaging preserves verification of older archives. Starlette/HTTPX deprecation and intentionally duplicated ZIP fixture warnings remain non-failing. A transient syntax error during implementation was corrected before the complete passing run.

No application endpoint, UI, schema or production configuration changed. This tool deliberately rehearses disposable SQLite; PostgreSQL, browser and mobile results were not rerun or reclassified as current evidence. It uses synthetic fixtures and does not contact a real model. Connection blocking/clean configuration is not an operating-system sandbox for hostile archived code; an operator must supply a trusted reviewed release.

Candidate `pilot-20261016-01` includes the checker and operator guide. Its final private receipt is retained next to the ZIP as `offline-release-check.json`; earlier release archives remain intact. Actual Linux image build/startup, hosted network/security/load and coordinated PostgreSQL restore, representative AI acceptance material, signed physical-device testing and staff sign-off remain open. No live integration, email, training, promotion or deployment was activated.

## 2026-10-16 — Mobile server/session isolation (Phase 6 milestone 21)

Found the mobile client persisted a bare token under a global SecureStore key and reused it after changing `EXPO_PUBLIC_API_URL`. Added normalized origin validation and a versioned origin/token envelope. Legacy, malformed, different-host/protocol/port and unsupported-version records are discarded. Both JSON and binary request paths use the shared session state and reject invalid production origins before network calls. Existing development apps must sign in again; no server account/password or database changed.

SecureStore operations are serialized and guarded by a revision counter. Clear drops memory access immediately; delayed restore/save cannot revive it. Storage errors are sanitized. Workspace invalidation now clears visible account/business panels even if deletion fails, including the system-health panel. A native storage deletion failure still requires device/operator follow-up; successful physical deletion is not inferred.

Validation: **33 mobile tests passed**, including request-path integration with mocked native adapters, URL rejection/canonicalization, old/foreign session cleanup, storage failures and delayed operation races. **21 contract tests**, web/mobile **TypeScript checks**, and both **iOS/Android Hermes exports** passed. Exports used offline Expo mode and do not prove a real server connection, native credentials, signing or device behavior. Existing Node experimental/module warnings remain non-failing. No backend/browser suite was rerun for these native-only behavior changes.

Registry metadata and npm audit were refreshed after sandbox DNS failures: latest braces/node-forge remain 3.0.3/1.4.0; **15 high, zero critical affected entries** remain. No dependencies or lockfile changed, and no audit suppression was applied. Current private audit evidence is `.local/dependency-audit-20261016-current.json`; the initial failed audit is not evidence of dependency health. Details: DEPENDENCY-REVIEW.md.

Server candidate `pilot-20261016-02` refreshes source/documentation identity and retains its own `offline-release-check.json`. As before, server ZIPs exclude the actual mobile source/bundles, which stay in `apps/mobile`; an installed app needs a later signed mobile build. Hosted execution, physical-device/Keychain/Keystore validation and mobile advisory remediation remain open. See MOBILE-SESSIONS.md. No deployment, live integration, signing or training occurred.

## 2026-10-16 — Mobile build profiles and input preflight (Phase 6 milestone 22)

Added dynamic Expo configuration, proposed separate development/preview/production names/identifiers/schemes, explicit EAS environments and standalone internal/simulator/store profiles. Removed the unusable development-client placeholder (expo-dev-client is absent) and empty submit profile. Production retains the existing proposed identifier and uses explicit remote version counters. No package dependency or lockfile changed.

Extracted the runtime server-origin validator into a shared JS module with TypeScript declarations, also used during build configuration. Named builds require a valid HTTPS origin and operator-supplied project UUID, reject mismatched/unknown profiles and cannot bypass release checks through a false local flag. Local Expo Go remains available; explicit local release exports enforce HTTPS. Static stale project identities are removed. The read-only mobile preflight returns sanitized missing-input errors and never reports signing/server/build verification.

**57 mobile tests passed**, including all previous session coverage and new profile, environment, malformed-input, private-value redaction, CLI and actual Expo config-resolution checks. **Web/mobile TypeScript checks passed**. **Both iOS/Android Hermes exports passed** with preview variant, explicit release mode, a reserved synthetic HTTPS endpoint and dotenv/telemetry disabled. The actual unconfigured preflight correctly returned `blocked`, not a claimed ready app. Existing Node warnings remain non-failing. No browser/API/full-platform regression was repeated for these mobile-only configuration changes.

Candidate `pilot-20261016-03` updates server documentation identity and receives its own offline-release receipt. Mobile source/build tools remain in the local mobile checkout and are excluded from server ZIPs. No Expo account/project registration, native compilation, build upload, signing, store submission, live connection or model training occurred. Real identifiers/project ownership, source-upload inspection, developer accounts, hosted TLS, upstream mobile dependency fixes and physical-device acceptance remain open. See MOBILE-BUILDS.md.

## 2026-10-16 — Clean mobile package and pilot hardening (Phase 6 milestone 23)

Completed a larger local preparation batch while hosting/live tests remain deferred:

- A separate mobile source allowlist, deterministic archive/manifest/checksum verifier, source comparison and supplemental EAS exclusions. Candidate `mobile-20261016-01` contains 97 selected files and no API implementation/private settings. A fresh extraction installed 583 locked packages offline with lifecycle scripts disabled, passed mobile TypeScript and exported both iOS/Android Hermes bundles using a reserved synthetic HTTPS origin. Source comparison still matched after installation/export. The adjacent private `local-validation.json` records source/archive/bundle hashes; it is not a signed native build or device test.
- Bounded local ClamD INSTREAM integration before attachment/import/email-file parsing/retention and again on stored downloads. Production file operations fail closed without scanning. A separate explicit clean/EICAR operator probe and optional Unix-socket Compose overlay are prepared. Tests use synthetic scanner replies, not a real installed engine/signature database. Scanner deployment/freshness/detection acceptance remains pending.
- Atomic database-backed global/account sign-in admission before password verification, including concurrent request tests and sanitized database failures. Defaults are 120/30 attempts per calendar minute; failed-password/MFA controls remain independent. Migration `31c8b020d6a1` adds only ephemeral counters.
- Bounded API body handling and web authentication/proxy streaming, including actual-byte counting, malformed/lying lengths, disconnected streams, deadlines and sanitized errors. The web sign-in proxy retains numeric Retry-After. Existing file caps, role checks and same-origin restrictions are preserved. See PILOT-HARDENING.md for exact limits and operational caveats.

Validation recorded for this batch:

- **Full backend: 1,066 passed, seven PostgreSQL-only skips.** The earlier run exposed a worker-drill assertion that classified the new operational counters as business data. The drill now snapshots the exact post-login counters and confirms they remain unchanged while continuing to reject any business writes. The complete final run passed; no existing business-data assertion was removed.
- **PostgreSQL 17.11:** 71 checks passed in the first focused file/login/MFA selection (50 schema-backed); 51 passed in the final request/login/scanner/recovery selection (14 schema-backed); the seven SQLite-skipped concurrency, restricted-role and populated-migration/restore checks passed separately. Four of those use the schema fixture and three own isolated databases. These overlapping selections are not added into a unique test total. Fresh migration/schema comparison passed in each runner and each local cluster was stopped afterward.
- **68 focused scanner/login/package tests passed**, including archive corruption/exclusion, exact scanner verdicts, fragmented/trailing responses, disabled-production refusal, rejected upload/import non-retention, old-download re-scan, probe false positives/negatives and concurrent admission. Later request-handling selections are covered by the final full run.
- **12 Node web-stream/handler tests**, **57 mobile tests**, **21 contract tests**, web/mobile TypeScript and the production web build passed. Both mobile exports above were built from a clean extracted package, without connecting to a server or signing account.
- Compose/Caddy validation, the new scanner overlay and the built standalone web smoke passed. The smoke verifies production cookie flags, origin protection, assets and authenticated proxying with a synthetic local API; it does not start Linux containers.

The first browser run passed 107 of 109 scenarios. The new malformed-body fixture was accidentally JSON-encoded by Playwright and was corrected to raw bytes. A warehouse scenario correctly hit the new account allowance because automated helpers repeatedly sign into the same fixture account; only the isolated browser-server configuration now uses 1,000 global/200 account attempts per minute. Production defaults remain 120/30, with separate SQLite/PostgreSQL budget enforcement tests. The complete corrected rerun passed **all 109 browser scenarios** in Chrome, including the actual web route rejection checks and warehouse workflow. No application limit was raised to accommodate the harness.

Before local migration, private backups of development and preview databases were taken. Exact values in all 58 pre-existing tables in each database, plus the preview credential file, were preserved; the new counter table started empty. SQLite integrity/foreign-key checks and Alembic comparison passed. No public PHP files, live accounts, mailbox credentials or business records were changed.

Server candidate `pilot-20261016-04` is the matching immutable server-source package; it excludes mobile implementations and private local data. Its exact-archive offline release receipt is retained alongside the ZIP. Previous candidates remain intact. Local scanner tests/probes, source checks and bundle exports do not close hosted security/load/recovery, upstream mobile advisories, real scanner signatures, physical devices, staff acceptance or representative AI evaluation. No external message, live integration, training/promotion, deployment or signing occurred.


## 2026-10-17 — Actual application email handoff (Phase 3 milestone 16, during Phase 6 preparation)

Connected final sealed approval bytes to the application's existing `email_attempts` and `email_attempt_events` through an internal service. It requires matching immutable approval/index/snapshot evidence, current session/access/context, a fresh approval and no unresolved attempt. Exact MIME serialization reuses the retained Message-ID/Date rather than generating a new identity. Claim retry identity, a pre-transport durable handoff fence, a final body gate, fenced completion and preserved uncertain/accepted evidence prevent silent replay.

The new development command `scripts/check-email-handoff.py` exercises actual records and the existing administrator review API in a clean, disposable migrated database. It uses only fixed synthetic envelope addresses and a fake Unix-socket SMTP peer. The prior prototype and network-free simulation remain separate. The application has no dispatcher route, live transport, activation flag or queue consumer for this service; approving a message still creates no real attempt.

Validation:

- **Full backend: 1,104 passed, seven PostgreSQL-only skipped**, with the existing non-failing Starlette/HTTPX, deliberately unsafe PDF fixture and duplicate-ZIP fixture warnings. This includes the 38 new application-handoff tests and all existing formatting, reply matching, history/recovery and prototype regressions.
- **Focused PostgreSQL 17.11 selection: 103 passed**, including **79 private-schema cases**, across application handoff, MIME formatting, attempt review and outbound approval. Fresh migration/schema comparison passed, and the owned local cluster was stopped afterward. The first sandbox attempt could not open its loopback port; the authorized rerun passed. This selection does not claim to rerun all seven full-suite skips; their earlier dated PostgreSQL evidence remains separate.
- **Independent rehearsal: all 13 checkpoints passed**, including STARTTLS/implicit TLS outcomes, actual administrator recovery/review and real subprocess exits after claim, before peer contact and after fake acceptance. Separate fake-peer evidence confirms acceptance before the last forced exit. The report `.local/email-handoff/rehearsal-20261016T193521Z-6d993cdb.json` records schema `31c8b020d6a1`, zero attempted external connections, disabled live sending, unverified delivery and temporary-database cleanup. The UTC filename precedes this Asia/Karachi date. Later expanded/full tests repeated the CLI against final code.
- Tests include altered/missing final identity, immutable-history/index disagreement, concurrent claims and dispatch, claim/handoff/completion database failures, lost sessions, mailbox/access/draft changes, paused pre-body recovery, preserved acceptance after context changes, wrong/empty tokens, early/expired recovery, same-approval refusal, fresh reviewed revisions, populated-database refusal, inherited-secret isolation, rejected live-target arguments and incomplete-report refusal. Updated local documentation links passed.

No database migration, preview/development business-data change, credential update, public PHP change or web/native contract/source change occurred. Browser/client builds were not rerun; the prior dated evidence remains in this ledger. The new serializer keeps the existing MIME output and is covered by the full backend regression. The rehearsal holds conversation/account locks across bounded synthetic I/O; production latency, overall transport deadlines and operational supervision remain design/acceptance work.

Server candidate `pilot-20261017-01` contains the inactive application module and current guides, with exact-archive source comparison and the 15-checkpoint staff/recovery release receipt retained beside it. The development-only SMTP rehearsal scripts/tests are deliberately excluded from server-source packages. Prior server/mobile packages remain intact. No live message, hosted deployment, signing, model training or feature activation occurred. Next: production transport and private activation design with offline checks, while provider tests, hosting and physical-device acceptance remain deferred. See [EMAIL-HANDOFF.md](EMAIL-HANDOFF.md).


## 2026-10-17 — Private SMTP transport and pilot authorization (Phase 3 milestone 17, during Phase 6 preparation)

Added `phonebuzz.smtp_transport` and the internal `Handoff.dispatch_smtp` bridge. The provider-capable transport requires a second owner-only policy bound to the exact SMTP settings, a UTC expiry within 24 hours and a bounded exact recipient allowlist. No setting was activated, private file created, SMTP credential read from the real environment or send endpoint/worker added. The existing offline configuration validator is shared without changing its redacted report contract.

The invocation checks exact private-file bytes before connecting, before authentication and at the final body gate. It validates sealed MIME/envelope/digest before I/O, resolves A/AAAA within a shared lifetime, rejects unsafe/mixed/excessive destinations, connects to one numeric address and verifies TLS/hostname with TLS 1.2 minimum. It chooses one advertised PLAIN/LOGIN mechanism and never retries a connection, alternate address, credential or message. The 20-second monotonic network budget, three-second operation/reply limits and bounded byte/line parser cover trickled replies. Filesystem pauses and database locks are not claimed to have hard process deadlines.

The offline `--check-policy` CLI has no send operation. It reports fixed states without private values. An early focused run caught database initialization during module import, before the CLI's sanitized error boundary; the result could expose synthetic configuration diagnostics. The transport result type is now imported only during actual dispatch, keeping offline inspection independent of database startup. The complete 109-case transport selection then passed, including malformed-settings redaction; the full backend run also passed the corrected CLI case.

Validation:

- **Full backend: 1,220 passed, seven PostgreSQL-only skipped.** This includes 109 new transport/policy cases and seven provider-to-ledger integration cases, plus all existing approval/history/recovery/prototype, migration and package tests. Existing Starlette/HTTPX, deliberately unsafe PDF fixture and duplicate-ZIP fixture warnings remain non-failing.
- **Focused transport/policy selection: 109 passed** after the CLI correction. Both TLS modes, PLAIN/LOGIN, unsupported STARTTLS/authentication, untrusted/wrong-host certificates, all major SMTP refusal/disconnect stages, malformed final acknowledgements, unchanged sealed bytes, expired/disabled/changed policy, password rotation, final-gate refusal, partial body writes, preserved acceptance after gate-cleanup failure, private-file safety, no-secret reports and rejected send arguments are covered. Mocked DNS/socket cases check forbidden addresses, mixed answers, limits, lifetimes, one numeric destination and failed-connection cleanup. Socket-pair tests exercise real TLS and SMTP parsing without a provider connection.
- **PostgreSQL 17.11 integration selection: 88 passed**, including **41 private-schema cases**, across the new bridge, actual handoff ledger and existing private preflight. Fresh migration/schema comparison passed and the owned cluster stopped afterward. The first sandbox attempt could not bind its loopback port; the authorized rerun passed. This is not a rerun of all seven backend skips; earlier PostgreSQL-only results remain separately dated.

No migration, public website edit, live database/account/password change, client contract/UI change, live integration, model training or signing occurred. Browser/mobile builds were not repeated; previous dated evidence remains separate. Schema head remains `31c8b020d6a1`. The new `PB_OUTBOUND_POLICY_FILE` setting defaults to unset, and the blank development policy stays disabled. The real application's routes and worker do not invoke the internal dispatch bridge.

Candidate `pilot-20261017-02` packages the inactive transport and updated operator guides. Exact source comparison and the extracted 15-checkpoint staff/recovery release receipt are retained beside the immutable ZIP. Development SMTP peers/tests and blank private-file templates stay excluded; the new guide contains the complete policy structure. Previous candidates remain intact. Next is the explicit operator/staff dispatch workflow and readiness/recovery controls, while real provider testing remains deferred. Hosted egress/DNS/TLS/authentication, sender ownership, lock contention, operational supervision and delivery acceptance remain open. See [SMTP-TRANSPORT.md](SMTP-TRANSPORT.md).


## 2026-10-17 — Explicit staff email dispatch (Phase 3 milestone 18, during Phase 6 preparation)

Added default-disabled GET readiness and POST dispatch endpoints, exact approved-version/MIME-digest confirmation, web/native controls and refresh of actual attempt history. Current authority, sealed approval and private policy are checked before a durable claim; handoff and the final body gate retain existing rechecks. An identical request returns its saved attempt without transport, including after interrupted claim or failed result persistence. Different keys cannot reuse the approval. The prepared staging stack explicitly keeps `PB_OUTBOUND_DISPATCH_ENABLED` false. No queue or automatic resend was introduced.

Validation:

- **Full backend: 1,247 passed, seven PostgreSQL-only skipped.** This includes 27 new dispatch cases plus prior handoff, policy, review, migration and packaging checks. Four non-failing warnings remain: Starlette/HTTPX, two intentionally unsafe PDF fixtures and the duplicate-ZIP fixture.
- **Focused API selection: 90 passed.** Dispatch input/role/readiness, stale approval/policy/digest, concurrent requests, real synthetic TLS acceptance/rejection/uncertainty, interrupted claims, failed completion persistence and final-gate revocation are covered. No provider is contacted.
- **PostgreSQL 17.11 selection: 65 passed**, including **60 private-schema cases**, across dispatch and application handoff. Fresh migration/schema comparison passed; the owned local cluster stopped afterward. The first sandbox bind failed; the authorized local rerun passed. This selection does not claim to rerun all seven backend skips.
- **Browser: three new dispatch scenarios passed**, then passed again with final phone-width captures. The separate enabled fixture uses the actual API/ledger with a synthetic transport and blocks external connections. It covers exact confirmation, literal content, one attempt, history refresh, lost-response handling without replay, readiness errors, viewer restrictions and same-origin protection. **All 13 focused existing approval/format/attempt/simulation/preflight scenarios passed** under the normal disabled fixture. The complete 109-scenario historical browser suite was not rerun for this change. An initial visual-only selector matched no test; the corrected three-case run passed. The phone-width readiness screenshot was visually inspected and the post-dispatch scenario checks for horizontal overflow.
- **Shared contracts: 21 passed; mobile guards: 58 passed.** Native timeout coverage verifies one aborted dispatch request with history guidance and no replay. Web/native TypeScript checks, production Next build, and unsigned iOS/Android Hermes exports passed. Exports used offline mode and a synthetic HTTPS origin; no signing/upload/provider call occurred.

The OpenAPI snapshot includes both dispatch operations. Schema remains `31c8b020d6a1`; no migration, preview/development business-data change, real credential read/update, public PHP edit, live activation, model training or device signing occurred. Review/history `sending_enabled` now reflects the runtime switch, and review delivery status becomes conservatively unverified after an attempt. The switch alone never grants per-message readiness.

Server candidate `pilot-20261017-03` and mobile source candidate `mobile-20261017-01` retain this implementation. Exact source-comparison reports and the server's extracted offline staff/recovery receipt are retained beside their immutable ZIPs; prior candidates are preserved. Mobile source verification and local exports are not a new clean-install or signed-device acceptance claim. See EMAIL-DISPATCH.md for operator controls and recovery. Hosted load/process shutdown, real provider interoperability/delivery, incoming bounce reconciliation and physical-device acceptance remain open; live provider testing remains explicitly deferred.


## 2026-10-19 — Incoming delivery reports and bounce evidence (Phase 3 milestone 19, during Phase 6 preparation)

Added a bounded structured DSN parser, atomic mailbox/report retention, exact sealed-message/recipient/mailbox/attempt correlation, unverified outcome summaries and original-source inspection on web/native. Reports stay in separate inbox conversations and never mutate SMTP outcomes, approvals, customer conversation versions, recovery states or retry authorization. Success/failure contradictions stay visible even after newer delay reports. Byte-identical duplicates retain the existing one-import behavior.

Validation:

- **Full backend: 1,286 passed, seven PostgreSQL-only skipped.** Existing four non-failing Starlette/HTTPX, unsafe-PDF fixture and duplicate-ZIP fixture warnings remain. This run includes 39 new delivery-report cases. A final returned-header count cap and one additional rejection case followed; the final focused selection passed **40 tests**. The entire backend was not repeated after that narrow parser bound.
- **PostgreSQL 17.11 selection: 70 passed**, including **35 private-schema cases**, across delivery reports and reply matching. Migration to `42d9c131e7b2` and schema comparison passed. The owned cluster was stopped afterward. The initial sandbox run could not bind its loopback port; the authorized rerun passed. The final header-only parser cap is covered by the subsequent focused parser run and does not change SQL. The seven full-suite skips retain their earlier separately dated evidence.
- Parser cases cover both original-header formats, all five actions, status-class consistency, duplicate/missing/ambiguous fields, unsupported types, original-recipient conflict, multiple recipient blocks, oversized diagnostics, returned-header count, ordinary/nested message exclusion and literal malicious-looking text. API/import cases cover original source visibility to viewers, unauthenticated rejection, no-attempt/claimed/rejected/tampered/mismatched evidence, uncertainty preservation, conflicts beyond the latest-20 display limit, byte-identical duplicates, transactional rollback/retry and a previous-schema populated-user migration with all old table rows unchanged. Populated evidence blocks destructive downgrade.
- **Browser: two new delivery-report scenarios passed**, including phone-width literal diagnostics and source provenance, conflict refresh without SMTP-state changes, stale-content removal on failed refresh, unsupported-source visibility and viewer controls. **Five existing attempt-history/mailbox scenarios passed** in their fresh baseline fixture. The initial combined run passed both new cases and three attempt cases but failed two mailbox count assertions because new report imports changed shared fixture totals. A dedicated delivery-report configuration isolates those imports; both groups then passed without relaxing the original assertions. The final phone screenshot was visually inspected, and the scenario checks horizontal overflow. No new full-browser run is claimed.
- **21 shared-contract and 58 mobile guard tests passed.** Web/native typechecks, production Next build and unsigned iOS/Android Hermes exports passed. Native exports used offline mode and a synthetic HTTPS endpoint. The OpenAPI snapshot is updated. No signing, external upload or actual provider transport was used.

The new table stores only newly imported evidence. No real database, account/password, private integration setting or public PHP site was changed. Existing local preview/development databases were not upgraded; back up and apply the included migration before running the new API/worker against an existing database. No historical delivery claim was inferred, provider activated, report automatically trusted, model trained or real message sent.

Server candidate `pilot-20261019-01` and mobile source candidate `mobile-20261019-01` contain this implementation. Their exact source-comparison receipts and the server archive's offline workflow/recovery receipt are retained beside the immutable packages; earlier candidates remain intact. This is local source and synthetic validation, not Linux image, hosted capacity, live provider, signed-device or staff acceptance. See DELIVERY-REPORTS.md. Next local extension: administrator triage and investigation notes for unverified/conflicting reports; provider acceptance remains deferred.


## 2026-10-20 — Delivery investigation notes and review tracking (Phase 3 milestone 20, during Phase 6 preparation)

Added administrator investigation notes and review status on web, iOS and Android, with read-only staff history. Notes are append-only and bound to the exact current report evidence. New evidence reopens attention; stale versions/evidence are refused. Identical explicit retries reuse one command, and changed payloads with an existing key are rejected. Report imports and note writes serialize on the attempt row. Investigation notes do not verify delivery, remove conflicting reports, change the SMTP outcome or grant resend permission.

Validation:

- **Full backend: 1,313 passed, seven PostgreSQL-only skipped, four existing non-failing warnings.** Focused investigation/report selection: **66 passed**, including 26 new investigation cases. Authorization, current-session recheck after locking, stale evidence, concurrent reviews, rollback, duplicate requests, pagination and bounded report snapshots are covered.
- **PostgreSQL 17.11 selection: 93 passed**, including **64 private-schema cases**, across investigation, report and explicit dispatch tests. Migration/schema checks passed; the owned local cluster stopped afterward. An initial sandbox loopback bind failure was followed by an authorized successful run. This selection does not claim to repeat every skipped full-suite PostgreSQL case.
- **Four delivery/investigation browser scenarios and five existing attempt/mailbox regression scenarios passed.** These cover administrator/viewer roles, cross-origin refusal, new evidence, stale saves, explicit retry after a lost response, failed refresh, session expiry and narrow-screen layout. The final investigation screenshot was visually inspected after improving field spacing and sizing; horizontal overflow checks passed. This is focused browser coverage, not the entire browser suite.
- **21 shared-contract tests, 58 mobile guards and both client TypeScript checks passed.** The production web build and both unsigned Hermes exports passed using a synthetic HTTPS origin. Native exports do not establish signed builds or physical-device acceptance.
- Migration **`53eac242f8c3`** adds only the investigation table/index. The populated migration test preserves previous table data and rejects downgrade when notes exist. OpenAPI was refreshed. Existing preview/development business databases were not migrated; back up before applying the new migration on a deployed environment.

Server candidate `pilot-20261020-01` and mobile candidate `mobile-20261020-01` carry this source. Their exact-source comparison and verification receipts are stored adjacent to the immutable archives; the server candidate also receives an extracted offline staff/recovery and evaluator check. Consult those receipts for package results. Prior packages remain intact.

No public PHP change, live provider test, email send, credential update, production deployment, signing or model training occurred. Live integrations remain disabled. Next local extension: a central staff attention queue for attempts and delivery reports that need investigation. See [DELIVERY-INVESTIGATIONS.md](DELIVERY-INVESTIGATIONS.md).


## 2026-10-20 — Central email attention queue (Phase 3 milestone 21, during Phase 6 preparation)

Added a read-only queue in the shared inbox on web, iOS and Android. It combines new/unreviewed linked reports, investigations in progress, uncertain attempts and expired claims, with current conversation-assignee filters. Closed conversations remain visible. Count and paginated summaries share one SQL statement snapshot; reviewed report work and unresolved SMTP state remain independent. Exact-attempt filtering opens the selected older attempt directly through the existing guarded forms. Returning to the list refreshes its membership, protects unsaved notes and is disabled during saves; attempt refresh is also disabled while a queue-case investigation save is pending.

Validation:

- **Full backend: 1,341 passed, seven PostgreSQL-only skipped, four existing non-failing warnings.** This includes **28 new queue cases** for all staff roles, absent authentication, no mutation/network/audit effects, report-review transitions, new evidence, uncertain state independence, expiration boundaries, closed conversations, current/inactive assignees, invalid filters, deterministic pagination, empty/out-of-range results, exact/cross-conversation attempt scope and attempts without reports. Initial focused selection passed 69 cases before seven additional no-report cases were added; the full suite includes all final cases.
- **PostgreSQL 17.11:** the initial queue/investigation/attempt selection passed **69 cases**, including **67 private-schema cases**. After adding the no-report cases, the complete final queue selection passed **28 cases**, each in a private schema. These are overlapping runs, not 97 distinct cases. Migration/schema comparison passed and the owned cluster stopped after each run. Initial sandbox loopback restrictions required authorized reruns. Existing separate PostgreSQL-only evidence remains dated; this selection does not rerun all seven full-suite skips.
- **Six delivery/investigation/queue browser scenarios passed**, including two new queue scenarios. They cover exact-attempt inspection, administrator note save and removal from the report filter, reappearance after new evidence, assignment filters, viewer read-only controls, stale-list hiding, session expiry and save-navigation/refresh protection. **Five existing mailbox/attempt-review scenarios also passed.** The phone-width queue screenshot was visually inspected and overflow assertion passed. These are focused browser selections, not a full browser regression.
- **21 existing shared-contract tests, 58 mobile guards and final web/native TypeScript checks passed.** Both final unsigned Hermes exports passed using a synthetic HTTPS origin. The final production web build passed; its output is retained in `.local/attention-web-build.log`. No signed app or physical device was tested.
- OpenAPI documents the new read-only endpoint and optional exact-attempt filter. **No migration was added**; schema head remains `53eac242f8c3`. No existing business database was migrated.

Early checks found a test audit baseline captured before a test login, synthetic fixture subjects outside the protected seeder prefix, and missing explicit filter labels for the browser locator. The test setup and accessible filter names were corrected; final cases passed. Native component prop/style mismatches were corrected before the final typecheck/exports.

Server candidate `pilot-20261020-02` and mobile candidate `mobile-20261020-02` package this source and its guides. Exact-source comparison/verification receipts are retained adjacent to the immutable archives; the server also receives the extracted offline staff/recovery and evaluator release check. Consult those receipts for package results. Previous candidates remain intact.

This index relies on append-only report retention and is not a detector for unsupported direct database edits that replace evidence without changing its count. The existing detail/save routes retain full evidence-digest and authority checks. Deployment-scale database performance, provider acceptance, hosting, physical devices, signing and representative model evaluation remain open. No live message, integration activation, public PHP change, credential update or model training occurred. Next possible local extension: separate investigation ownership and due dates. See [EMAIL-ATTENTION.md](EMAIL-ATTENTION.md).


## 2026-10-21 — Investigation ownership and deadlines (Phase 3 milestone 22, during Phase 6 preparation)

Added case responsibility on web, iOS and Android: administrator assignment to an active administrator, optional explicit UTC deadline, reasoned reassignment/clearing and immutable history. This stays separate from conversation assignment, delivery evidence and investigation status. Queue filters now include case owner, unavailable owners and overdue outstanding cases. Past deadlines can be retained during reassignment but newly changed deadlines must be in the future. Reviewed/otherwise completed work leaves attention without deleting its plan; new report work can bring the retained owner/deadline back.

Validation:

- **Full backend: 1,371 passed, seven PostgreSQL-only skipped, four existing non-failing warnings.** This includes **30 new case-plan tests**. They cover staff/admin boundaries, active target roles, current actor/session/owner rechecks after locks, strict dates and inputs, exact deadlines, independent conversation assignment, preserved SMTP state, stale versions, duplicate retry keys, no-op refusal, history paging, audit rollback, concurrent competing/identical commands and populated migration preservation. The existing 28 attention cases also pass. Focused initial selection: **58 passed**.
- **PostgreSQL 17.11 initial case-plan/attention selection: 58 passed**, including **57 private-schema cases**. After strengthening the independent target-owner role-change test, the final **30 case-plan cases passed**, including **29 private-schema cases**. These overlap; they are not 88 distinct tests. Fresh migration/schema comparisons passed and the owned test cluster stopped afterward. Initial sandbox bind restrictions required authorized loopback reruns. Earlier evidence for the seven full-suite PostgreSQL-only skips remains separately dated.
- **Eight delivery/investigation/queue browser scenarios passed**, including two new responsibility scenarios. They exercise UTC input and persisted history, assignment independent from the conversation, case-owner/overdue filters, viewer read-only access, same-origin enforcement, stale save/edit retention, explicit retry after a lost response and hiding stale data on failed reads. **Five existing mailbox/attempt-review scenarios passed** separately. The phone-width screenshot `.local/case-responsibility-phone.png` was visually inspected; overflow assertions passed. This is focused browser coverage, not a full browser-suite run.
- **23 shared-contract tests and 58 mobile guard checks passed**, including UTC round-trip/second preservation and invalid calendar normalization tests. Final web/native TypeScript checks, both unsigned Hermes exports with a synthetic HTTPS API origin, and the production web build passed. The final web build followed the browser regressions to regenerate production route type references.
- Migration **`64fbd353a9d4`** adds only the case-plan table/index. The populated migration test preserves existing user/investigation data and all earlier table rows, starts with no inferred plans, passes schema comparison and refuses a populated downgrade. Existing business databases were not migrated. OpenAPI and operator guidance were updated.

Candidate `pilot-20261021-01` packages the matching server source; `mobile-20261021-01` packages native source. Exact source-comparison/verification receipts are retained next to each immutable archive. The server receives the extracted offline staff/recovery and evaluator release check; consult its adjacent receipt for the result. Previous packages remain intact.

No hosted deployment, live provider test, real message, credential update, public PHP change, signing or model training occurred. This work does not add proactive reminders or change delivery/send permissions. The migration needs the normal backup/grant procedure when later deployed. Outstanding security/dependency remediation, hosted operational acceptance, signed physical-device checks and representative AI/business acceptance remain open. See [EMAIL-CASE-PLANS.md](EMAIL-CASE-PLANS.md).

## 2026-10-21 — Browser response protections (Phase 6 milestone 24)

Added staff web response headers preventing framing, MIME sniffing and referrer disclosure, plus restrictions on unused browser capabilities. The root document refuses base elements, plugin content and off-origin form submission. Prepared Caddy settings match the application. API attachment/PDF sandbox policies remain separate. This is a limited document CSP; script/style execution restrictions and independent security review remain open. See [BROWSER-PROTECTIONS.md](BROWSER-PROTECTIONS.md).

The dependency refresh again reports **15 high affected entries, zero critical**, representing the same **two underlying mobile-tooling advisories**; web/contracts/root selection is clear. Published braces 3.0.3 and node-forge 1.4.0 still have no patched releases listed in their advisories. No dependency or lockfile change, override or suppression was made. See DEPENDENCY-REVIEW.md for registry evidence and primary advisory links.

Validation:

- **All 112 default browser scenarios passed**, including three new enforcement scenarios. They exercise an actual differently originated loopback parent, blocked frame rendering, browser CSP violation events with zero prohibited requests, unchanged base URL, blocked capabilities, missing referrer and working staff sign-in. Existing trading, attachment, billing, order/return, assistant and security flows pass under the new headers.
- The initial frame-test parent used a synthetic intercepted response, which triggered Chrome's local-network access gate before the response policy. The test now uses a real loopback parent. A blocked form submission also left Playwright waiting for a top-level navigation; a named child target now isolates that test. All three final focused tests and the entire default regression pass. These were test-harness corrections; application restrictions were not relaxed.
- **Eight separate delivery/investigation/case-plan scenarios and three synthetic dispatch scenarios passed.** Together with the default suite, all **123 browser scenarios** passed on the final application configuration. The three earlier focused protection checks overlap with the default suite and are not added again.
- **Web/native TypeScript checks and the final production web build passed.** Compose/Caddy configuration and private model/scanner overlays validate without starting containers. The production standalone smoke passed for headers, asset MIME types, production cookies, origin refusal, authenticated proxying and retained sandbox/disposition/no-store headers on attachment and PDF downloads. Initial sandbox loopback failures were followed by authorized successful runs. Logs are `.local/browser-protections-{tests,regression,delivery,dispatch,types,build,staging}.log` plus the registry audit files noted in DEPENDENCY-REVIEW.md.

Backend and native application source did not change. The earlier same-day **1,371 backend passes**, PostgreSQL case-plan checks and unsigned native exports remain dated evidence and were not repeated for these browser headers. No new schema migration was added; head remains `64fbd353a9d4`. No existing business database was migrated.

Server candidate `pilot-20261021-02` contains the web/proxy protections and updated guides. Mobile candidate `mobile-20261021-02` refreshes the dependency review and package guide only; native implementation and dependency versions match the prior candidate. Exact verification/source-comparison and the server offline release receipts are retained beside the immutable archives; consult those receipts for package results.

No live messages, provider activation, hosted deployment, public PHP change, signing or model training occurred. Real proxy/TLS behavior, mobile upstream remediation, signed devices, operational acceptance and representative business/model acceptance remain open.


## 2026-10-21 — Per-response script authorization (Phase 6 milestone 25)

The root staff document now receives a cryptographically random 32-byte nonce for each request. Next renders the layout dynamically and attaches the nonce to its scripts; the request policy is replaced before rendering, caller nonce headers are removed, and prefetch labels do not bypass enforcement. Production uses private/no-store document responses, strict script loading, no inline event handlers or string compilation, and same-origin connections. Existing structural/response protections and independent API download sandbox policies remain intact. See BROWSER-PROTECTIONS.md.

Inline CSS remains allowed for Radix inline styles and runtime scroll-lock styles. Development retains the framework-required eval and loopback HMR allowances; these are absent from the production policy. This does not claim elimination of XSS, a complete style lockdown or independent security acceptance. Dynamic page rendering and actual proxy/CDN behavior require hosted capacity/configuration checks.

Validation:

- **112 default workflow scenarios passed**, with **four production-only script cases explicitly skipped in that profile**. **Eight delivery/investigation/case-plan scenarios and three synthetic dispatch scenarios passed** separately. These development-mode runs cover the existing UI and API workflows under the new policy.
- **All seven production browser protection scenarios passed** against a disposable standalone build. Four new cases verify fresh nonce/header/HTML agreement, hostile caller/prefetch labels, no-store documents, refused stale/nonexistent nonces, blocked event attributes, refused same-origin/external parser-injected scripts with browser violation evidence, successful hydration/sign-in with Secure/HttpOnly cookies and refused string compilation. Three existing structural/header checks overlap the default workflow run. There are **127 distinct browser scenarios with passing evidence across these scoped runs**, not 130 independent scenarios or a full production-mode workflow run. Six development smoke cases passed separately and also overlap the default run.
- **Final production web build and web/native TypeScript checks passed.** The build confirms dynamic root rendering and proxy inclusion. The final Compose/Caddy and standalone smoke passes nonce freshness, spoof-header refusal, no production eval, no-store HTML, correct asset MIME types, production cookie flags, origin enforcement and authenticated attachment/PDF responses preserving sandbox/disposition/no-store headers.
- Early test probes inserted scripts through DevTools evaluation, which bypassed CSP for those probes. They now execute through normal HTML parsing. Development response interception also conflicted with HMR local-network checks and Next's development cache behavior; production policy probes now run only in the production profile, with normal development workflows checked separately. An attempted broader production workflow run was stopped after existing HTTP API setup helpers omitted Secure cookies and returned 401. Production cookies and application authorization were not relaxed. The full workflow suite needs an HTTPS test environment before it can be reported as production-mode coverage.
- Initial sandbox loopback restrictions required authorized reruns. Logs: `.local/script-policy-{development,regression,delivery,dispatch,production,types,build,staging}.log`. No new dependency audit was needed for this change: manifests/lockfile remain unchanged, and the earlier same-day audit still records two unresolved mobile-tooling advisory sources.

Backend/native implementation and schema remain unchanged. The earlier same-day backend/PostgreSQL and unsigned native export results remain dated evidence, not reruns for this change. Existing business databases were not migrated. Migration head remains `64fbd353a9d4`. Mobile source still exactly matches retained candidate `mobile-20261021-02`; the comparison is `.local/script-policy-mobile-comparison.json`.

Server source candidate `pilot-20261021-03` includes the new proxy, dynamic layout and operator guidance. Its adjacent checksum, source-comparison and extracted offline release-check receipts identify the exact package and verification results. Prior immutable candidates remain intact. No deployment, real email, provider activation, public PHP change, credential change, signing or model training occurred.


## 2026-10-21 — Full local HTTPS production-web regression (Phase 6 milestone 26)

Added a disposable local TLS proxy for the actual standalone production web build, a fresh one-day self-signed loopback certificate, fixed shared HTTP/HTTPS test origins and complete baseline/delivery/dispatch production profiles. Browser and separate API fixture contexts use HTTPS and accept the temporary certificate explicitly. Secure/HttpOnly/Strict cookies, same-origin checks, the enforced production script policy and download policies remain unchanged. Default HTTP development tests remain available. See [LOCAL-HTTPS.md](LOCAL-HTTPS.md).

Validation:

- **118 baseline production-web browser scenarios passed with zero skips**, including all four script-policy probes and two new HTTPS cases. **Eight delivery/investigation/case-plan scenarios and three synthetic dispatch scenarios passed** in their separate fresh-fixture HTTPS runs. Together these are **129 distinct passing HTTPS browser scenarios**, covering login/MFA/recovery, staff roles, private uploads/downloads, inventory, quotations, orders/returns, draft billing fixtures, assistant/learning, communication review and production browser controls. The API uses synthetic test configuration; this is not production API/provider/scanner acceptance.
- The HTTPS-specific cases verify a secure browser context, Secure/HttpOnly/Strict cookies, authenticated browser and API-helper requests, rejection of an HTTP downgrade in the Origin header, logout invalidation and certificate acceptance limited to explicitly configured test contexts. A fresh strict context rejects the self-signed certificate; an anonymous context that accepts TLS still receives 401 on protected resources. No system trust store or application TLS verification was changed.
- **Five HTTP development compatibility scenarios passed**, covering workspace and private evidence workflows after the shared-origin refactor. An initial **12-case HTTPS focused selection passed** and overlaps the complete suite; it is not added to the 129 total. The final production build and web/native TypeScript checks passed before the full HTTPS run. Browser collection now explicitly matches `.spec.ts`; Node/mobile unit tests retain their separate commands rather than being imported during browser discovery.
- The TLS runner restricts both proxy and backend to loopback, uses an ephemeral backend port, generates a private temporary key/certificate and requests graceful process cleanup. The final resource check found **zero new temporary production directories remaining**; previously existing temporary directories were left untouched. Evidence: `.local/https-cleanup-check.json`. No real provider requests or real messages were part of these suites.
- The first sandbox run could not bind the synthetic API port; the authorized rerun succeeded. No application regression or runtime fix was needed. The earlier HTTP-only production-helper limitation is now resolved by the HTTPS test environment, without relaxing Secure cookies or changing authorization. Logs: `.local/https-{focused,development-compatibility,build,types,regression,delivery,dispatch}.log`.

Production application, backend/native code, dependencies and schema are unchanged from the prior candidate. Exact-source comparison with `pilot-20261021-03` found only updated/new deployment guidance among packaged sources; test infrastructure stays in the full development checkout. Earlier API/PostgreSQL/native-export/dependency evidence remains dated; these suites were not repeated for test infrastructure. Migration head remains `64fbd353a9d4`; existing business databases were not migrated. Mobile candidate `mobile-20261021-02` remains current.

Refreshed server candidate `pilot-20261021-04` packages the unchanged application plus current HTTPS/readiness guidance. Its adjacent source-comparison and offline release-check receipts record the exact archive verification. The deployment ZIP excludes test certificates, keys, fixtures, logs and browser tooling. Prior candidates remain intact.

This milestone closes the local full production-web HTTPS regression gap. It does not close real DNS/certificate renewal, deployed Caddy/firewall behavior, Linux-image startup, PostgreSQL/scanner operations, capacity, coordinated hosted recovery, live delivery, signed devices or staff/business/model acceptance. No deployment, public PHP change, credentials update, real email, signing or model training occurred. The two previously recorded mobile-tooling advisory sources remain unresolved; no fresh dependency change or audit is claimed here.

## 2026-10-22 mobile dependency re-review

Successful registry audits: full workspace 15 high affected entries/zero critical from the same two advisory sources; web/contracts/root selection zero findings. Published versions, advisory patched-version fields and supported Expo parent dependency metadata were reviewed (DEPENDENCY-REVIEW.md). No supported fix was identified. Application code, manifests and lockfile are unchanged; no regression/build result is newly claimed by this review.

The source candidates `pilot-20261022-01` and `mobile-20261022-01` refresh documentation only. Their adjacent checksum, source-comparison and offline-release-check receipts are the authority for package verification results; the latter exercises isolated API/recovery/evaluator integration only. Hosting, real integrations, mobile signing/devices and mobile security approval remain pending. Phase 6 milestone 26 remains the latest completed engineering milestone.

## 2026-10-22 cPanel deployment preparation

Added a standalone Compose alternative for the existing Apache/TLS host, a private settings/Apache snippet generator and CPANEL-DEPLOYMENT.md. Existing API/web Dockerfiles and application code are preserved. No application migration was added. 54 focused cPanel/setup/package checks passed. A disposable local Apache HTTP harness passed proxy, allowlist/spoofed-header, response-header, redirect and certificate-validation checks. This is not actual cPanel/TLS or Linux-container acceptance. The target account reports Docker daemon permission denied, while Compose 2.27.0 and occupied 80/443 listeners were observed. Operator deployment and host-specific security/acceptance remain pending.