You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adds a web processing drawer for one exact selected document version, with executable profile selection, reviewed provider flow, consent state, retained-artifact consequences, and durable job progress.
Shows rendition and embedding coverage independently, including missing, rebuilding, unavailable, partial, and complete states, without turning an optional provider failure into a false all-or-nothing result.
Adds a verified sanitized Markdown view with immutable build, source, and profile identities; completeness and warnings; body-relative navigation; and inert rendering.
Adds source-fenced retrieval proof for the selected version, including the actual search mode, degradations, result evidence, and bounded trace.
Keeps browser authority narrow: processing survives a closed response after durable enqueue, rendition reads are not cached and are integrity-checked, and the daemon-lifetime session gains only the exact processing and read routes.
Why
Docbank already has the daemon API and CLI, but the primary human interface could not review what leaves the vault, grant or inspect consent, follow a durable processing job, read the verified rendition, or see why retrieval degraded. This puts those boundaries in one version-pinned workflow without giving the browser provider credentials or general daemon authority.
Usage
Select a file in the web app and choose Process and retrieve. Pick an executable profile, review the exact flow and retained classes, then choose Consent and run when consent is required. After processing, use Read sanitized Markdown to inspect the verified rendition or search the selected version directly from the drawer.
Reviewed processing plan
Partial provider result
Verified sanitized Markdown
All captures are from the real daemon and web app against a temporary synthetic vault.
Verdict: Two medium-severity security issues require attention.
Medium
document/openaiembed/client.go:232-235: The configured egress policy is validated and fingerprinted but not enforced. New preserves the caller’s transport, allowing document/query content and bearer credentials to bypass CIDR, proxy, or transport restrictions. Install a sealed providerhttp transport or reject unsealed clients.
document/bridge/client.go:107-109: The rendition bridge only disables cookies and redirects while retaining the caller’s ambient transport, permitting HTTP operator-network origins. Source documents and bearer credentials could be exposed through a malicious proxy or network observer. Require a bounded egress policy and sealed transport, or reject unbounded clients and non-loopback HTTP origins.
mariusvniekerk
changed the title
Add web document processing and rendition views
[E13–S9 10/15] Add web document processing and rendition views
Aug 30, 2026
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
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.
mariusvniekerk
changed the title
What changed
Why
Docbank already has the daemon API and CLI, but the primary human interface could not review what leaves the vault, grant or inspect consent, follow a durable processing job, read the verified rendition, or see why retrieval degraded. This puts those boundaries in one version-pinned workflow without giving the browser provider credentials or general daemon authority.
Usage
Select a file in the web app and choose Process and retrieve. Pick an executable profile, review the exact flow and retained classes, then choose Consent and run when consent is required. After processing, use Read sanitized Markdown to inspect the verified rendition or search the selected version directly from the drawer.
Reviewed processing plan
Partial provider result
Verified sanitized Markdown
All captures are from the real daemon and web app against a temporary synthetic vault.
Refs #176
Stacks on #233.