Workspace and artifacts

Every conversation in Motriz carries a workspace — a panel docked beside the thread with the product's files, diffs, and durable outputs. Artifacts are those durable outputs: specs, prototypes, build prompts, and journey documents with identity and provenance, not chat scrollback.

The workspace panel

The workspace docks to the right of an open conversation, and only there — the Dashboard, Journey, and Build destinations close it on entry (Build has its own full-page workspace).

While closed, the chat header shows a pill labeled "Workspace" with a badge counting the tabs available to this product, plus an orange dot when new artifacts have landed. Click it to open the panel; "Hide workspace" closes it. When a run lands artifacts, the workspace opens itself on the Artifacts tab — and a new prototype opens straight into its preview.

Docked, the panel keeps a fixed width (420 px by default; drag its left edge to resize, and the width persists). "Expand workspace" moves it over the chat at full width — the conversation stays mounted underneath, so live runs keep streaming — and "Collapse workspace" docks it again. A window too narrow for the split moves the workspace into the main area instead of closing it.

Which tabs a product gets

Tabs follow the product's mode (see Core concepts), so you never face empty tools:

Artifacts is the one tab every product has; Files and Changes exist only where there is a working copy to show. The Journey tab is a compact rail beside the co-founder conversation: the current milestone's artifact slots as a live checklist ("captured", "being captured now", "up next") and a mini-bar that jumps to the Journey destination.

Files: what this thread sees

Files is a read-only tree of the thread's working copy — the thread's own worktree if it has one, otherwise the product's repository. It shows what the agent in this conversation actually sees and edits, not necessarily your main checkout (see Git, worktrees, and GitHub). .git, node_modules, build output folders, and symlinks are hidden.

Selecting a file opens a read-only viewer with line numbers and syntax highlighting; editor colors and file icons follow your Appearance settings. Markdown opens rendered, with a "View source" / "View rendered" toggle; HTML files add an "Open in prototype preview" button for the native preview window. Binary files show "Binary file not shown"; files over 400 KB are cut off with a "Truncated" badge.

Changes: what runs actually did

Changes shows per-run diffs — every file a run touched, grouped under a "Run" header with + − ~ glyphs for added, deleted, and modified files. Docked, it is an accordion; expanded, a split with changed files on the left and a read-only diff on the right ("Select a change to see its diff."). Rows are badged "binary" or "truncated" when a diff cannot be complete. Read it before committing from the Git dialog; the review path shows these same diffs as its Changes station.

Artifacts

Twelve artifact kinds exist, grouped in every gallery in one fixed order: Briefs · Memos · Research · Plans · PRDs · Prototypes · Specs · Build prompts · Documents · Saved links · Images · Files. They come from three places:

• The co-founder conversation captures the journey's canonical documents — Idea brief, Problem frame, ICP, Market memo, Competitor map, Validation roadmap, Strategy memo, MVP scope, PRD, UX flow, Feasibility memo, Learning plan — as briefs, memos, research, plans, and PRDs (the UX flow lands as a spec).
• Product design threads produce specs and build prompts (the Specialist) and multi-screen HTML/CSS prototypes (the Designer).
• Chat and build threads can save files of any format alongside reusable prompts, documents, links, and images.

Artifacts live in Motriz's application data, outside your repository — prototypes are never written into your repo, and the design personas are instructed to use the repository as reference and write their deliverables to the artifact workspace. That instruction is expected behavior, not an access-control boundary. Generic files are shelved by extension: HTML under Prototypes, PDFs under Documents, image files under Images.

The Artifacts tab

The tab lists every artifact in the product; the open thread only drives grouping — rows sort newest-first under "This thread" and "Earlier in product". Each row shows a live thumbnail (prototypes render their real content in an inert, script-blocked frame) or a kind icon, the title, and a meta line like "spec · 2h ago". A prototype row expands into its screens; a build-prompt row carries a "+ Task" button that queues it as a durable task in Build ("Task added to the product queue"). File-kind artifacts do not open in-app — clicking one reveals the file in Finder.

Selecting a prototype opens an in-panel preview with "Open ↗" (the native preview window), "Expand" (the design stage, below), and "+ Task"; documents open a reading view. Expanded, the tab becomes the same card gallery as the Dashboard body, plus filter chips that exist only here — All, Prototypes, Specs, Prompts, Plans, Documents, Images — showing only kinds that exist, each with a count.

The expanded artifact view

Opening an artifact from the Dashboard gallery takes the full container. The breadcrumb root ("Dashboard / {title}") is the way back; the ✕ button and Esc also close it. Content sits on a centered paper column you resize by dragging either edge. The toolbar follows the kind:

Versions and provenance

Every artifact keeps provenance back to the product, work item, and run that made it — the thread chip on each card ("Open thread: {title}") is its visible face — plus a version counter that bumps every time a run publishes a change. Designs show it: "design · v3" on the set row, a "v3" pill in the thread header, and a revision run titled "Design pass · v3". Other kinds never display a version number.

Runs work on a private staged copy of the product's artifacts and publish only what actually changed. If two runs revise the same artifact concurrently, the later publication lands as a forked copy under a new slug — concurrent runs never overwrite each other's work. There is no version browser in 1.0.0: you cannot view, compare, or restore a prior version.

The design workspace

Prototypes are design sets: one HTML page per screen, pure HTML and CSS, entered at index.html. "Expand" puts a design on stage beside a narrowed conversation, one screen at a time, with a ‹ › stepper and a "{i} / {total}" counter. "Open ↗" pops the page into the native Preview window; "Restore split" (or Esc — which first closes an open note or comment mode) returns to the split.

The stage is where design review happens. Toggle comment mode ("Comment — click any element to pin a note"), click an element, and write what should change ("What should change here?" → "Pin note"). Notes render as numbered pins on the screen and as cards in the conversation ("Comment · {screen title}"), where they collect replies. "⚡ Fix" queues an open note for the next design pass ("queued · v4"); when your next message runs a pass that publishes the revision, queued notes flip to addressed ("✓ v4"). You can also resolve a note by hand. Addressed and resolved pins retire from the canvas — the chat card remains the durable record.

The Evidence tab

Journey products get an Evidence tab with four segments — the working memory behind the journey's criteria and decision cards (see The product journey):

• Evidence — "What we learned." Claims with a confidence badge (High, Medium, Low) and a source-type badge — Interview, Research, Document, Test, You, or Stated belief — where the source links back to the document, artifact, or URL it came from. Entries are written only by the co-founder as conversations produce them; there is no manual add, edit, or delete.
• Assumptions — "What must be true." Riskiest first, each with a "Risk {n}" badge. You edit them in place: status (Untested, Testing, Supported, Contradicted, Inconclusive) plus confidence, scope, and evaluation date. The co-founder creates and ranks assumptions; judging them stays yours.
• Tests. The fully manual segment: "+ Add test" creates a Discovery or Validation test — a sample plan and stop rule always; validation adds a falsifiable hypothesis, metric, and decision rule. Statuses: Planned, Running, Done, Dropped; marking a test Done requires a result and an interpretation. Tests cannot be deleted — drop them instead.
• Signals — "Product signals." Define what pull looks like and record manual aggregate observations — a complete local workflow, no analytics account needed. Connected sources are optional: link Amplitude or PostHog right here in the Evidence tab (credentials stay encrypted locally) and Motriz runs read-only aggregate queries against your account — it reads numbers in, never writes back.

The Documents tab

Documents is the product's source-material library: "Transcripts, research, notes, PDFs, and data files" you add for your co-founder to read and cite. It is not where the journey's outputs live — canonical documents like the Idea brief are artifacts. Pick a type (Transcript, Note, Research, Deck, or Data) and press "Add"; the picker accepts Markdown, text, PDF, CSV, JSON, and log files up to 20 MB each. Files are copied into Motriz's managed storage, so the original stays where it is and later edits to it are not reflected. Clicking a row opens a reader (Markdown rendered, PDF text extracted, previews capped at 100,000 characters); evidence entries whose source names a document link straight into it.