feat(documents): preview shielded sign-off inside the Documents section - #377
Merged
Conversation
Embeds the demo vault as a working preview at /wallets/[wallet]/documents/preview, reached from a "Shielded sign-off" button in the Documents header — linked rather than left to be guessed at, since this section has already shipped unreachable once. The content is Mesh Multisig's OWN feature vault, not the wallet's documents, and the panel says so in the first sentence. A demo that let someone believe they were looking at their own records would be worse than no demo. What it shows honestly is the mechanism: selecting a note reveals the path a proof of it would disclose, and the documents it would keep sealed as hashes. Reuses VaultBrowser exactly as /vault does — it takes one `view` prop and owns its state — so there is one browser implementation rather than a second that drifts. TWO THINGS WORTH REVIEWING - loadVaultTrustView throws when the vault is not a DAG. That is right for a build-time check and wrong on a treasury page: an unrelated Markdown edit must not turn Documents into a 500. The loader is wrapped and degrades to hiding the panel. A CI test already asserts the vault IS a DAG, so the branch should stay unreachable. - The loading lives in src/lib/documents/vault-preview.ts rather than in the page, matching the thin-shell shape of every other page under documents/. It also makes the behaviour testable at all: importing the page pulls the whole component tree, including ESM-only react-markdown, which the CJS jest project cannot parse. Tests cover both paths, including that the props survive Next's JSON serialisation — a Map, Set or Date in getServerSideProps props is a runtime "Error serializing" on the deployed page that no type check catches. Verified against a real build: the route returns 200 and ships the view (10 hubs, 62 notes, 52 trust edges). 1141 tests pass; tsc clean; next build exit 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Embeds the demo vault as a working preview at
/wallets/[wallet]/documents/preview, reached from a Shielded sign-off button in the Documents header — linked rather than left to be guessed at, since this section has already shipped unreachable once.What it shows, and what it says it shows
The content is Mesh Multisig's own feature vault, not the wallet's documents, and the panel says so in its first sentence. A demo that let someone believe they were looking at their own records would be worse than no demo.
What it shows honestly is the mechanism they would get: selecting a note reveals the path a proof of it would disclose, and the documents it would keep sealed as hashes. Real content, real hashes, real trust graph — 10 hubs, 62 notes, 52 trust edges.
It reuses
VaultBrowserexactly as/vaultdoes — oneviewprop, all state internal — so there is one browser implementation rather than a second that drifts.Two things worth reviewing
The throw is wrapped.
loadVaultTrustViewthrows when the vault's trust edges are not a DAG. That is right for a build-time check and wrong on a treasury page: an unrelated Markdown edit must not be able to turn a wallet's Documents section into a 500. The loader degrades to hiding the panel instead. A CI test already asserts the vault is a DAG, so the branch should stay unreachable.The loading is not in the page. It lives in
src/lib/documents/vault-preview.ts, matching the thin-shell shape of every other page underdocuments/. It also makes the behaviour testable at all — importing the page pulls the whole component tree including ESM-onlyreact-markdown, which the CJS jest project cannot parse.Tests
Both paths are covered, including that the props survive Next's JSON serialisation. A
Map,SetorDateingetServerSidePropsprops is a runtime "Error serializing" on the deployed page that no type check catches, so the test asserts the round trip is lossless.Verified against a real build: the route returns 200 and ships the view.
tsc --noEmitclean; 1141 tests pass;next buildexit 0.🤖 Generated with Claude Code