When a conforming wallet still breaks an application

The affirmative case for a common interface

A wallet interface lets an application request actions without implementing every wallet’s private API. It can make user permissions more consistent, allow reusable test vectors and make alternative implementations easier to compare. That shared boundary is valuable precisely because the wallet and application are different components with different responsibilities.

The user still needs the complete task to work. An operation may exist in the interface while an implementation rejects a particular request, asks for an unexpected permission or returns behavior the application cannot handle. A passing test only establishes the behavior covered by that test under its recorded conditions. It does not certify all combinations of wallet, app, platform and version.

Basis: BRC-100 · wallet to application interface

What the October 4 exchange establishes

A Zanaadu user reported a broken mobile posting workflow and an unexpected signing restriction. A maintainer subsequently described an overly restrictive change, acknowledged missing prompt and release communication, and said the interface check had passed. Project Babbage accepted a code-quality and testing gap. The reporter’s later constructive response is useful context, but it is not a verification of repair.

These are attributed public reports. They do not establish an independently reproduced diagnosis, a fixed version or a successful current test. This case records the support and compatibility lesson without asking readers to accept a claim about an unobserved outcome. A later update should name the release, conditions and evidence that change this status.

Basis: Zanaadu mobile workflow reportMaintainer’s explanation and acknowledgmentProject Babbage’s acknowledgment of the testing gapReporter’s constructive follow-up

Four layers to inspect before assigning the fix

The specification defines what a request means and which behavior is promised. Wallet policy defines permission and risk decisions inside that boundary. The implementation carries those decisions out. The application then composes operations into a user workflow, including its handling of denials, errors and changes.

Calling a problem an implementation issue can help assign work, but should not end the investigation. A standard may leave important semantics ambiguous. A policy change may be legitimate yet poorly communicated. An application may rely on undocumented behavior. More than one of these can be true at once. The useful result is a precise supported behavior and a tested path forward.

A compatibility matrix should therefore name app, wallet, versions, platform, workflow, expectation, observed result, date and tester. Distinguish pass, fail and not tested. Keep a reported failure separate from an independently reproduced failure; otherwise the table silently upgrades the evidence.

Basis: BRC-100 · wallet to application interfaceMaintainer’s explanation and acknowledgment

Public compatibility support and security reporting

Ordinary compatibility questions benefit from public symptoms, supported behavior, release notes and migration instructions. Developers should not need a private relationship to learn that a supported operation changed. A public report can be constructive even when its first explanation of the cause turns out to be incomplete.

If a report includes a suspected exploitable weakness, use the affected project’s designated confidential reporting process for sensitive details. A safe public status can still explain affected functionality, mitigations that do not create new risk, supported versions and where updates will appear. Do not publish credentials, private records or exploit instructions in a compatibility ticket.

The TypeScript stack has a public security policy. That fact establishes a reporting route, not an independent audit or a paid bounty promise. It also does not establish that any existing advisory describes this particular incident. Match identifiers and affected versions before linking an advisory as its resolution.

1. Ordinary unexpected behavior: provide safe symptoms, versions, expected behavior and a public issue or support route.
2. Potential exploitable weakness: send sensitive detail through the project’s designated process; keep public updates safe and useful.
3. Unclear category: ask the maintainer to route it without requiring secrets or a public reproduction of a weakness.
4. Resolution: name the release and retest the original user task before marking it fixed.

Basis: TypeScript stack security policy

Communicate a behavior change before users discover it

A useful change notice states what changed, who is affected, which versions contain it and what applications should do. If a restriction changes, describe the user-visible behavior and supported migration path. Do not turn a security improvement into an undocumented compatibility surprise when safe advance communication is possible.

The notice should also distinguish intentional behavior from a regression and identify the owner of follow-through. An apology or acknowledgment matters, but users still need a release and a working task. Preserve failed tests and unexpected results as part of the record; they explain why a later claim of compatibility is credible.

For maintainers, shared interface tests and application workflow tests serve different purposes. Add coverage for the behavior that mattered to the user, including ordinary denial and recovery behavior, while keeping security-sensitive investigation in the appropriate process. A versioned result is more useful than a general badge saying ‘compatible.’

Basis: Maintainer’s explanation and acknowledgmentProject Babbage’s acknowledgment of the testing gap

A matrix ready for real results

The downloadable CSV begins with the reported Zanaadu case and a blank test row. Its test status is not-tested because this article did not reproduce the workflow. The reported symptom remains in a separate field. Fill unknown versions only from evidence; do not infer them from a publication date.

Use the same workflow against the relevant released app and wallet versions, retain a non-sensitive result and record who performed the test. A successful retest supports that combination on that platform. It cannot establish universal compatibility or resolve unrelated reports. Link the evidence back into the article so the original conversation becomes a durable, revisable record.

Basis: Zanaadu mobile workflow reportReporter’s constructive follow-up

What would change this assessment?

A named release and successful workflow retest can establish a repair for that combination. Repeated unexplained regressions or unclear semantics would justify revising implementation practices, compatibility commitments or the specification itself.

Keep and reuse the work

These assets carry their scope, date and source page. Templates are proposed tools; blank or synthetic records do not establish tested results.

• Evidence diagram as SVGAccessible text, scope and canonical source retained.
• Full article as MarkdownReadable offline, including source notes and limits.
• Versioned compatibility matrixReported symptom and independent test status are separate.
• Behavior-change notice templateVersions, supported behavior, migration and retest evidence.

Structured public library · Use the canonical page and preserve qualifications when quoting or adapting an answer.

Sources and provenance

The reasoning above stands on this page. The original exchanges record how the question developed; publication on X is not independent proof that a claim is true.

1. BRC-100 · wallet to application interfacedocumented · Access recorded 2026-10-05

   The interface specification; implementation, policy and workflow outcomes need their own evidence. No new compatibility test is implied by this guide.

2. Zanaadu mobile workflow reportreported · Access recorded 2026-10-05

   October 4 user report of failed posting and an unexpected signing restriction. Not independently reproduced for this article.

3. Maintainer’s explanation and acknowledgmentreported · Access recorded 2026-10-05

   Describes an overly restrictive change and missing prompt/release communication, despite a passing interface check. Does not establish a released repair.

4. Project Babbage’s acknowledgment of the testing gapreported · Access recorded 2026-10-05

   Public acceptance of responsibility for code quality and workflow coverage. An acknowledgment is not a fix.

5. Reporter’s constructive follow-upreported · Access recorded 2026-10-05

   Acknowledges shared responsibility. It does not confirm a successful retest.

6. TypeScript stack security policydocumented · Access recorded 2026-10-05

   Project-specific reporting policy. A policy is not an audit, a promised bounty, or evidence that this compatibility incident matches an advisory.

Continue by question