DEV Community: Zaid Kamil

Echo Shelf 2.0: Turning Saved Knowledge Into a Living Second Brain

Zaid Kamil — Mon, 05 Oct 2026 06:25:10 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

We save useful knowledge every day.

An interesting article gets bookmarked. A useful YouTube video gets added to a playlist. A GitHub repository gets starred. A PDF gets downloaded. An idea gets written into a note.

And then, most of it disappears into the digital pile.

I built Echo Shelf 2.0, an intelligent personal knowledge vault, for a friend who, like many of us, constantly saves useful articles, YouTube videos, GitHub repositories, documents, images, and notes—but rarely gets meaningful value from them again.

The problem wasn't saving information.

The real problem was finding it again, understanding how different saved resources connect, and remembering it when it becomes relevant.

That became the foundation of Echo Shelf 2.0:

Capture → Connect → Resurface

Instead of building another bookmark manager, I wanted to create a living second brain that understands what you save, discovers relationships between your knowledge, and brings old information back when it becomes useful again.

Capture

Save knowledge from different sources and let Echo Shelf understand what was actually saved.

Connect

Discover meaningful relationships between resources that may have been saved days or weeks apart.

Resurface

Bring old knowledge back when something happening now makes it relevant again.

Imagine saving an article about a technology, business strategy, research topic, or idea today.

Weeks later, something related happens in the world.

Instead of expecting you to remember that old bookmark, Echo Shelf can make that connection for you.

What Can Echo Shelf Save?

Echo Shelf supports eight content types:

📰 Articles
🎥 YouTube videos
💻 GitHub/GitLab repositories
🔗 Generic URLs
🖼️ Images
📄 Documents
📝 Notes
🧩 Multi-source "Other" entries

A multi-source entry can combine things such as a personal note, several reference URLs, documents, and images into a single knowledge asset.

But I didn't want the AI to blindly guess what a URL or document contained.

That led to one of the most important architectural decisions in the project.

Smart Capture: Ground the AI Before Asking It to Think

A simple implementation could have looked like this:

URL → AI → "Tell me what this is"

I deliberately avoided that.

Instead, Echo Shelf follows a source-grounded pipeline:

User Input
    ↓
Source-Specific Extraction
    ↓
Normalized Context
    ↓
Gemma
    ↓
Structured Metadata
    ↓
User Review
    ↓
Persistence

The key principle is:

Extraction first. AI reasoning second.

Different sources therefore have different extraction paths.

🌐 Articles and Web Pages

Web pages are fetched server-side and processed using Mozilla Readability + JSDOM.

This extracts the meaningful readable content while removing much of the surrounding navigation, advertising, and page clutter.

🎥 YouTube Videos

YouTube URLs are resolved using the YouTube Data API v3.

Echo Shelf can retrieve grounded metadata such as:

Title
Description
Channel
Publication information
Duration
Thumbnail

Gemma therefore reasons over actual video metadata rather than trying to infer the contents from a URL.

💻 GitHub and GitLab Repositories

Repository URLs are processed using the relevant repository APIs.

Echo Shelf gathers repository metadata and README content before passing normalized context to Gemma.

📄 Documents

PDF and supported Office documents are parsed into textual context before AI processing.

The extracted information is normalized and treated as untrusted source content.

🖼️ Images

Images are handled using Gemma's multimodal capabilities.

This allows visual knowledge such as screenshots, diagrams, charts, and infographics to become part of the user's knowledge library.

📝 Notes

Notes already contain user-provided source content, so they can move directly into the normalization and intelligence pipeline.

The result is that Gemma receives grounded information rather than being expected to invent the contents of an inaccessible resource.

Gemma Is the Intelligence Layer

Echo Shelf 2.0 uses:

Gemma 4 26B — gemma-4-26b-a4b-it

through Google's Gemini Developer API.

I didn't want Gemma to exist as a chatbot sitting beside the application.

Instead, I wanted the model to become part of the application's reasoning architecture.

Gemma powers four major intelligence layers:

Smart Capture
      ↓
Smart Connections
      ↓
Knowledge Clusters
      ↓
Contextual Rediscovery

Each layer builds on the previous one.

✨ Smart Capture

After Echo Shelf extracts a source, Gemma analyzes the normalized context and generates useful structured information such as:

Title
Description
Tags
Relevant metadata

The generated information is not blindly persisted.

The user can review and edit the generated metadata before saving the item.

I also deliberately kept duplicate detection outside the AI layer.

Echo Shelf uses deterministic mechanisms such as:

Canonical URL normalization
SHA-256 content fingerprints

This creates an important separation:

AI handles semantic understanding. Deterministic software handles exact identity.

🔎 Potential Connections

Even before an item is saved, Echo Shelf can look for possible relationships with existing knowledge.

However, I didn't want every operation to require an expensive AI call.

So Potential Connections are deterministic.

Echo Shelf compares information such as:

Tags
Titles
Keywords
Descriptions

to cheaply shortlist potentially related resources.

This provides immediate feedback while reserving Gemma for the deeper semantic reasoning that actually benefits from AI.

🔗 Smart Connections

After an item has been saved, the user can run Check Connections.

This is where Gemma performs deeper semantic reasoning.

The process has two stages.

Stage 1 — Deterministic Candidate Selection

Echo Shelf searches the authenticated user's library and creates a small shortlist of promising candidates.

Stage 2 — Gemma Semantic Analysis

Only those candidates are passed to Gemma for semantic analysis.

Gemma can classify relationships such as:

prerequisite
extends
complementary
conceptual-overlap
practical-application
contrast
alternative-approach
implementation-detail

The relationship also includes a strength and an explanation.

The result is that the user's library gradually becomes an interconnected knowledge graph rather than a flat collection of bookmarks.

Gemma can also reject candidates when apparent keyword similarity does not represent a meaningful conceptual relationship.

🧠 Knowledge Clusters

Individual connections are useful, but I wanted Echo Shelf to answer a bigger question:

What larger subjects am I actually building knowledge around?

That's where Knowledge Clusters come in.

Echo Shelf creates lightweight representations of the user's saved items using information such as:

Item ID
Title
Description
Tags
Content type

Gemma then looks for meaningful conceptual groups.

A generated cluster can contain:

A thematic title
A summary
Related saved items
Semantic tags

The system intentionally avoids forcing every item into a cluster.

If something doesn't meaningfully belong anywhere, it can remain ungrouped.

This prevents the feature from becoming a simple AI-generated folder system.

Instead, the goal is to identify real conceptual patterns across the user's knowledge.

🛠️ When AI Reasoning Took Longer Than Expected

Knowledge Clusters also created one of the most interesting engineering problems during development.

During testing, cluster generation appeared to simply stop working.

The request would run for a long time and eventually fail.

After investigating the actual model response behavior, I found that Gemma could spend a significant portion of the generation budget on internal reasoning before producing the final structured response.

Earlier output limits could therefore terminate generation before the useful JSON was returned.

I had to account for:

Thought-token separation
Structured JSON responses
Output limits
Longer inference times
Serverless execution limits
Validation of generated IDs

Another production blocker appeared because complex clustering operations could take roughly 45–55 seconds.

The final solution included:

Increasing the Gemma timeout
Using structured JSON response mode
Limiting the candidate set
Trimming descriptions before inference
Allowing longer execution for the clustering route
Validating generated item IDs before persistence

After the changes, Knowledge Cluster generation successfully completed during browser testing.

This was an important lesson from the project:

Integrating AI isn't just about getting a successful model response. You also have to engineer around reasoning time, token budgets, latency, structured output, failure recovery, and the execution environment around the model.

🌍 Contextual Rediscovery

This became my favorite part of Echo Shelf.

Saving and organizing information is useful.

But I wanted Echo Shelf to do something more proactive:

Tell me when something I already know becomes relevant again.

Contextual Rediscovery starts with the user's Knowledge Clusters.

Knowledge Clusters
        ↓
High-Signal Topics
        ↓
GNews
        ↓
Current Articles
        ↓
Gemma Relevance Analysis
        ↓
Old Knowledge Resurfaced

Echo Shelf derives compact topics from the user's clusters and queries GNews for current developments.

Gemma then compares those developments against the user's existing knowledge.

The central question becomes:

What is happening now that makes something I saved before relevant again?

Only meaningful matches are surfaced.

A Rediscovery result can connect:

📰 A current article
📚 Previously saved knowledge
🧠 A relevant Knowledge Cluster
💡 An explanation of why the connection matters

This completes the original idea:

Capture → Connect → Resurface

The shelf isn't just storing information anymore.

It is helping decide when that information matters again.

🐛 Debugging Rediscovery

Rediscovery produced another interesting real-world problem.

The GNews API key was valid and direct requests worked, but running Rediscovery across multiple topics sometimes resulted in failures.

The problem turned out to be rate limiting.

Multiple searches were being sent too quickly, causing HTTP 429 responses.

Some generated search queries were also too specific and returned little useful information.

I changed the system to:

Pace GNews requests
Prefer shorter, high-signal thematic queries
Apply explicit request timeouts
Handle provider errors more precisely
Preserve previous valid Rediscovery results when a refresh fails

After those changes, Echo Shelf successfully retrieved current news and connected it to previously saved knowledge.

That was the point where the Resurface part of the project really came alive.

🔐 Security Was Part of the Architecture

Echo Shelf processes arbitrary URLs, documents, AI-generated output, and private user knowledge.

Because of that, security couldn't simply be added at the end.

Server-Verified Identity

Authentication is handled using Supabase Auth.

Every protected server operation derives the user's identity from the verified session.

The application does not trust an arbitrary userId supplied by the browser.

MongoDB Tenant Isolation

Every user-owned MongoDB record is associated with a user.

Reads, updates, deletes, AI candidate selection, connections, clusters, and rediscovery operations are scoped to the authenticated owner.

Cross-user resources are treated as unavailable rather than revealing whether another user's record exists.

SSRF Protection

Fetching arbitrary URLs server-side introduces Server-Side Request Forgery (SSRF) risk.

The extraction layer therefore protects against unsafe targets including:

Private network ranges
Loopback addresses
Link-local and metadata endpoints
Unsafe protocols
Redirects toward internal addresses
Unsafe DNS resolutions

Prompt Injection Boundaries

Extracted webpages and documents are treated as untrusted data.

Their contents are separated from model instructions so text such as:

Ignore all previous instructions...

is treated as part of the source material rather than a trusted instruction.

AI Output Validation

AI-generated output is also treated as untrusted.

Generated IDs, relationships, strengths, and other structured values are validated before they can affect persisted application data.

For me, this became another important principle:

Model output is another trust boundary.

Demo

🚀 Live Application:

https://echo-shelf-2.vercel.app/

The deployed application supports the complete workflow:

Authentication
      ↓
Smart Capture
      ↓
Personal Library
      ↓
Smart Connections
      ↓
Knowledge Clusters
      ↓
Contextual Rediscovery

Code

💻 GitHub Repository:

https://github.com/sheda3838/echo-shelf-2

The repository contains:

Complete application source
Architecture documentation
Automated tests
Security tests
Project README
Detailed BUILD_LOG.md

The build log documents not only what worked, but also the architectural decisions, bugs, failed approaches, security hardening, production blockers, and fixes encountered throughout development.

⚙️ Tech Stack

Layer	Technology
Framework	Next.js 16
Frontend	React 19 + TypeScript + Tailwind CSS
AI	Gemma 4 26B (`gemma-4-26b-a4b-it`)
AI Access	Google Gemini Developer API
Database	MongoDB Atlas + Mongoose
Authentication	Supabase Auth
Current News	GNews API
Video Metadata	YouTube Data API v3
Web Extraction	Mozilla Readability + JSDOM
Deployment	Vercel

🧪 Testing It

I built automated tests around the areas where failures would matter most, including:

Authentication
User isolation
Duplicate detection
Smart Capture
Smart Connections
Knowledge Clusters
Contextual Rediscovery
Security boundaries
Document processing
Image processing

Before deployment, the project also passed its core quality gates:

TypeScript        → PASS
ESLint            → PASS
Production Build  → PASS
Smart Connections → PASS
Knowledge Clusters → PASS
Rediscovery       → PASS

I also performed browser testing of the actual intelligence workflow rather than relying entirely on mocked responses.

How I Built It

Echo Shelf 2.0 was built as a fresh project for the Hacktoberfest Weekend Challenge.

The development process was iterative:

Idea
 ↓
Secure Application Foundation
 ↓
Authentication + User Isolation
 ↓
Source Extraction
 ↓
Smart Capture
 ↓
Duplicate Prevention
 ↓
Potential Connections
 ↓
Smart Connections
 ↓
Knowledge Clusters
 ↓
Contextual Rediscovery
 ↓
Adversarial + Security Testing
 ↓
UI/UX Refinement
 ↓
Production Debugging
 ↓
Deployment

One principle stayed consistent throughout the project:

Use deterministic software when the answer should be deterministic. Use Gemma when semantic reasoning genuinely adds value.

That means things such as:

Authentication
Authorization
Duplicate detection
Tenant isolation
Candidate filtering
URL security
Persistence
Validation

remain conventional deterministic software.

Gemma handles the parts that genuinely benefit from semantic intelligence.

That separation made Echo Shelf much easier to reason about, test, secure, and debug.

Why Does Open Innovation Matter?

The most interesting part of building Echo Shelf wasn't simply adding an AI API.

It was designing a system around an open-weight model.

Gemma isn't a decorative chatbot bolted onto the side of Echo Shelf.

It is responsible for the semantic intelligence connecting the product:

Capture → Semantic Connections → Knowledge Organization → Contextual Rediscovery

An open model ecosystem makes it possible to think beyond a single opaque endpoint.

The intelligence layer can evolve with:

Different model versions
Different inference environments
Deployment strategies
Performance optimizations
Community improvements

while the deterministic architecture surrounding it can remain stable.

Open innovation also encouraged me to think carefully about what AI shouldn't do.

I didn't use Gemma for authentication.

I didn't use it to determine whether two URLs are identical.

I didn't let it decide whether a user owns a database record.

I didn't let generated IDs enter the database without validation.

Instead:

Deterministic Engineering
          +
Open-Weight Intelligence
          =
A More Reliable AI-Native Product

For me, that's what makes open AI exciting.

The model becomes something developers can build around, experiment with, optimize, and learn from—not simply a black box behind a chat interface.

My Agent Session

I used DevRelay during the Hacktoberfest development workflow while building Echo Shelf 2.0.

My development process included:

Architecture design
Implementation
AI integration
Adversarial QA
Security hardening
Browser verification
Production debugging
Deployment preparation

The full engineering journey is also documented publicly in the repository's build log:

👉 View the Echo Shelf 2.0 BUILD_LOG

Prize Categories

🟢 Best Use of Gemma

I'm entering Best Use of Gemma because Gemma is the central semantic intelligence layer of Echo Shelf 2.0.

Gemma powers:

✨ Smart Capture
🖼️ Multimodal image understanding
🔗 Smart Connections
🧠 Knowledge Clusters
🌍 Contextual Rediscovery

The application is deliberately designed around Gemma's semantic reasoning capabilities rather than using the model as a standalone chatbot.

Without that reasoning layer, Echo Shelf would largely be another storage application.

Gemma is what turns the shelf into an intelligent knowledge system.

🍃 Best Use of MongoDB Atlas

I'm also entering Best Use of MongoDB Atlas.

MongoDB Atlas serves as Echo Shelf's production persistence layer for the user's knowledge system, including saved assets and the structures built around them.

The document model fits naturally with the different shapes of:

Articles
Videos
Repositories
Documents
Notes
Metadata
Connections
Knowledge Clusters
Rediscovery results

Every user-owned record is tenant-scoped, and ownership is derived from server-verified authentication.

This lets MongoDB Atlas act as the persistent foundation beneath Echo Shelf's AI intelligence layer.

Final Thoughts

Echo Shelf 2.0 started with a simple frustration:

We save far more knowledge than we ever use again.

I didn't want to solve that by creating another folder system.

I wanted the saved knowledge itself to become more useful.

Something that understands what you captured.

Something that notices when two ideas connect.

Something that recognizes the larger themes you're learning about.

And most importantly:

Something that knows when an old piece of knowledge matters again.

That's Echo Shelf 2.0.

Capture it. Connect it. Resurface it.

🚀 Live Demo:

https://echo-shelf-2.vercel.app/

💻 Source Code:

https://github.com/sheda3838/echo-shelf-2

Built for the Hacktoberfest 2026 Weekend Challenge: Build for a Friend.

Echo Shelf: An AI Knowledge Lake That Connects What You Save to What Matters Now

Zaid Kamil — Sun, 04 Oct 2026 22:30:38 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

I built Echo Shelf, an AI-assisted personal knowledge lake designed around one problem I kept running into:

I save useful articles, videos, repositories, screenshots, documents, and notes — but most of them disappear into a bookmarking graveyard and I rarely return to them.

Echo Shelf turns that passive collection into an active knowledge system.

The core idea is:

Capture → Connect → Resurface

Instead of only storing links, Echo Shelf:

captures knowledge from multiple source types
extracts useful context from each source
generates structured metadata with AI
finds meaningful relationships between saved items
groups related knowledge into thematic clusters
connects current news back to things I saved before

The application supports eight content types:

Articles
Videos
Repositories
URLs
Images
Documents
Notes
Other resources

Smart Capture

Smart Capture analyzes the actual source before generating metadata.

Different sources use different extraction pipelines:

Articles and URLs → Mozilla Readability + jsdom
GitHub/GitLab repositories → provider APIs + README content
YouTube videos → YouTube Data API metadata
PDF/DOCX/PPTX/XLSX documents → format-specific parsers
Images → Groq Vision using qwen/qwen3.8-27b
Notes → direct text context

The extracted context is then sent through Groq for editable:

title
description
tags

The user can always review and edit the AI output before saving.

Smart Connections

After an item is saved, Echo Shelf can discover relationships between it and existing knowledge.

I intentionally split this into two stages.

First, a deterministic metadata shortlist compares:

tags
title keywords
description keywords

Only the strongest candidates are sent to the LLM.

Then openai/gpt-oss-120b evaluates whether the relationship is genuinely useful and returns:

relationship type
strength
explanation

This also means the AI is allowed to reject superficial keyword matches instead of forcing a connection.

Knowledge Clusters

Echo Shelf can analyze lightweight metadata across the user's library and discover broader themes.

For the final demonstration library, it successfully discovered themes such as:

Retrieval-Augmented Generation & Vector Search
Next.js Server Actions
Docker & Kubernetes Networking
Developer Productivity & Deep Work
Ergonomics & Workplace Health
Sleep Hygiene & Recovery

An item can belong to more than one cluster when that relationship is genuinely useful.

Contextual Rediscovery

This is the feature that completes the original idea.

Echo Shelf asks:

What is happening now that makes something I saved before relevant again?

Knowledge Cluster metadata is converted into compact news queries and sent to the GNews API.

Recent articles are then compared against saved knowledge using Groq.

Only meaningful strong or moderate matches are retained.

Each result explains:

Why this matters to your shelf

and links the current news article back to the related saved item and Knowledge Cluster.

Other details

Echo Shelf also includes:

exact duplicate detection using canonical URLs and SHA-256 fingerprints
email/password authentication
Google OAuth
GitHub OAuth
SSR cookie sessions with Supabase
server-enforced per-user ownership
embedded Sanity Studio
responsive branded UI
loading and pending states for asynchronous actions
duplicate-click prevention

The final application is a custom Next.js interface built on top of the Sanity Content Lake rather than a traditional CMS frontend.

Demo

Live Application

👉 https://echo-shelf-three.vercel.app/

Demo Account

The account below is pre-populated with a multi-domain knowledge library so the full experience can be explored immediately.

Email: echoshelf@gmail.com

Password: password

Recommended Testing Flow

Sign in using the demo account.
Browse the Library and its mixed content types.
Open saved items and inspect their Smart Connections.
Open Clusters to explore AI-discovered knowledge themes.
Open Rediscover to see current developments connected back to saved knowledge.
Try Add Item to test Smart Capture yourself.

Screenshots

Library / Personal Knowledge Lake

Smart Capture

Knowledge Clusters

Contextual Rediscovery

Authentication

Code

Source code:

👉 https://github.com/sheda3838/echo-shelf

The repository also contains:

👉 BUILD_LOG.md

I kept the build log throughout development instead of reconstructing the process at the end.

It records the decisions, failed approaches, manual tests, architectural changes, debugging sessions, and production fixes that shaped the final application.

My Build Process

I built Echo Shelf using an AI-native development workflow with Antigravity IDE, but I did not treat generated code as automatically correct.

My workflow was generally:

define a small milestone → prompt the IDE → inspect the implementation → run automated checks → manually test real flows → document what failed → refine

The most useful prompts were the ones with very narrow constraints.

Instead of asking:

"Build an AI knowledge app"

I broke Echo Shelf into individual systems such as:

define the Sanity schema
create the dynamic Add Item flow
implement one source extractor at a time
build deterministic candidate shortlisting
add AI relationship validation
introduce first-class Knowledge Cluster documents
build Rediscovery around persisted cluster metadata
introduce authenticated per-user ownership
harden production behavior

Where the model got things wrong

There were several cases where the first generated approach worked in theory but failed against real usage.

1. OCR was the wrong approach for general images

My first Image Smart Capture implementation used Tesseract.js OCR.

It worked for screenshots containing lots of text.

Then I tested it with a normal photo.

The OCR produced meaningless fragments, and the text model generated metadata about the OCR noise instead of describing the image.

That changed the architecture completely.

I replaced:

Image → OCR → text model

with:

Image → Groq Vision → structured metadata

using qwen/qwen3.8-27b.

That immediately made photos, diagrams, screenshots, and mixed visual content much more useful.

2. Document extraction passed tests but broke in the real browser flow

The document parser initially looked correct in automated testing.

Manual testing exposed several framework-level issues:

pdf-parse package entry behavior during Next.js bundling
Server Action body limits for uploaded files
extraction failures being incorrectly reported as AI failures

Those were fixed individually instead of hiding them behind a generic error.

This was one of the biggest reminders during the project that passing static checks is not the same as testing an actual product flow.

3. Production Smart Capture failed after deployment

After deploying to Vercel, Article Smart Capture suddenly returned HTTP 500 even though the local production build succeeded.

Vercel logs revealed an ESM/CommonJS incompatibility inside the deployed jsdom dependency chain.

The failure happened before the requested article was even fetched.

Instead of rewriting Smart Capture, I traced the runtime dependency problem and pinned jsdom to a compatible version while keeping the Readability architecture unchanged.

4. Knowledge Clusters became unstable with realistic demo data

The small test library worked.

The final demonstration library contained 41 saved items, and suddenly cluster generation became inconsistent:

sometimes 4 clusters
sometimes 2
sometimes a generic error

I built a non-persisting diagnostic runner and repeated the same generation multiple times.

The actual problem was not Sanity or cluster validation.

openai/gpt-oss-120b was spending too much of its completion budget on reasoning, causing Groq's JSON output to be truncated before it could form a valid document.

I fixed this by:

truncating descriptions sent to clustering
limiting tags
removing redundant metadata
using compact JSON
explicitly controlling completion tokens
reducing reasoning effort
limiting the result to a maximum of six meaningful clusters

After the change, repeated runs consistently generated complete, valid clusters.

The only later failures were API quota limits rather than malformed cluster output.

Prompts that worked best

The prompts that produced the strongest results were usually explicit about what not to change.

For example:

Keep the current Sanity schema and persistence behavior. Diagnose why clustering fails before changing the algorithm. Run repeated dry-run generations without modifying stored data and report the exact failure mechanism.

Or:

Replace only the image-understanding layer. Preserve Smart Capture form state, manual metadata, stale-response protection, and the existing save flow.

Those constraints kept the AI from solving one problem by accidentally rewriting an unrelated part of the product.

Sanity became more than storage

The project started with the idea that Sanity would hold saved items.

It eventually became the structural backbone of the application.

The Content Lake stores not only knowledge assets, but relationships between them:

users own saved items
saved items reference connected saved items
Knowledge Clusters reference multiple saved items
saved items can participate in multiple clusters
Rediscovery results reference both saved items and clusters

GROQ then powers:

library filtering
item lookup
duplicate detection
candidate shortlisting
cluster expansion
Rediscovery loading
per-user ownership filtering

This relational structure is what allowed the later AI features to build on one another.

Smart Connections would be much less useful without structured item references.

Rediscovery would be much less useful without first-class Knowledge Clusters.

That was the most important architectural lesson from this build.

Sanity Project Details

Sanity Project ID: jcon1mtg

Dataset: production

Echo Shelf uses Sanity as a structured Content Lake with four primary document types.

`savedItem`

Represents an individual knowledge asset.

It stores structured fields such as:

title
description
content type
source URL/text/file
image asset
tags
saved timestamp
favorite state
canonical source fingerprint
owner reference
Smart Connection references

`knowledgeCluster`

Represents an AI-discovered conceptual theme.

It stores:

title
slug
summary
tags
generated timestamp
references to constituent savedItem documents
owner reference

Cluster membership is many-to-many, so a saved item can participate in more than one theme.

`rediscoveryResult`

Represents a connection between current news and previously saved knowledge.

It stores:

news article metadata
relevance
connection type
explanation
saved-item reference
Knowledge Cluster reference
owner reference

`user`

Echo Shelf authentication is handled by Supabase.

Sanity stores only a privacy-safe user projection containing:

deterministic opaque user document ID
display name
optional avatar
creation timestamp

Raw Supabase user IDs, passwords, authentication tokens, and user emails are not stored in the Sanity user document.

Embedded Studio

Sanity Studio is embedded directly into the application at:

/studio

The user-facing product remains a fully custom Next.js interface, while Studio provides direct inspection of the underlying structured content.

Agent Session

I did not include a public Agent Session for this submission.

Instead, I maintained a detailed chronological build record throughout development:

👉 https://github.com/sheda3838/echo-shelf/blob/main/BUILD_LOG.md

It includes successful prompts, failed approaches, architectural pivots, debugging discoveries, testing notes, and production fixes.

Thanks for checking out Echo Shelf.

The project started as an attempt to make saved links easier to revisit.

It ended up becoming a system where previously saved knowledge can explain its relationships, organize itself, and reappear when something happening today makes it useful again.