← Atlas Journey · Docs

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

Atlas six-product wizard gap inventory

Read-only inspection of [private location omitted], HEAD 8355bce, on 2026-10-07. No application, Git or runtime mutations and no tests executed. Ticket reads through authenticated gh failed because api.github.com was unreachable. Ticket allocation below must be reconciled with the actual bodies of open issues 93–96 before publication.

What exists and what is missing

AreaVerified current implementationNeeded for the requested six complex, realistic, branching wizards
Release vocabularyapps/bff/src/form-releases.ts:6 supports text, multiline, date, number, currency, select, radio and checkbox. Definitions contain ordered sections and fields, optional task screens, scalar answers, required/min/max/length constraints, bilingual copy and a hash-pinned release.Versioned stage definitions, explicit presentation conditions and bounded rule vocabulary; reject unknown references/cycles/invalid operators; pin all stages and task screens in the same release. Compound/repeated data needs a deliberately bounded contract if product stories require it.
ConditionsField, compileRelease and validateAnswers have no condition property or evaluator. Every field in a definition participates in complete validation.Reviewed declarative conditions for visibility and active-stage validation. Define treatment of answers when a prior answer hides their branch, and whether cross-field conditions belong to presentation or owner rules. No executable CMS expressions.
Browserapps/web/src/Products.tsx:19 renders every section at once. Draft UI provides Save and Submit; task UI offers information/follow-up/reviewer actions. Radio currently renders as a select. FormDraft.tsx and EmployerFields.tsx have separate field renderers.Accessible Next/Back, stage/progress labels, visible-path review, error focus, keyboard behavior and resume. Render CMS-defined stages with a consistent registry. Keep local navigation separate from Camunda task transitions.
Durable wizard stateapps/bff/src/products.ts uses revision-checked pinned drafts and same-case task commands. Product draft output is draftId/releaseId/revision/answers/release. No stage cursor or completed-stage checkpoints appear in product-trpc-schemas.ts or the renderer.Persist and validate resume state against release and answers. Invalidate later completion checkpoints when controlling answers change; preserve stale-revision and idempotent command semantics. Agree whether cursor is authoritative or only a navigation hint.
Contractsdraft-trpc-schemas.ts makes rendererSchemaVersion literal 1, flat section/field definitions and scalar answer records. Strict TypeBox parsers check input/output without coercion or defaults and bound final payload bytes. product-trpc.ts routes the existing owner functions.Incrementally extend reviewed input/output vocabulary and browser-safe inferred types. Specify v1 compatibility and failure behavior for unsupported releases. Do not encode product field requirements a second time in TypeBox.
Camundaatlas-product-intake.bpmn version product-v2 supports one optional pre-review follow-up then review/RFI loop. atlas-product-claim-review.bpmn product-v1 starts at review and loops on RFI. product-content.ts:15 chooses these two processes for six products.Product-specific multi-task branches, explicit outcomes and logical form references where the requested journey crosses durable workflow stages. Reuse generic processes only when task order and owner semantics really match. Version deployment and retain compatible old processes.
Adapterproduct-engine.ts:28 start accepts only followUpRequired; findTask accepts three element IDs; complete sends only reviewDecision. products.ts correlates process/version/task/assignee/form before projection and reconciles uncertain commands.Extend the domain adapter for approved task transitions and versioned branch variables. Preserve exact task correlation, durable acceptance and no retransmission after ambiguous writes. Private gRPC is a separate ADR 0012 migration, not a prerequisite for wizard UX.
Contentful seedseed-contentful-form.ts:17 defines field/section/form models without stages or conditions. seed-product-content.ts refuses model or entry drift before publication. product-content.ts:65 produces one primary section per product and shared information/decision screens, plus life follow-up.Reviewed model migration and richer synthetic en-US/es-US author graphs per product. Compile and preview every reachable branch before activation; preserve old immutable release pointers and old draft behavior.
TestsProduct content/compiler, owner, tRPC, adapter and seed scripts exist. test-product-ui.mjs has three fixture-browser tests for incomplete save, reviewer RFI display and Spanish errors. test-product-cloud-e2e.mjs contains real HTTPS/engine proof concentrated on life/Medicare/dental; it explicitly limits content to compiled synthetic published-shaped releases. Separate disability/LTC/annuity scripts cover their owner benefit/payout rules.Red-first journeys at React + real BFF + PostgreSQL + real Camunda, with external simulated integrations. All six need explicit positive branch paths, changed-answer path invalidation, resume/back/locale preservation, task ownership and negative-path assertions. Fixture render tests remain useful but cannot certify durable sequencing.

Existing product depth

productEntries currently seeds these primary answers:

ProductFieldsExisting process or outcome depth
LiferequestedCoverage, beneficiaryName, healthQuestionsApply, declarationshealthQuestionsApply=yes selects one eoiDetail follow-up; reviewer can request additionalInfo; clean reviewed EOI can gate approval; approval creates synthetic coverage.
Medicare supplementexistingCoverageReference, effectiveDate, declarationsGeneric review/RFI; synthetic enrollment. No live Medicare verification.
DentalserviceDate, serviceType, claimedAmount, declarationsGeneric claim review/RFI; reviewed clean evidence and allowed-amount/remaining-benefit limits; no payout.
Disability incomeabsenceStart, absenceEnd, payoutAlias, declarationsGeneric claim review/RFI; seeded benefit/coverage, evidence and separate disbursement. Linked employer leave exists elsewhere and must retain its privacy boundary.
Long-term careperiodStart, periodEnd, payoutAlias, declarationsGeneric claim review/RFI; seeded benefit, evidence and separate disbursement.
AnnuitywithdrawalAmount, payoutAlias, declarationsGeneric claim review/RFI; balance reservation and separate disbursement. Case cancellation is distinct from requesting annuity funds.

These are six short synthetic forms with durable owner outcomes. They do not establish six complex multi-stage wizard journeys.

Proposed incremental graph

First amend the owner-approved requirement and acceptance matrix. Specs 90/91 and issues 93–96 are supplied as existing planning context, but their bodies were not retrieved in this worker. Reuse every covered extent rather than cloning their original work into new tickets. A one-follow-up acceptance criterion can be a first demonstrable path; it cannot be the final acceptance gate for the expanded request.

  1. Plan amendment and readiness gate. Specify each product's stages, controlling answers, reachable branches, task owner, evidence requirements, fictional domain rules, terminal outcomes, resume/back behavior and per-branch tests. Keep defects 98/MFA and 99/case withdrawal in their existing tickets.
  2. First complete branching journey. Reuse the existing issue among 93–96 that owns life/follow-up work. Deliver the minimum reviewed stage/condition vocabulary, compiler, TypeBox contract, seed migration, React stage rendering, durable save/resume, owner validation and Camunda path as one user-visible life journey. Keep this slice small but include a genuinely changed-answer branch.
  3. Six product slices after the first journey passes. Reuse the applicable 93–96 ticket extents. Add product-specific steps and task bindings with focused React/BFF/Camunda tests. Medicare and dental can establish non-financial branching; disability and LTC need evidence and benefit/disbursement separation; annuity needs balance and account rules. Sequence new shared vocabulary changes through one owner, then allow disjoint content/BPMN/product logic work only after contracts stabilize.
  4. Cross-product convergence. Qualify six branch matrices, two locales, old and new pinned releases, auth/context isolation, revisions/idempotency, evidence replacement, restart/reconciliation, and both sides of cancel-versus-decision races. Defects 98/99 must pass before claiming full completion.

Dependencies: requirement gate -> first life journey -> remaining product journeys -> six-product convergence. MFA/withdrawal fixes can progress independently under their existing ownership, then join convergence. Contentful authoring stays with Contentful; presentation navigation stays in SDUI; durable human-task branching stays with Camunda; financial and eligibility rules stay with owner services.

Test seam and risks

Begin each story with a failing browser interaction against the public tRPC/HTTPS BFF. Use the real compiled pinned release and real owner persistence. The first durable task branch must reach actual Camunda, not a stub that invents the next task. Assert observable rendered stages and backend task/operation identity together. Require a happy branch, alternate branch, changed earlier answer, saved resume, locale switch, unauthorized actor, stale draft/task, hidden-answer handling and ambiguous-effect recovery where applicable. Seed/content/compiler malformed-graph tests remain focused lower checks.

Accepted ADRs 0004/0005/0011/0012/0013 preserve immutable bilingual releases, durable owner commands, bounded code-owned schemas and tRPC browser transport. Avoid arbitrary condition expressions, hard-coded product pages, competing TypeBox form rules or a second workflow engine. Main risks are evolving the release contract without supporting old drafts; confusing Next with task completion; retaining hidden answers without agreed semantics; leaking evidence through shared stage projection; and certifying six-product UX from existing three-product fixture/qualification evidence. Existing process version matching and uncertain-operation reconciliation should be retained rather than rewritten.