• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

archetech / archon / 32755694476
95%

Build:
DEFAULT BRANCH: main
Ran 24 Aug 2026 05:20PM UTC
Jobs 1
Files 91
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

24 Aug 2026 05:16PM UTC coverage: 93.932%. Remained the same
32755694476

push

github

web-flow
feat(clients): Add DIDComm credential exchange to KeymasterUI (#936)

* feat(clients): Add DIDComm credential exchange to KeymasterUI

#919 added this to packages/wallet-ui, which both wallets consume, and left
the two standalone clients behind. Nobody noticed for weeks: no test, no
typecheck and no CI check covers these files, so a whole feature going
missing was silent. Filed as #935.

Both copies now get, alongside the existing Notice-based Send:

- "Send over DIDComm" on each issued credential, opening a recipient modal
  and calling sendCredentialDidComm. sendCredential posts a Notice carrying
  the credential's DID, which only a did:cid holder can resolve and
  decrypt; this carries the signed credential itself, which is the only way
  to reach a subject outside the network.
- "Accept" on issue-credential/3.0 messages in the DIDComm inbox. A false
  return means a foreign issuer's credential with no did:cid to resolve, so
  it says so rather than reporting a success that stored nothing, and the
  message stays in the inbox where its contents can still be read.
- "Credential" as the inbox label for that message type, rather than the
  raw type URI.

Applied from a single script to both files so they stay byte-identical --
verified, they do. Both apps build, and the calls are present in the built
bundles rather than only in the source.

This is the fourth and fifth copy of this feature. #99 is the fix; #935 is
the guard that makes the next omission loud.

2266 tests, typecheck 0, lint clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(clients): Report an empty recipient, and resolve it before sending

The review is right that an empty submit went nowhere silently. This
modal's confirm button is always enabled -- unlike the shared wallet UI's,
which disables it -- so an empty value reaches the handler, hit `if (!to)
return`, and left the dialog open with nothing said.

Checking what the shared UI does turned up a seco... (continued)

3854 of 4341 branches covered (88.78%)

Branch coverage included in aggregate %.

8484 of 8794 relevant lines covered (96.47%)

690.73 hits per line

Jobs
ID Job ID Ran Files Coverage
1 32755694476.1 24 Aug 2026 05:20PM UTC 182
94.94
GitHub Action Run
Source Files on build 32755694476
  • Tree
  • List 91
  • Changed 77
  • Source Changed 0
  • Coverage Changed 77
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • Github Actions Build #32755694476
  • 933ba2f2 on github
  • Prev Build on main (#32646167150)
  • Next Build on main (#32758619472)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc