Artifact capture — chat artifacts as first-class wiki entries

TL;DR: Claude.ai conversations regularly produce artifacts — code, HTML, SVG, mermaid diagrams, full documents, PDFs / DOCX / XLSX — that today are stranded in chat history. Hussh's wiki captures prose via the existing memory pipeline; a second pipeline (wiki_artifact_save) captures structured artifacts. Artifact bytes live in the dedicated wiki Shared Drive; public artifacts receive per-file reader ACLs on their canonical Drive file. A wiki page mirrors each artifact and renders it natively in the reader — SVG and mermaid render as diagrams, HTML renders in a sandboxed iframe, code is syntax-highlighted server-side, PDF/DOCX/XLSX render via Google Drive's preview iframe. The wiki is the primary viewing surface; Drive is the byte store.

Status as of 2026-05-29: Tool shipped. Reader-side native rendering shipped. Public and private artifact saves write to the dedicated wiki Shared Drive when WIKI_DRIVE_PRIVATE_SOURCE_ID is configured. Public canonical files are verified with anyone-with-link reader access; Drive shortcuts remain internal organization metadata. Historical artifacts from the older Hussh One / Hussh Tech Shared Drives were copied and rewritten into the wiki Drive on May 29, 2026.

Why this exists

The wiki is built on Karpathy's LLM Wiki pattern: "good answers become wiki pages." But a "good answer" sometimes isn't prose — it's a working SVG of a flow, a TypeScript snippet that demonstrates a contract, an HTML mockup, a 1-page strategy doc the model just generated. Three properties make these worth treating as first-class:

They're durable. A diagram of the three-layer architecture doesn't go stale just because the conversation that produced it ended.
They're reusable. The same SVG belongs in slide decks, on the wiki, in Drive folders shared with collaborators.
They have natural homes outside the wiki. Code wants a .ts file you can git clone and run. SVG wants a Drive preview. Markdown documents want to live next to other Drive documents.

The wiki keeps navigation and rendering (a page per artifact, full-text searchable, cross-linked to related concepts, and rendered natively inline). Drive keeps bytes (the canonical file you can download, share outside Hussh, or embed elsewhere). Each does what it does best.

Native rendering on the wiki page

The wiki reader dispatches by artifact.type and renders each kind inline:

`artifact_type`	How it renders on the wiki page
`svg`	Inline `<svg>` (DOMPurify-sanitized for safety)
`mermaid`	Client-side mermaid.js render (lazy-loaded only on pages that use it)
`html`	Sandboxed `<iframe srcdoc>` with `sandbox=""` — no scripts, no same-origin
`code`	Server-side syntax highlight via Shiki (zero client JS for highlighting)
`react` (TSX/JSX)	Syntax-highlighted source by default; "Render this component" toggle reserved for a Sandpack opt-in
`image`	Inline `<img>` via the Drive embed URL (`lh3.googleusercontent.com`)
`pdf` / `binary`	Google Drive `/preview` iframe (DOCX/XLSX/PPTX/PDF rendered natively by Google's viewer)
`markdown` / `document`	The wiki page IS the artifact — normal markdown render

Bytes for text artifacts come from the first fenced code block in the wiki page body (already stored there by wiki_artifact_save). Binary artifacts (PDF/DOCX/etc.) render directly from their Drive file via the public viewer — every public artifact has anyone-with-link access set at save time, so visitors don't need to sign in.

How it routes

Two routing decisions get made on every save:

1. Drive home — dedicated wiki Shared Drive

Public and private artifacts go to the dedicated wiki Shared Drive. Public canonical files get anyone-with-link reader access; private files do not. Topic still matters for wiki path, page relations, visibility inheritance, and business-map context.

The older Hussh One and Hussh Tech Shared Drives are legacy rollback sources. New artifact saves should not route there unless WIKI_PUBLIC_ARTIFACT_BUCKET=legacy is set for an explicit rollback test.

2. Sub-folder — by artifact kind

Inside the wiki Shared Drive, files mirror the artifact's canonical wiki parent and use one of these leaf folders:

code/         ← code, react
diagrams/     ← mermaid, svg
documents/    ← markdown, document
mockups/      ← html
images/       ← images
files/        ← pdf, binary
other/        ← anything else

The wiki page path mirrors this exactly. A mermaid diagram about the three-layer architecture lands under that concept's diagrams/ folder in the wiki and under the matching Drive folder in the wiki Shared Drive. Browsing either surface tells you the same story.

The default visibility for an artifact is private. A few rules raise it to public:

Inherit from page references. If the primary page and all related wiki pages are public, the artifact can default public. Any private or missing reference forces private.
Explicit override. The caller can pass visibility: 'public' | 'private' to override, but explicit public still requires every primary/related page to already be public. It cannot publish an artifact that points at private pages.
Sensitivity scan can demote. Even if visibility resolves to public, a fast regex sweep over the artifact body looks for credential patterns, PII (tax identifiers, SSNs, credit cards), and private fund-formation jargon. Any hit forces drafts: the wiki page is created in wiki/_drafts/ for human review, and the Drive upload is skipped entirely.

This mirrors the public vs. private surfaces model already used by the wiki promotion tool.

Auth — keyless impersonation

The MCP runs as wiki-runtime@hussh-wiki-prod. To write to the Workspace Shared Drive, it impersonates the delegated Drive service account that is Manager on the dedicated wiki Shared Drive. Impersonation uses the IAM Credentials API — there's no long-lived JSON key in Secret Manager, no key rotation to track, and revocation is one IAM-binding removal away.

Drive scopes are intentionally split by job:

drive.file lets the wiki agent create and manage wiki-generated artifacts, folders, and shortcuts in the Shared Drives.
drive.readonly lets the wiki agent list and read existing files in Shared Drive files/ folders for ingestion. Existing-file ingestion must read the file contents before linking anything into the wiki; title-only matching is not acceptable.

Private artifacts stay private in Drive

When an artifact resolves to private, the bytes are uploaded to the restricted private area of the wiki Shared Drive:

Private Drive files never receive public ACLs.
Private Drive upload failure does not copy private bytes into the Git mirror as a fallback; the draft contains metadata and a retry instruction only.
Small private text artifacts may still render inline on authenticated wiki pages for reader usability, but the wiki Drive is the byte boundary for files.
Large private artifacts require WIKI_DRIVE_PRIVATE_SOURCE_ID; if that wiki Drive is unavailable, the save is skipped or drafted without preserving private bytes in Git.

What gets stored where

For a public artifact named "Three-layer architecture" tagged as mermaid, related to wiki/concepts/three-layer-architecture.md:

Wiki page (this repo, public): wiki/artifacts/diagrams/2026-05-09-three-layer-architecture.md — frontmatter (title, description, type, visibility, artifact: {…drive_location…}), TL;DR, summary, inline preview (first ~80 lines), link to Drive.
Drive file (wiki Shared Drive): the matching Drive file under the concept's diagrams/ folder — the full mermaid source, with Drive's preview rendering it visually.
Reader URL: the wiki page is searchable and cross-linked from the related concept page.
Drive URL: opens directly in the Drive UI for download or further editing.

For a private artifact, the authenticated wiki page records a private Drive location. Anonymous MCP/public reader responses strip non-public Drive IDs and links.

Failure modes — fail open, route to drafts

The pipeline is designed so a misconfigured Drive doesn't block useful work:

Wiki Drive ID env var unset → drafts (with guardrail_reason: drive_upload_failed).
Impersonation grant missing → drafts.
Network or auth failure during public upload → drafts; public-safe bytes may be preserved for retry.
Network or auth failure during private upload → draft metadata only; private bytes are not copied into Git.

In each case, the wiki page (or its draft equivalent) is still produced and committed. Public-safe bytes are preserved for retry; private bytes require a retry into the wiki Drive rather than being copied into Git.

Relations

LLM Wiki pattern — the wiki context this builds on; "good answers become wiki pages" generalizes to "good artifacts become wiki entries with external bytes".
Public vs private surfaces — the visibility / sanitization model whose rules this pipeline reuses.
Wiki-as-app architecture — the three-tier plan this tool slots into.
BYOA — the architectural commitment that motivates keeping artifact bytes on the user's own Drive (Workspace they own), not on Hussh-owned infrastructure.
Hussh wiki — scalable app + MCP architecture — Artifact capture into the wiki

Enterprise architecture streamlining boundary

Current repo truth: partner artifacts can support a planning lane, but generated PDFs and Drive-backed files remain private unless explicitly reviewed and promoted.
North-star direction: safe artifacts should point to repo-backed architecture docs and avoid becoming a second source of truth.
Not shipped / not implied: a proposal artifact does not prove implementation, deployment, or partner storage authority.
Source notes: internal architecture notes — enterprise planning stream and proposal boundaries.

Sources

LLM Wiki pattern — pattern this extends.
Public vs private surfaces — visibility model reused.
Wiki-as-app architecture — system this slots into.