Frozen document. Dates and status refer to its original source. Private resources and unreviewed images are unavailable.

Prototype acceptance and handoff strategy

Status: accepted verification and handoff strategy for Set acceptance evidence and agent handoff gates, amended by the owner's two-stage placement clarification in ADR 0010. The owner confirmed the real-service seam and evidence retention on September 23, 2026, chose measurement before numerical timing targets on September 26, and confirmed local Mac certification before cloud deployment. This document defines required checks, not results; no Atlas application has been built or tested.

Main test seam

Certify selected journeys on the Mac through the integrated loopback HTTPS origin with the actual React build, BFF/backend adapters, Keycloak with TOTP, Camunda, PostgreSQL, and ClamAV. Render forms from imported, pinned Contentful releases containing both en-US and es-US. Only payment and legacy endpoints are simulated. A green isolated UI test or mocked engine response alone does not qualify a journey. The later hosted HTTPS origin is a separate promotion seam for deployment-specific behavior.

The harness seeds one repeatable synthetic dataset: customers, a shared customer/employee identity, two isolated employers, managers, assigned reviewers, individual and employer coverage, annuity contracts, premium obligations, synthetic account aliases, documents, process versions, and pinned bilingual form releases. It records image/version digests and a seed revision. Reset stops workers, clears or namespaces prior business operations and sessions, then reseeds; it never treats old idempotency keys or sessions as valid in the new dataset.

Observable journey evidence

For each of the six selected product journeys, run at least one successful path and one meaningful business exception from the fictional rule catalog. Assert the visible final business outcome, authorized task history, and authoritative record effects through the public API. Include the shared premium-collection and payment-account path where applicable, and the separate disability benefit and employer leave/RTW decisions. Run the end-user journey in each locale at least once; verify that switching locale on a saved case preserves the same pinned release and case state. The specs will name exact fixtures and expected states per journey.

Use focused integration/contract checks for response shapes, revision and idempotency rules, stable status/error codes, authorization context, business record ownership, Camunda task correlation, document state, and simulated downstream effect count. The record owner verifies invariants; the BFF verifies browser/session and API boundary behavior; the workflow adapter verifies delivery and task correlation; the UI verifies rendering and accessible interaction. The integrated gate then verifies their combined behavior.

Required negative and recovery cases

• Deny cross-customer, cross-employer, unassigned-reviewer, and manager access to medical, EOI, claim, or banking details; verify public APIs and document downloads directly, not only hidden UI controls.
• Verify login, MFA, step-up freshness, logout, session expiration, CSRF denial, absent browser tokens, and en-US/es-US authentication copy with real Keycloak. A failed assurance or authorization check cannot produce a business effect.
• Scan a clean upload and reject a deliberately marked test sample using the real scanner; quarantine remains private. Scanner unavailable, timeout, and failed scan cannot release or satisfy evidence. Exercise the 10 MiB file boundary and replacement/version history.
• Repeat submission, task decision, and financial commands after a lost response; the authoritative effect occurs once. Test stale revisions, engine restart, outbox retry, simulated payment outcome unknown/reconciliation, and a cancellation-versus-approval race. Do not infer a terminal failure from a timeout.
• Restart the local stack without reseeding and verify persistent cases, pinned releases, operations, documents, and task recovery. Temporarily make Contentful unavailable after import and confirm existing pinned forms still render; new publishing remains unavailable.
• Check keyboard navigation, focus, labels, announced errors, and a representative screen-reader pass for login/MFA, form errors, upload, task review, and status. Inspect both locales for truncation and untranslated critical actions.
• Check emitted audit events and redacted logs for actor, correlation, outcome, and version without passwords, tokens, OTP codes, raw answers, medical contents, document bytes, or bank fields.

Resource and timing baseline

The owner chose to measure the complete stack before setting numerical pass/fail targets. On the Mac's selected Docker runtime, with image downloads excluded and the synthetic dataset seeded, measure cold Compose startup to healthy, dashboard and task reads, submission acknowledgement, 10 MiB upload with scanning, and a complete six-journey demo run. Record sample size, percentiles or elapsed time, exact commands, host/container CPU/memory/disk peaks, image versions, and any out-of-memory restart. Repeat resource and timing measurements on the chosen VPS after deployment; local capacity is not evidence of VPS fit. Do not present the earlier suggested 15-minute, two-second, three-second, or 30-second numbers as accepted requirements.

The first integrated build publishes the local baseline and its measurement method. The owner then agrees numerical thresholds for the final demo against measured evidence before performance can pass. Functional, security, recovery, accessibility, and evidence gates do not wait for this calibration. If the stack cannot complete a journey or measurement, record a failing result and resolve it before claiming readiness. Neither local nor VPS timings make a production scale or availability claim.

Evidence and gates

Keep exact test commands and results, redacted service logs, version/seed manifest, resource measurements, accessibility observations, and a repeatable synthetic demo script in the private repository or CI artifacts. Link evidence from the relevant implementation issue; never commit credentials, OTP seeds, real documents, or unredacted logs. A failed or unrun check is explicit, with a linked follow-up rather than a passing claim.

Worker checks stay narrow: owned unit/contract tests, a focused integration seam, and touched-package typecheck/lint. At a convergence gate the orchestrator verifies stable interfaces, cross-module contracts and the integrated paths affected by that wave. Run the complete journey, security, accessibility, recovery, and resource suite at the final demo gate, or earlier when a change creates a specific cross-cutting risk. Avoid rerunning the entire suite after every small change.

The local certification gate precedes deployment. At the hosted promotion gate, rerun critical successful and exceptional paths plus authorization, session/CSRF, locale, upload/scanning, persistence, reconciliation, backup restore, HTTPS proxy/callback and resource checks through the actual hosted origin. Preserve distinct evidence for both environments; a local pass cannot be relabelled as hosted proof.

Discovery closes when business/functional decisions, glossary, relevant ADRs, verification strategy, and unresolved limitations are explicit. The later to-spec pass confirms each spec's testing seam and publishes stories, decisions, acceptance behavior, deferrals, and decision links. The to-issues pass obtains owner review of vertical slices and dependencies before implementation dispatch. Each implementation issue must state blockers, conceptual owner and forbidden scope, complexity/effort/reasoning level, AFK/HITL mode, parallel wave, minimal context packet, focused checks, and the required handoff fields. No application worker starts until these gates and interface contracts are met. The dedicated VM security prototype is historical research, not a gate for this topology.