yeah that could be nice too. For this PR i was following Louis's direction around using the sidebar and a separate artifacts page to help people find ai outputs more generally. I’d keep this one focused on that for now.

nice is that sidebar? can it render react ? like if AI generate react

right now it’s a sidebar section for files the AI created. It can show a preview and open them but it doesn't render generated react as a live interactive artifact yet.

can you share video?

yep here's a small demo: https://drive.google.com/file/d/1U3kQwTFj6IXbI4NgnmmyVmu7v-yg4V1x/view?usp=sharing

I'm still working on it, but this shows the basic flow where the agent creates a final file and saves it into Artifacts.

same flow goes for pipe if pipe has any output after they can be accessed in the Artifacts as well. happy to test other flows too if you have suggestions.

@thisisharsh7 hmm trying to think how we could show the inbox, memories, and artifacts, in coherent way that is human friendly and scalable while still being an AI first source of context

i guess memories is mostly for AI while artifacts is more for humans to vizualize while notification/inbox is also meant for humans but right now it's a bit spammy / too much info for humans

maybe try some suggestions as mockups until we find the right UX (AI generate ASCII mockups or sometimes what I do is asking generating mockups through grok API or temporary html page + screenshot to add as comment to the PR to see how it would look like)

makes sense. I'll think through inbox, memories, and artifacts together and put together a few mockups so we can compare directions.

Louis, sharing some rough ai generated mockups for inbox, memories, and artifacts.
lmk what you think.

1. we can merge memories and inbox section into one and show them in feed section together with artifacts

2. or we can leave the memories tab as it is and put the files generated in the notification ui as shown.

I haven't written feature-specific E2E for this yet. since the PR is still in draft and the current discussion is about refining the UX direction, I'd prefer to finalize the feature behavior first and add focused E2E test afterward.

great work this is needed congrats

@louis030195 please check this lmk what you think

make sure to add a filter so we can easily browse through artifacts

Update:

• added e2e coverage for the outputs API and Brain artifacts flow
• added stable test ids for Brain interactions and delete confirmation
• fixed inline artifact markdown expansion in Brain by using the same viewer file-read path as the dedicated file viewer

Follow up -

• added the required coverage manifest entries for the new specs

Update

• fixed output path sanitization so we still block traversal, but preserve valid dotted filenames. the old logic stripped all .. and trimmed dots, which broke normal names like my..file.txt and .env. now we only reject . / .. as full path components, and added unit tests for the edge cases.

• fixed read_viewer_file so it no longer reads the entire file into memory before truncating. it now does a capped read at the 10 MB limit, which avoids large-memory spikes on huge files. also fixed the truncation flag so the UI warning appears correctly for oversized files.

@thisisharsh7 whats the status of this PR?

@louis030195 it's completed, final review from your side is needed

GREAT WORK HERE MATES, CONGRATIS
this is taking screenpipe next level!