Why 175 passing tests still did not make FigureDesk release-ready
CODE56 is a useful example of a release lesson that is easy to miss: a large green test result can be real, valuable evidence and still be insufficient for shipping accounting software.
What actually passed
CODE56 completed a substantial automated and device-test run. The JVM debug suite passed 148/148, the JVM release suite passed 148/148, lintDebug and lintRelease passed, and debug, AndroidTest, release, R8 and AAB builds completed. On a Samsung SM-S938B, the full unfiltered instrumented suite passed 175/175. The installed owner-test APK was also pulled back from the phone and matched the build output byte-for-byte by SHA-256.
Those numbers matter because they are reproducible evidence. They tell us that the tested contracts and instrumented cases behaved as expected in that build. They do not prove that every workflow a user can reach has been physically certified.
What CODE56 changed
The remediation work addressed concrete failure modes. The sticky Back control was moved below the safe top inset and given a full-width target. App Back and Android Back now unwind the same ordered history. A genuinely fresh bookkeeping action clears shared purchase facts, attachments and review state instead of inheriting stale state from a previous event.
CODE56 also added a narrow fail-closed foreign-service matrix with documented manual exchange-rate provenance, kept SEK bookkeeping local-first with no telemetry, introduced an in-app multipage PDF reader for saved report content, and removed internal technical identifiers from ordinary report PDFs.
Why the gate stayed open
The final release gate still failed because the remaining work sits across complete user lifecycles rather than isolated functions. Foreign invoice recognition followed by partial or full settlement is not wired and certified end-to-end. Foreign credit/refund and exchange-difference handling are not certified as product workflows. PDF save-copy behavior is not standardized across every accounting/report/document family, and every historical issued document does not yet have the same immutable persisted-PDF lifecycle.
Physical certification was also incomplete. The Samsung suite passed, and the previously failing sticky-Back route was physically closed, but the requested full 19-point manual matrix and two schema-17 backup→clear→restore cycles were not completed. Calling the build release-ready would therefore overstate the evidence.
A narrow foreign-currency example
CODE56 supports only a deliberately narrow foreign-currency slice: certain outside-EU B2B service purchase/incoming cash cases. The posting snapshot stores the original currency amount, SEK result, SEK-per-unit rate, effective date, actual source date, source and method. Changing currency or date requires a new review before posting.
Automatic rate fetching is not enabled in CODE56. The implemented path records manual provenance locally, and no counterparty, invoice, receipt, evidence or bookkeeping record is sent over the network for that feature. Cases such as EU flows, goods, foreign invoice-method settlement, credits and refunds remain NeedsInformation or Unsupported rather than being silently generalized.
PDF lifecycle versus PDF rendering
A PDF can render correctly and still leave a release problem. CODE56 can display saved report content in an in-app multipage viewer and handles missing or corrupt files explicitly. It also removes internal enums, rule/package IDs, fingerprints and calculator-engine version text from ordinary user PDFs.
But the lifecycle is not yet uniform: some paths still use direct MediaStore exports instead of one Android CreateDocument save-copy flow, and some historical documents regenerate from immutable snapshots rather than opening one persisted immutable PDF artifact. That difference is why “the PDF looks right” is not the same claim as “the complete document lifecycle is certified.”
The release lesson
The useful conclusion from CODE56 is not that automated tests are insufficient. It is that release evidence has layers. Unit and contract tests can verify rules. Instrumented tests can verify UI and device behavior. Physical checks can verify touch, lifecycle and storage behavior. End-to-end certification then asks whether the complete supported user journey has been demonstrated without gaps.
For FigureDesk, the correct public status after CODE56 is therefore specific: strong automated and Samsung test evidence, several concrete remediation improvements, and an open release gate with known blockers. That description is less dramatic than “175 tests passed, ship it,” but it is more useful to anyone trying to understand what the software can actually claim.
This case study describes software-development and verification evidence from FigureDesk CODE56. It is not accounting, tax or legal advice.
A release gate should name both evidence and gaps
Record what passed, on which build and device, then separately list every incomplete lifecycle, physical test and unsupported rule path. A green suite becomes more trustworthy when the product also states what it did not prove.