Known Issues

Current alpha expectations

This list summarizes the rough edges that are already known.

Likely things you may notice

• large lots can still take time on first load, especially when a view needs a fresh high-resolution fetch
• WebGPU availability depends on browser support and runtime initialization; canvas fallback exists but is slower
• some newer workflows are more polished in modals than in smaller card surfaces
• shared-space and document lifecycle behavior is newer than the rest of the product

Check the installed fixes

Proposal saving and cold analysis-share restoration shipped in separate frontend builds. Both were verified on the hosted demo after its 7 September 2026 rollout, but an installation can have the proposal fix without the share fix.

These are exact identifiers for two Stratum-published images, not a rule that any newer date includes the fixes:

Frontend image build date (UTC)	Proposal saving	Cold analysis shares
2026-09-07T21:12:54Z	Fixed	Not fixed
2026-09-07T21:50:22Z	Fixed	Fixed

On a managed installation, an administrator can check without repository access:

1. Request GET /health/deployment on the API host. This endpoint requires no bearer token at the application layer; an installation’s network or proxy may restrict access. For 401/403 or an unreachable endpoint, ask the deployment operator rather than changing application credentials. See health endpoint exposure.
2. Require HTTP 200, managed: true, healthy: true, stale: false and state: "in_sync". The images["stratum-app"] entry must also have in_sync: true. Otherwise, the intended image is not confirmed as running.
3. Compare that entry’s desired_published_at exactly with the table. It is the publisher’s image build date, usable for the running image only after step 2. observed_at and last_success_at are monitoring/deployment times, not build identifiers.
4. For an unlisted date, a custom build, missing metadata or managed: false, ask your deployment provider to confirm each fix separately. A later date alone is not proof; neither is a healthy process. Keep the precautions below until confirmation, and check the two workflows independently.

Use disposable QA artifacts, not a live review, for these checks:

• Proposal saving: edit a saved proposal’s summary and attach evidence. Confirm Save Proposal becomes enabled, save, then fully reload and reopen the version. Confirm both changes remain. With current exact impact, also save and reload Sign Off and Reopen independently; verify status and sign-off, not just the badge before saving.
• Cold share opening: save an analysis with a known selection and what-if limit, then open its share in a fresh authenticated tab. Check the snapshot, selected count and limit, wait for Lot data ready, and confirm title, selection and limit editing are disabled even for the owner. An empty view or a stalled load is not a passing check.

Proposal review changes can remain unsaved

Fixed in the frontend image dated 2026-09-07T21:12:54Z and verified on the hosted demo with the combined-fix image dated 2026-09-07T21:50:22Z. Use the installed-fix check for another installation.

In older builds, a proposal can show Approved after Ready for Review and Sign Off while leaving Save Proposal disabled. Reopening the server version can restore Draft and no sign-off. Evidence attachment and removal, summary edits, and limit changes can also be incorrectly marked saved.

This documentation deploys separately from the app, so an updated guide does not establish that your instance has the fix. Until its rollout is confirmed, reopen the saved version and check its evidence, summary, status, and sign-off before sharing or distributing a report. If a change is missing and saving remains disabled, do not distribute the proposal as an approved record; report the failure.

Sign Off and Reopen do not save automatically. Updating the app cannot restore edits that were never saved to the server.

Analysis share links can stall on open

Fixed and verified on the hosted demo in the frontend image dated 2026-09-07T21:50:22Z. The earlier proposal-only image does not include this fix. Use the installed-fix check independently of the proposal check. A fresh authenticated tab on demo restored the saved snapshot, selected dies and what-if limit, reached Lot data ready, and kept editing, share creation and share revocation disabled even for the analysis owner.

In older builds, a newly opened analysis share can stall at Preparing exact selection, with all seven datasets idle and zero selected dies. The share request succeeds, but the saved view never becomes ready; reloading alone does not fix this circular wait.

Do not interpret empty views as an empty saved selection. Report the build date and loading state if this happens. The demo rollout does not update a separate installation.

Good bug reports

When reporting an alpha issue, include:

• lot id
• snapshot id or whether you used latest
• test number and test name if relevant
• wafer number if the issue is wafer-scoped
• whether the problem occurred in a card or modal
• whether what-if mode or a saved analysis, proposal, or notebook was involved

That context usually cuts the reproduction time down dramatically.