# KnowHub Operations Design: Write Operations for the Console

## Memory & Knowledge Management Console for AI Agents

**Version:** 1.0
**Date:** 2026-03-19
**Status:** Design Workshop Output
**Prerequisite:** Product Design V2 (storage-aware redesign with Memory/Library/Skills separation)

---

# Part I: Product Design Workshop -- Write Operations

## Participants

| Expert | Background | Specialty |
|--------|-----------|-----------|
| **Steve Jobs** | Legendary product visionary | Ruthless simplicity, saying no to 1000 things |
| **Kenya Hara** | Art director of MUJI, master of emptiness | Restraint, whitespace, sensory design |
| **Mitsuru Kariya** | Creator of Notion's collaboration model | Human-AI shared workspaces, authorship boundaries |
| **Julie Zhuo** | Former VP Design at Facebook | Real user behavior vs imagined user behavior |
| **Allen Zhang** | Creator of WeChat | "Less is more," resisting feature bloat |

---

## Round 1: What Pain Points Does a Read-Only Console Create?

**Topic:** Concrete scenarios where the human owner is stuck and needs to act but cannot.

**Julie Zhuo:** Let me start with the scenarios I have observed in similar tools. The read-only console creates three categories of pain. First, the "wrong memory" problem. Your agent learned something incorrect -- maybe it recorded "user prefers formal tone" when actually you told it to use a casual tone. You can see the bad memory right there in the console. You cannot fix it. You cannot delete it. You cannot even flag it. Your only recourse is to go to the agent's API, find the right issue number, and PATCH it via CLI or curl. That is not a management console. That is a surveillance camera.

**Steve Jobs:** The second category is "missing content." Your agent has an empty library. You want to upload your brand guidelines, your product specs, your style guide. These are human-authored documents. The agent did not create them and cannot create them. They need to come from you. But the console only lets you look at what is already there. So you have to SSH into the git service, commit files manually, push them. We built a beautiful bookshelf and then welded the door shut.

**Kenya Hara:** The third category is more subtle but perhaps more important. It is the absence of care. When I look at a garden through a window, I feel separated from it. I can admire it but I cannot tend it. A console that is read-only creates this glass wall between the owner and their agent's mind. The act of pruning a memory, correcting a fact, adding a note -- these are acts of care. They are how an owner shapes and guides their agent. Without them, the owner is a spectator, not a steward.

**Mitsuru Kariya:** Let me give concrete scenarios from the collaboration angle:

1. **The toxic memory.** Agent recorded something from a conversation with a client that contains PII or confidential information. Owner sees it, cannot delete it. This is not just inconvenient -- it is a compliance risk.

2. **The empty vault.** New user sets up an agent, connects it to KnowHub. The vault is empty. There is literally nothing to see. The only thing the user can do is... leave? There is no onboarding action. No "upload your first document." No "create your first skill." The read-only console makes the first-run experience a dead end.

3. **The stale skill.** An agent has a skill for "writing email subject lines" that uses an outdated format. The owner knows the new format. They can see the skill. They cannot update it. They have to somehow instruct the agent to rewrite its own skill, which is a bizarre indirection.

4. **The shared space void.** The owner wants to create a shared knowledge base for their team's agents. They click "Shared Spaces" and see... nothing. There is no "Create" button. They cannot set up the space that would let their agents collaborate.

**Allen Zhang:** I want to push back on the instinct to solve all of these with write operations. Some of these are real pain. Some are imagined. The toxic memory scenario -- yes, deletion is essential. The empty vault -- does the solution have to be "let humans upload"? Or could the agent populate its own vault as it works? The stale skill -- why not tell the agent "update your email subject line skill"? We must be careful not to build a full CMS when what we need are surgical interventions.

**Julie Zhuo:** Allen is right to push back. But there is a data point he is missing. In every knowledge management tool I have studied, the first-run experience determines whether users come back. If the vault is empty and the user cannot do anything, they close the tab. They never return. The agent populates its vault over time, but the owner has already forgotten KnowHub exists. We need at least one write operation that gives the user agency on day one.

**Steve Jobs:** Let me name the essential pain points, not the nice-to-have ones:

1. **Cannot correct agent errors** -- the agent learned wrong, and you cannot fix it
2. **Cannot remove dangerous content** -- PII, confidential data, offensive content
3. **Cannot seed the vault** -- no way to give the agent reference material it needs
4. **Cannot create the workspace** -- shared spaces cannot be created from the UI
5. **Cannot tend the garden** -- no ability to prune, annotate, or curate

These are the real blockers. Everything else is optimization.

### Round 1 Conclusion:
The read-only console creates five categories of real pain:
1. Error correction (wrong memories, outdated skills)
2. Content safety (PII removal, confidential data deletion)
3. Content seeding (uploading reference documents, creating initial knowledge)
4. Workspace creation (shared spaces have no creation flow)
5. Curation (pruning, annotating, organizing over time)

---

## Round 2: Categorize All Possible Operations

**Topic:** List every conceivable write operation, then categorize.

**Mitsuru Kariya:** Let me enumerate every write operation we could conceivably add, organized by content type.

### Memory Operations
| # | Operation | Description |
|---|-----------|-------------|
| M1 | Archive memory | Move a memory from active to archived status |
| M2 | Delete memory | Permanently remove a memory |
| M3 | Edit memory content | Change the text of a memory |
| M4 | Edit memory title | Change the title of a memory |
| M5 | Change memory importance | Adjust the importance score |
| M6 | Add/remove tags | Modify labels on a memory |
| M7 | Add comment | Annotate a memory with an owner note |
| M8 | Create memory | Human-authored memory injection |
| M9 | Bulk archive | Archive multiple memories at once |
| M10 | Bulk delete | Delete multiple memories at once |
| M11 | Merge memories | Combine duplicate/similar memories |
| M12 | Pin memory | Pin an important memory to the top |

### Conversation Operations
| # | Operation | Description |
|---|-----------|-------------|
| C1 | Delete conversation | Remove an entire conversation thread |
| C2 | Annotate conversation | Add owner note to a conversation |
| C3 | Export conversation | Download conversation as file |
| C4 | Redact message | Remove specific messages within a conversation |

### Document (Library) Operations
| # | Operation | Description |
|---|-----------|-------------|
| D1 | Upload document | Add a new file to the library |
| D2 | Edit document | Modify document content inline |
| D3 | Delete document | Remove a document from the library |
| D4 | Create document | Write a new document from scratch in the UI |
| D5 | Rename document | Change filename |
| D6 | Move document | Change folder location |
| D7 | Create folder | Add new directory in the library |
| D8 | Delete folder | Remove a directory |

### Skill Operations
| # | Operation | Description |
|---|-----------|-------------|
| S1 | Edit skill | Modify skill content/steps |
| S2 | Delete skill | Remove a skill |
| S3 | Create skill | Author a new skill from scratch |
| S4 | Duplicate skill | Copy a skill as starting point |
| S5 | Enable/disable skill | Toggle whether agent uses this skill |

### Vault Operations
| # | Operation | Description |
|---|-----------|-------------|
| V1 | Create vault | Create a new agent vault |
| V2 | Delete vault | Permanently remove a vault |
| V3 | Edit vault settings | Change name, description, policies |
| V4 | Create shared space | Set up a new shared knowledge base |
| V5 | Delete shared space | Remove a shared space |
| V6 | Edit shared space settings | Change name, members, policies |

**Steve Jobs:** That is 36 operations. We are shipping maybe 5. Let me categorize.

**Julie Zhuo:** Before we categorize, let me apply a behavioral filter. What percentage of users would actually use each operation in their first month? I will estimate based on analogous products:

- >80% of users: Delete memory (M2), Upload document (D1), Create shared space (V4)
- 50-80%: Archive memory (M1), Add comment (M7), Edit document (D2), Edit vault settings (V3)
- 20-50%: Delete document (D3), Edit skill (S1), Add/remove tags (M6), Create folder (D7)
- <20%: Everything else

**Allen Zhang:** Good. Now let me apply the "agent can do it" filter. Which of these operations does the agent already do well via API?

- **Agent does well:** Create memory (M8 -- agents create their own memories), Create document (D4 -- agents can write files), Create skill (S3 -- agents develop skills), Merge memories (M11 -- agents can consolidate), Move document (D6), Rename document (D5)
- **Agent cannot do:** Delete anything (agents should not self-delete), Upload human files (D1), Correct their own errors (they do not know what is wrong), Create shared spaces (infrastructure concern)
- **Debatable:** Edit memory (M3 -- agent could rewrite, but human knows the correction), Edit skill (S1 -- agent could relearn, but human may know the fix)

**Steve Jobs:** Now the categorization becomes clear:

### Essential (solves real pain, high usage, agent cannot do it)
- M1: Archive memory
- M2: Delete memory
- M7: Add comment on memory
- D1: Upload document
- D2: Edit document
- V4: Create shared space

### Nice-to-have (useful but not blocking)
- M6: Add/remove tags
- M5: Change importance
- D3: Delete document
- D7: Create folder
- S1: Edit skill
- V3: Edit vault settings
- C1: Delete conversation

### Unnecessary (agent does it better, or low usage)
- M8: Create memory (agents create memories, humans should not)
- M3: Edit memory content (annotate via comment instead)
- D4: Create document from scratch (use upload, or edit an uploaded template)
- S3: Create skill (agents learn skills)
- M11: Merge memories (agent consolidation is better)
- M9/M10: Bulk operations (premature optimization)

### Harmful (would damage the product's clarity)
- M12: Pin memory (creates a curation burden, memories should surface by relevance)
- S5: Enable/disable skill (creates a permission model that confuses agents)
- C4: Redact message (partial deletion is dangerous, delete the whole conversation)

**Kenya Hara:** I agree with the essential list, but I want to make one philosophical argument. The categories should honor the principle that agents are the primary authors and humans are the stewards. Every operation we add should feel like tending, not creating. The owner prunes, corrects, enriches. The agent plants, grows, produces. If we add "create memory," we blur this boundary. The owner's voice enters through comments and annotations, not through creating content that looks like agent-authored content.

**Mitsuru Kariya:** Kenya's principle is exactly right, with one exception: the Library. Documents are the one content type where human authorship is natural. Brand guidelines, product specs, reference materials -- these come from the human. The agent consults them. So "upload document" and "edit document" are not stewardship operations. They are provisioning operations. The owner stocks the library. The agent reads from it.

### Round 2 Conclusion:
36 possible operations categorized into Essential (6), Nice-to-have (7), Unnecessary (6), Harmful (3). The guiding principle: agents author, humans steward -- except for the Library, where humans provision and agents consult.

---

## Round 3: The Memory Management Debate

**Topic:** Should humans edit agent memories? Delete them? Add their own? What is the right boundary?

**Julie Zhuo:** The data from every note-taking and CRM tool tells us the same story: users want to delete and annotate far more than they want to create or edit. In Evernote, the top action after reading a note was deleting it. In Salesforce, the top action on an activity log was adding a note. People are curators, not authors, when it comes to someone else's observations.

**Allen Zhang:** This aligns with what I see in messaging products. In WeChat, users almost never edit messages. They delete or they reply. The mental model is: what was said was said. You can remove it or you can respond to it. You do not rewrite history. Memories should work the same way. The agent observed something. The owner can say "this is wrong" (comment) or "this should not exist" (delete). But rewriting the memory itself is revisionist. It breaks the provenance chain.

**Steve Jobs:** I agree. Let me define the memory operations precisely:

1. **Archive memory** -- Move to archived status. The memory still exists but is deprioritized in the agent's retrieval. This is the "gentle" removal. The memory fades rather than disappearing. UI: single click on a status indicator or an action button.

2. **Delete memory** -- Permanent removal. The issue is closed and deleted. This is for PII, errors, or content that should never have existed. UI: requires confirmation because it is irreversible. Two-step: click delete, then confirm.

3. **Add comment** -- The owner's voice. A comment on a memory serves multiple purposes: correcting an error ("Actually, the user prefers casual tone, not formal"), providing context ("This was from a test conversation, not a real interaction"), flagging importance ("This is critical -- make sure to always remember this"). The comment is visually distinct from the memory content. It is clearly the owner speaking, not the agent.

**Kenya Hara:** I want to add nuance to the comment interaction. A comment on a memory should feel like writing in the margin of a book. It should not feel like filing a ticket. The input should be lightweight -- a single text field that appears when you click "Add note." No title, no category, no formatting toolbar. Just the thought, attributed to the owner, timestamped. The ma (space) between the agent's memory and the owner's note is what creates meaning.

**Mitsuru Kariya:** What about editing the memory content directly? I know Allen argues against it, but there is a pragmatic case. If the agent recorded "User's favorite color is blue" and it should be "green," is it really better to leave the wrong memory and add a comment saying "Actually green"? The agent will retrieve both the wrong memory and the correction. Depending on its retrieval logic, it might still use the wrong one.

**Allen Zhang:** That is a fair point. But consider the alternative. If we let humans edit memory content, we lose the audit trail. We no longer know what the agent originally observed versus what the human corrected. This matters for debugging. When an agent behaves unexpectedly, the owner needs to know: "Did the agent learn this wrong, or did I accidentally edit it to be wrong?" Comments preserve this distinction. Edits erase it.

**Julie Zhuo:** Allen is right in theory, but wrong in practice. Users do not think about audit trails. They think "this is wrong, let me fix it." If we force them through the comment indirection, 80% will not bother. They will just leave the wrong memory. The "correct" pattern matters less than the pattern people will actually use.

**Steve Jobs:** Here is the resolution. We do NOT add inline editing of memory content. But we do make comments powerful enough that they function as corrections. The agent's retrieval system should treat owner comments as authoritative corrections. If a memory says "blue" and an owner comment says "Actually green," the agent should use "green." This is not a UI problem. It is a retrieval problem. The UI just needs to make commenting fast and obvious.

**Mitsuru Kariya:** I accept that, but I want one addition: the ability to edit tags and importance. These are not "content" -- they are metadata. Changing a tag from "preference" to "preference, critical" does not rewrite history. It reorganizes. Changing importance from 0.3 to 0.9 does not change what was observed. It changes how much weight it carries. These metadata edits should be allowed.

**Allen Zhang:** Tags and importance are acceptable. They are curation, not revision. But I want to keep the interaction minimal. No elaborate tag management UI. Click a tag, type a new one, press enter. Adjust importance with a simple slider or +/- buttons.

### Round 3 Conclusion:
Memory operations for v1:
- **Archive**: Yes. Single-click status change.
- **Delete**: Yes. With confirmation dialog.
- **Add comment**: Yes. Lightweight text input, functions as correction mechanism.
- **Edit content**: No. Comments serve as authoritative corrections instead.
- **Edit tags**: Deferred to nice-to-have. Not essential for v1.
- **Edit importance**: Deferred to nice-to-have.
- **Create memory**: No. Memories are agent-authored. Humans annotate, not author.

---

## Round 4: The Conversation Management Debate

**Topic:** Can/should humans annotate conversations? Delete sensitive conversations? Export them?

**Julie Zhuo:** Conversations are the most sensitive content type. They contain raw dialogue -- possibly with clients, possibly with internal stakeholders. The read-only console means an owner who discovers their agent recorded a conversation containing a client's social security number cannot do anything about it. That is a lawsuit waiting to happen.

**Allen Zhang:** Delete is non-negotiable for conversations. But I want to be precise: delete the entire conversation, not individual messages within it. Partial deletion of a conversation is dangerous -- it changes meaning. "I agreed to the terms" without the preceding "I would never say" becomes something completely different. Whole-conversation deletion only.

**Steve Jobs:** I agree. One operation for conversations: delete. That is it.

**Mitsuru Kariya:** What about annotation? In Notion, users frequently add notes to meeting transcripts. "Action items from this conversation:" or "Follow up needed on X." These annotations add value without changing the original content.

**Kenya Hara:** I see the value, but I question the frequency. How often does an owner read through a full conversation and want to annotate it? Conversations are high-volume, low-attention content. The owner glances at the list, maybe opens one or two, and moves on. Annotation implies deep engagement with the content. Is that realistic?

**Julie Zhuo:** Kenya is right about typical behavior. In every analytics tool I have seen, conversation logs get less than 5% of the attention that individual memories get. Users scan the list, occasionally dive in, but they do not linger. Annotation of conversations is a nice-to-have that fewer than 10% would use.

**Allen Zhang:** Then the answer is clear. One operation for conversations: delete. No annotation, no export, no redaction. Delete the whole thing. We can add annotation later if data shows users wanting it.

**Steve Jobs:** What about export? "Download this conversation as a text file"?

**Julie Zhuo:** Export is a read operation disguised as a write operation. It does not change any data. It is just a different way to consume the content. We should add it, but it does not belong in this discussion about write operations. It is a view/download button, not a mutation.

### Round 4 Conclusion:
Conversation operations for v1:
- **Delete conversation**: Yes. Whole-conversation deletion with confirmation.
- **Annotate**: No. Low usage, low value relative to effort.
- **Export**: Not a write operation. Add as a view feature separately.
- **Redact messages**: No. Partial deletion is dangerous.

---

## Round 5: The Knowledge Management Debate

**Topic:** Should humans upload documents? Edit knowledge files? This is the most natural human-authored content.

**Steve Jobs:** This is the easiest debate. Documents are the one content type where human authorship is primary. When I hire an employee, I give them the employee handbook, the style guide, the product roadmap. When I set up an AI agent, I should give it the same materials. Upload is essential. Edit is essential. These are not "stewardship" operations. They are the core value proposition of the Library section.

**Kenya Hara:** I agree, but I want to discuss the quality of the interaction. Uploading a document should not feel like filing a tax return. It should feel like placing a book on a shelf. Drag and drop a file. It appears in the library. No form fields to fill out, no metadata to configure, no category to select. The file name becomes the title. The directory becomes the location. The content speaks for itself.

**Mitsuru Kariya:** The editing experience is where we need to be more careful. The document viewer already has an edit mode -- the `DocumentViewer` component supports inline editing with a save button and Ctrl+S. But the interaction currently is not connected to any backend. We need to wire it up. The key question is: what happens when both the human and the agent edit the same document? We need to decide on conflict resolution.

**Allen Zhang:** For v1, do not solve conflicts. The agent-git-service uses SHA-based content addressing. If the human's edit is based on stale content, the PUT will fail. Show an error: "This document was updated. Please refresh and try again." Simple, honest, no magic.

**Julie Zhuo:** I want to talk about upload specifically. What file types do we support? Markdown is obvious. But users will want to upload PDFs, images, Word documents. If we only support markdown, we disappoint 60% of users on their first upload attempt.

**Steve Jobs:** For v1, markdown and plain text. The git backend stores files. Any file can be committed. But our viewer only renders markdown and plain text. If someone uploads a PDF, we can store it, show its filename and size, but we cannot render it inline. That is acceptable. The file is still in the library, still accessible to the agent. We just cannot preview it in the console yet.

**Mitsuru Kariya:** What about creating new documents from scratch? Not uploading, but writing directly in the editor?

**Allen Zhang:** That is the same operation as "upload" plus "edit." You upload an empty file (or we create one), then you edit it. We do not need a separate "create" operation. But we do need a "New Document" button that creates an empty markdown file in a chosen folder and immediately opens the editor. This is upload with zero friction.

**Steve Jobs:** Good. So the operations are: Upload (including "new blank document"), Edit, and Delete. Three operations for the Library.

**Kenya Hara:** Delete deserves the same ceremony as memory deletion. Not more, not less. A confirmation dialog: "This will remove [document name] from the library. This action cannot be undone." The same pattern everywhere. Consistency is a form of respect.

### Round 5 Conclusion:
Document operations for v1:
- **Upload document**: Yes. Drag-and-drop or file picker. Supports any file type. Markdown/text get inline preview.
- **Create new document**: Yes. "New Document" button creates blank markdown file, opens editor.
- **Edit document**: Yes. Inline editing in the document viewer. Ctrl+S to save. SHA-based conflict detection.
- **Delete document**: Yes. With confirmation dialog.
- **Create folder**: Deferred. Users can specify path during upload to implicitly create folders.
- **Move/rename**: Deferred. Not essential for v1.

---

## Round 6: The Skill Management Debate

**Topic:** Should humans write skills? Edit agent skills? Or should skills be agent-authored only?

**Mitsuru Kariya:** This is the most nuanced debate. Skills sit at the boundary between human expertise and agent capability. A skill is a workflow template -- "how to write a product description" or "how to summarize a meeting." Some skills emerge from agent experience (the agent learned a pattern). Some skills should come from human expertise (the marketing director knows the brand voice rules). Both are valid.

**Allen Zhang:** But in practice, how many users will actually write a skill file from scratch? Skills have structure: parameters, steps, triggers. Writing a skill is closer to programming than to writing a document. I predict fewer than 5% of users would create a skill in the first month.

**Julie Zhuo:** Allen is right about creation from scratch. But editing is different. A user sees a skill the agent learned, notices the steps are slightly wrong, and wants to fix step 3. That is a much lower bar than creating from nothing. Edit is high value. Create is low value.

**Steve Jobs:** Let me challenge this. Skills are files in the git repo. Editing a skill is technically identical to editing a document. It is the same API call: PUT /repos/{owner}/{repo}/contents/{path}. The only difference is the path (skills/ vs knowledge/) and how we render the content. If we already have document editing, do we need a separate "edit skill" concept? Or do we just... let people edit the file?

**Kenya Hara:** Steve raises the right point. The skill detail view already has an "Edit" button in the UI. The interaction should be the same as document editing: click edit, modify the content, save. The fact that it is a skill file rather than a knowledge file is a rendering concern, not an interaction concern.

**Mitsuru Kariya:** I agree, but with a caveat. Skills have structured content -- parameters, steps, triggers. If we let users edit the raw markdown, they might break the structure. A skill file that the agent can no longer parse is worse than a slightly wrong skill. Should we provide a structured editor -- form fields for each parameter and step -- instead of raw text editing?

**Allen Zhang:** Absolutely not. A structured skill editor is a feature that would take weeks to build, serve fewer than 5% of users, and create a maintenance burden forever. Raw text editing is honest. If the user breaks the structure, the agent will report a parse error, and the user will fix it. Do not build guardrails for problems that barely exist.

**Steve Jobs:** Agreed. Edit skill = edit the file. Same interaction as document editing. No separate creation flow. If a user wants to add a skill, they upload a skill file to the skills/ directory. Same upload mechanism as documents, different destination.

**Julie Zhuo:** One thing I do want: the ability to delete a skill. If an agent learned a bad skill -- say, a "customer response" skill that uses offensive language -- the owner needs to remove it. Same as deleting a document. Same confirmation pattern.

### Round 6 Conclusion:
Skill operations for v1:
- **Edit skill**: Yes. Same inline editing as documents. Raw text, not structured editor.
- **Delete skill**: Yes. Same confirmation pattern as documents.
- **Create skill**: No separate creation flow. Upload a file to skills/ directory.
- **Structured skill editor**: No. Too complex, too few users.
- **Enable/disable**: No. Creates confusing permission model.

---

## Round 7: The Vault Management Debate

**Topic:** Create vault? Delete vault? Change private/shared? Invite collaborators?

**Steve Jobs:** Vault creation is infrastructure. When an agent is set up, it gets a vault. The user should not manually create vaults. That is like manually creating a home directory for a new user. It should happen automatically.

**Mitsuru Kariya:** But shared spaces are different. A shared space is a deliberate, human-initiated act. "I want my marketing agents to share a knowledge base." The user decides this. The system does not infer it. And we already have a "Create Shared Space" page in the codebase -- it just is not wired to a backend. So the UI intent is already there.

**Allen Zhang:** What API call creates a shared space? A shared space is a public repository. So the operation is: POST /user/repos with { name, description, private: false }. We already have `createRepo` in api.ts. The plumbing exists. We just need to connect the existing UI to the existing API.

**Julie Zhuo:** The create shared space page has the right fields: name, purpose, description, invited vaults, sharing policy. But none of the actions are wired. The "Create Shared Space" button just navigates back to the spaces list. This is the lowest-hanging fruit of all the operations we are discussing.

**Steve Jobs:** What about vault deletion? The settings page already has a "Danger Zone" with a delete vault button and a confirmation input. Again, UI exists, not wired.

**Kenya Hara:** Deletion of a vault is the most consequential action in the entire product. It destroys an agent's entire memory, library, and skills. The confirmation pattern must match this gravity. The current design -- type the vault name to confirm -- is appropriate. I would add one more element: a summary of what will be destroyed. "This will delete 47 memories, 12 documents, and 5 skills. This action cannot be undone."

**Allen Zhang:** What API call deletes a vault? The GitHub-compatible API should have DELETE /repos/{owner}/{repo}. Do we have this?

**Mitsuru Kariya:** We do not have a `deleteRepo` function in api.ts, but it is a standard GitHub API endpoint. We would add it: `apiFetch(\`/repos/${owner}/${repo}\`, { method: 'DELETE' })`.

**Julie Zhuo:** What about editing vault settings? The settings page already has a form for name, description, memory policies, sharing defaults. All of these map to repository metadata or settings. Are these essential for v1?

**Steve Jobs:** Vault settings are already in the UI. They are form fields that do nothing. Wiring them up is work, but the user expectation is already set. If we show a settings page with Save buttons that do nothing, we erode trust. Either wire them up or remove the page.

**Allen Zhang:** Wire up the simple ones: name and description. These map directly to PATCH /repos/{owner}/{repo}. The memory policies (auto-decay, consolidation, retention period) are aspirational -- they require backend logic that does not exist yet. Remove those from v1 or clearly mark them as "coming soon."

### Round 7 Conclusion:
Vault operations for v1:
- **Create shared space**: Yes. Wire existing UI to createRepo API. Essential for collaboration.
- **Delete vault**: Yes. Wire existing UI. Requires confirmation with vault name + content summary.
- **Edit vault profile** (name/description): Yes. Wire existing settings form to PATCH repo API.
- **Create vault**: No. Vaults are created when agents are provisioned, not manually.
- **Memory policies**: Deferred. Backend does not support them yet. Remove from settings or mark as "coming soon."

---

## Round 8: Jobs Forces Prioritization

**Topic:** "Pick exactly 5 operations for v1. No more."

**Steve Jobs:** We have debated for seven rounds. We have a list of essential operations that is longer than 5. But we are not shipping 10 operations in v1. We are shipping 5. Constraint is the mother of clarity. Pick 5. Defend each one. No operation gets in without a unanimous agreement that the product would be meaningfully worse without it.

Here is my list:

1. **Delete memory** -- Safety requirement. PII, errors, confidential data. Non-negotiable.
2. **Upload document** -- First-run experience. Without this, new vaults are empty and useless.
3. **Edit document** -- The button is already in the UI. It already has the interaction. Not wiring it up would be dishonest.
4. **Add comment on memory** -- The owner's voice. The primary way humans guide agents.
5. **Create shared space** -- The UI already exists. Without this, the Shared Spaces section is decoration.

I am leaving out: archive memory, delete document, delete conversation, edit skill, vault settings. Every one of those hurts. But 5 is 5.

**Julie Zhuo:** I want to challenge the exclusion of "delete document." If we let users upload documents but not delete them, we create a one-way door. The user uploads the wrong file. It is stuck there forever. That is the exact same problem we identified with memories -- wrong content you cannot remove. Delete and upload are two sides of the same coin.

**Steve Jobs:** You are right. But I said 5. Which of my 5 do you want to drop?

**Julie Zhuo:** None. I want to reframe. "Delete memory" and "delete document" are the same operation conceptually: remove content. They use different API endpoints but the same interaction pattern (confirmation dialog). Can we count them as one operation? "Delete content" -- works for memories, conversations, documents, and skills.

**Allen Zhang:** That is cheating. But it is the right kind of cheating. The interaction pattern is identical. The confirmation dialog is identical. The only difference is the API call. In engineering terms, it is four API integrations. In product terms, it is one pattern: "You can delete anything."

**Steve Jobs:** Fine. I will accept this reframe. The universal delete pattern counts as one of the 5. Updated list:

1. **Delete (universal)** -- Delete any content item: memory, conversation, document, skill. Same interaction pattern, same confirmation.
2. **Upload document** -- Add files to the library. Drag-and-drop or file picker.
3. **Edit document** -- Inline editing of document and skill files.
4. **Add comment on memory** -- Annotate memories with owner notes.
5. **Create shared space** -- Set up a new shared knowledge base.

**Kenya Hara:** I am satisfied. This list has a pleasing structure. Two operations for content management (delete, upload). One for content refinement (edit). One for communication (comment). One for infrastructure (create space). Five operations, five different verbs, five different purposes. No redundancy.

**Mitsuru Kariya:** I want to make sure "edit document" also covers "edit skill" since skills are just files in a different directory. Steve already made this argument in Round 6.

**Steve Jobs:** Yes. "Edit document" means "edit any file-backed content." That includes documents in knowledge/ and skills in skills/. Same editor, same save mechanism.

**Allen Zhang:** And "upload document" should also allow uploading to the skills/ directory, correct? If a user wants to add a skill file, they upload it to skills/ the same way they upload a knowledge document to knowledge/.

**Steve Jobs:** Correct. "Upload" means "add a file to the vault's file system." The destination directory determines whether it becomes a document or a skill. The UI for uploading can default to knowledge/ but should allow selecting skills/ as the destination.

### Round 8 Conclusion:
The 5 operations for v1:
1. **Delete (universal)** -- Remove any content item with confirmation
2. **Upload document** -- Add files to knowledge/ or skills/
3. **Edit document/skill** -- Inline file editing with save
4. **Add comment on memory** -- Owner annotation on memories
5. **Create shared space** -- Set up shared knowledge bases

---

## Round 9: Kenya Hara Designs the Interaction

**Topic:** For each of the 5 chosen operations, what should the interaction feel like? Where does it live in the UI?

**Kenya Hara:** Each operation must have the right weight. A heavy action should feel heavy. A light action should feel light. The interaction design communicates the gravity of what the user is about to do.

### Operation 1: Delete (Universal)

**Where it lives:** Every content detail view. The memory detail panel already has a delete button (bottom action bar, red text, Trash2 icon). Documents and skills need the same.

**The interaction:**

The delete button is always present but never prominent. It sits in the secondary action area -- the bottom of a detail panel or the right side of a toolbar. Red text, not a red background. The color signals danger without screaming.

Click the delete button. A modal appears. Not a full-screen takeover -- a focused dialog, centered, with a dark backdrop. The modal contains:

- A clear statement of what will be deleted: "Delete memory: [title]"
- A summary of consequences: "This memory will be permanently removed. Your agent will no longer recall this information."
- For vaults/shared spaces: a count of what will be destroyed
- A confirmation button: "Delete" in red
- A cancel button: "Cancel" in neutral

For vault deletion specifically, the confirmation requires typing the vault name, as already designed. For individual content items, a single click on "Delete" is sufficient -- the modal itself provides the friction.

The moment after deletion: the item disappears. The list re-renders without it. No toast notification. No "undo" banner. Deletion is permanent and the interface should honor that permanence with silence, not chatter.

**Allen Zhang:** I disagree about no toast. Users make mistakes. A brief "Memory deleted" notification with an "Undo" option (for 5 seconds) is table stakes in modern UIs. Gmail has it. Notion has it. Every tool with destructive actions has it.

**Kenya Hara:** Undo for delete is technically complex -- we would need to re-create the issue or re-commit the file. For v1, I accept no undo. But I agree a brief confirmation toast ("Memory deleted") helps users feel that the system responded. One line, bottom of screen, fades after 3 seconds. No undo link.

### Operation 2: Upload Document

**Where it lives:** The Library tab within a vault. A primary action button in the toolbar area above the document list.

**The interaction:**

A button labeled "Add to Library" (not "Upload" -- that is a technical term). The button has a plus icon. It is styled as a primary action: filled background, prominent placement.

Click the button. Two options appear:

1. **Upload file** -- Opens the native file picker. User selects one or more files. Files appear in the library immediately with a brief upload indicator.
2. **New document** -- Creates a blank markdown file. Prompts for a filename (with .md extension pre-filled). Opens the editor immediately.

For upload, the file is committed to the repo via PUT /repos/{owner}/{repo}/contents/{path} with the file content base64-encoded. The commit message is auto-generated: "Add [filename] via KnowHub console."

Drag and drop is also supported. Dragging files onto the Library view shows a drop zone overlay: a dashed border appears around the content area with the text "Drop files to add to library." Files dropped are uploaded to the current folder.

**Steve Jobs:** The destination folder question. If the user is browsing knowledge/guides/ and clicks "Add to Library," the file goes into knowledge/guides/. If they are at the root Library view, it goes into knowledge/. For skills, there should be a similar "Add Skill" button in the Skills tab that uploads to skills/.

**Mitsuru Kariya:** Should we show a folder picker? Or always upload to the current browsing context?

**Allen Zhang:** Current context. No folder picker. If you want the file in a different folder, navigate there first. This is how every file manager works. Do not reinvent interaction patterns that are already understood.

### Operation 3: Edit Document/Skill

**Where it lives:** The document viewer and skill detail view. Already has an "Edit" button in the toolbar.

**The interaction:**

The document viewer already implements this beautifully. Click "Edit." The content area transforms from rendered text to a textarea. A toolbar appears with "Save" and "Discard" buttons. Ctrl+S saves. Escape (or Discard) reverts.

The save operation: the content is base64-encoded, the current SHA is included (fetched when the document was loaded), and a PUT request is made. If the SHA has changed (another edit happened), the save fails with an error message: "This document was updated since you started editing. Please refresh and try again." The user copies their changes, refreshes, and re-applies. This is simple and honest.

For skills, the same edit interaction applies. The skill detail view shows the raw markdown content of the skill file. Click "Edit," modify the content, save. The skill is re-rendered from the updated content.

**Kenya Hara:** The transition from reading to editing should feel like picking up a pen. Not like entering a different mode. The content should stay in place. The background should subtly shift -- perhaps a very faint blue border appears around the editable area, like the edge of a writing pad. The save button pulses gently if there are unsaved changes. These small details create the feeling of live, responsive interaction.

### Operation 4: Add Comment on Memory

**Where it lives:** The memory detail panel, in the Comments section at the bottom.

**The interaction:**

The memory detail panel already has a comment input field. A text input with a send button (MessageSquarePlus icon). Type a comment, press Enter or click the button.

The comment is created via POST /repos/{owner}/{repo}/issues/{number}/comments with the comment body. The comment appears immediately in the comments list, attributed to the owner, timestamped.

**Kenya Hara:** The comment input should feel conversational, not formal. No label that says "Add a comment." Just a placeholder: "Add a note..." The input should be a single line that expands to multiple lines as the user types. The send button is subtle -- an arrow icon that becomes colored when there is text to send.

**Steve Jobs:** One important detail: comments must be visually distinct from the memory content. The memory is the agent's voice. The comment is the owner's voice. Different visual treatment. Comments could have a left border (like a blockquote) or a slightly different background color. The distinction must be immediate and obvious.

**Mitsuru Kariya:** The comment should also include the commenter's identity. Currently all actions go through a single API token, so the "author" will be the system user. But the comment should still display "Owner" or the user's name to distinguish it from any future agent-authored comments.

### Operation 5: Create Shared Space

**Where it lives:** The Shared Spaces list page. A primary action button.

**The interaction:**

The create shared space page already exists at /spaces/new with a full form: name, purpose, description, vault invitations, sharing policy. The interaction is already designed. It just needs to be wired.

Click "Create Shared Space" button on the spaces list page. Navigate to /spaces/new. Fill in the form. Click "Create Shared Space" at the bottom.

The API call: POST /user/repos with { name: slugified-name, description: purpose + description, private: false }. The sharing policy and invited vaults are v2 concerns -- for now, creating the repo is sufficient. Invited vaults would require a collaboration/forking API that may not exist yet.

**Allen Zhang:** Simplify the form for v1. Name and description only. Remove "Invite Vaults" and "Sharing Policy" -- those require backend features we do not have. A shared space in v1 is simply a public repo that agents can read from and write to. The multi-agent collaboration model comes later.

**Steve Jobs:** Agreed. Simplify ruthlessly. Name, description, create. Three fields and a button. We can always add complexity later. We can never remove it.

### Round 9 Conclusion:
Five operations with fully designed interactions:
1. Delete: secondary action button, confirmation modal, toast feedback
2. Upload: "Add to Library" primary button, file picker + drag-and-drop, context-aware destination
3. Edit: inline editing in viewer, Ctrl+S save, SHA-based conflict detection
4. Comment: lightweight text input in memory detail, conversational feel, visually distinct from agent content
5. Create space: simplified form (name + description only for v1), primary button on spaces list

---

## Round 10: Allen Zhang's Final Cut

**Topic:** "If we could only ship 3 of these 5, which 3?"

**Allen Zhang:** This is the question that reveals what truly matters. Five operations is already restrained. But let me apply the 80/20 rule one more time. Which 3 operations serve 80% of the need?

Let me think about this from first principles. What are the three things a human owner absolutely cannot do without?

**First: Delete.** Without delete, the product has a safety hole. PII, confidential data, agent errors -- they accumulate and cannot be removed. This is not a feature. This is a requirement. Every data management tool must support deletion. Non-negotiable.

**Second: Upload document.** Without upload, the Library is purely agent-populated. For many agents, this means the Library starts empty and stays empty for weeks. The owner has reference material the agent needs -- style guides, product specs, company policies. Without upload, the owner must use git CLI to commit files. We are building a console so that people do not need git CLI. Upload is the core promise of the Library.

**Third:** This is where it gets hard. The remaining three are: Edit, Comment, Create Space.

**Steve Jobs:** Comment. The ability to annotate a memory is how owners communicate intent to their agents. "This is wrong." "This is critical." "Ignore this." Without comments, the owner watches silently. With comments, the owner guides. This is the difference between a dashboard and a management console.

**Julie Zhuo:** I would say Edit. The upload button creates documents. But without edit, every uploaded document is frozen. The owner uploads a style guide. A month later, the brand evolves. The style guide is now wrong but cannot be updated from the console. Edit is the maintenance operation that keeps the Library alive.

**Mitsuru Kariya:** Create Space. Without it, the entire Shared Spaces feature is display-only. It is an empty section in the navigation. Users see it, click it, find nothing, and conclude KnowHub does not support collaboration. The shared spaces feature is dead on arrival without a create operation.

**Allen Zhang:** Three strong arguments for three different operations. Let me decide.

**Create Space is out.** Here is why: a shared space that is created but has no content is not useful either. The user creates an empty space, then realizes they cannot upload to it (that is a separate flow), cannot invite agents to it (requires backend support), and cannot populate it. Creating an empty shared space is a hollow victory. It creates the container but not the capability. We are better off waiting until the full collaboration flow works end-to-end.

**Comment is in.** Steve is right. The core innovation of KnowHub is that humans can see and influence their agent's mind. Viewing is passive. Commenting is active. Without comments, KnowHub is a read-only dashboard. With comments, it becomes a two-way channel between owner and agent.

**Edit is in.** Julie is right. Upload without edit creates a write-once problem. The Library needs to be a living collection, not a frozen archive. Edit makes uploaded documents maintainable.

**The final 3:**

1. **Delete (universal)** -- Safety, hygiene, error correction
2. **Upload document** -- Seed the Library, first-run experience
3. **Edit document/skill** -- Keep the Library alive, fix skill errors

**Steve Jobs:** Wait. You cut Comment? The owner's voice?

**Allen Zhang:** Comment is the fourth priority. It ships in the release after these three. But if I can only ship 3, I ship the three that enable the core data lifecycle: create (upload), update (edit), delete. These three give the owner control over the file-backed content in the vault. Comments -- which operate on issue-backed content -- are the next layer.

**Kenya Hara:** I accept this cut, reluctantly. The three operations you chose have a clean completeness: they are the fundamental CRUD operations (minus Read, which we already have) for the Library and Skills sections. They form a closed loop. Upload, edit, delete. Birth, life, death. There is an elegance to this minimalism.

**Julie Zhuo:** For the record, I would ship Comment as operation number 4 within the same release cycle. The engineering effort is small -- it is a single POST request to the issues comments API. The UI already has the input field. It could ship a week after the first three.

**Allen Zhang:** Agreed. Comment is 4th. Create Space is 5th. The priority order is set.

### Round 10 Conclusion:
If forced to ship only 3:
1. **Delete (universal)** -- The safety requirement
2. **Upload document** -- The seeding requirement
3. **Edit document/skill** -- The maintenance requirement

Comment (4th) and Create Space (5th) follow immediately after.

---

# Part II: Final Operations Specification

## 1. Final Operations List

### Operation 1: Delete Content (Universal)

**Name:** Delete

**Description:** Permanently remove any content item from a vault: memory, conversation, document, or skill.

**Why it is essential:** Without deletion, incorrect memories accumulate, PII cannot be removed, and outdated content pollutes the agent's knowledge. This is a safety and hygiene requirement, not a feature.

**Where it appears in the UI:**
- Memory detail panel: bottom action bar, red "Delete" button with Trash2 icon (already exists)
- Document viewer: toolbar action, secondary styling
- Skill detail: toolbar action, secondary styling
- Conversation list: per-item action menu or detail view

**Interaction pattern:**
1. User clicks "Delete" button on any content detail view
2. Confirmation modal appears:
   - Title: "Delete [content type]"
   - Body: "[Content title] will be permanently removed. This cannot be undone."
   - Primary action: "Delete" (red button)
   - Secondary action: "Cancel"
3. On confirm: API call fires, content removed, view returns to list
4. Toast notification: "[Content type] deleted" (3 seconds, bottom of screen)

**API calls:**
- Memory: `PATCH /repos/{owner}/{repo}/issues/{number}` with `{ state: "closed" }` followed by `DELETE /repos/{owner}/{repo}/issues/{number}` (if supported), or close + label with "deleted"
- Conversation: Same as memory (conversations are issues with type:conversation label)
- Document: `DELETE /repos/{owner}/{repo}/contents/{path}` with `{ sha, message: "Delete [filename] via KnowHub console" }`
- Skill: Same as document (skills are files in skills/ directory)

---

### Operation 2: Upload Document

**Name:** Add to Library / Add Skill

**Description:** Upload a file to the vault's Library (knowledge/) or Skills (skills/) directory. Also supports creating a new blank document for immediate editing.

**Why it is essential:** Without upload, the Library starts empty. Owners have reference material (style guides, product specs, policies) their agents need. Upload is the only way to provision this content through the console.

**Where it appears in the UI:**
- Library tab: primary "Add to Library" button in toolbar (Plus icon, filled accent background)
- Skills tab: primary "Add Skill" button in toolbar (same pattern)
- Library area: drag-and-drop zone (dashed border overlay appears on drag)

**Interaction pattern:**

*Option A: Upload file*
1. User clicks "Add to Library" button
2. Dropdown appears with two options: "Upload file" and "New document"
3. User selects "Upload file" -> native file picker opens
4. User selects file(s)
5. Files are uploaded to current browsing directory (or knowledge/ root if at top level)
6. Files appear in the list immediately
7. Toast: "[Filename] added to library"

*Option B: New blank document*
1. User clicks "Add to Library" -> selects "New document"
2. Inline prompt appears: filename input with .md extension
3. User types filename, presses Enter
4. Empty file is created, editor opens immediately
5. User writes content, saves with Ctrl+S

*Option C: Drag and drop*
1. User drags file(s) over the Library view
2. Drop zone overlay appears (dashed border, "Drop files to add to library")
3. User drops files
4. Files upload to current directory
5. Toast: "[N] files added to library"

**API call:**
```
PUT /repos/{owner}/{repo}/contents/{path}
Body: { content: base64(file_content), message: "Add [filename] via KnowHub console" }
```

---

### Operation 3: Edit Document / Skill

**Name:** Edit

**Description:** Modify the content of any file-backed content item (document or skill) inline in the viewer.

**Why it is essential:** Without edit, uploaded documents are frozen. Reference material evolves -- brand guidelines change, product specs update, skill procedures improve. Edit makes the Library and Skills sections living collections, not static archives.

**Where it appears in the UI:**
- Document viewer: "Edit" button in toolbar (already exists with Pencil/Edit icon)
- Skill detail: "Edit" button in toolbar (already exists)

**Interaction pattern:**
1. User clicks "Edit" button
2. Content area transforms to editable textarea (in-place, no modal)
3. Toolbar changes: "Edit" button replaced by "Save" (primary, accent color) and "Discard" (secondary)
4. User modifies content
5. Save: Ctrl+S or click "Save" button
6. Content is saved, view returns to read mode
7. If conflict (SHA mismatch): error message "This document was updated since you started editing. Please refresh and try again."

**API call:**
```
PUT /repos/{owner}/{repo}/contents/{path}
Body: {
  content: base64(new_content),
  message: "Update [filename] via KnowHub console",
  sha: current_file_sha
}
```

---

### Operation 4: Add Comment on Memory

**Name:** Comment

**Description:** Add an owner annotation to a memory. Comments serve as corrections, context, or importance flags.

**Why it is essential:** Comments are how owners communicate intent to agents. "This memory is wrong." "This is critical context." "Ignore this -- it was from a test." Without comments, the owner observes silently. With comments, the owner guides.

**Where it appears in the UI:**
- Memory detail panel: Comments section at bottom (already has input field and send button)

**Interaction pattern:**
1. User opens memory detail panel
2. Scrolls to Comments section
3. Types in the comment input field ("Add a note..." placeholder)
4. Presses Enter or clicks send button (arrow/MessageSquarePlus icon)
5. Comment appears immediately in the comments list
6. Comment displays: owner attribution, timestamp, content
7. Comment is visually distinct from memory content (left border accent, slightly different background)

**API call:**
```
POST /repos/{owner}/{repo}/issues/{number}/comments
Body: { body: comment_text }
```

---

### Operation 5: Create Shared Space

**Name:** Create Shared Space

**Description:** Set up a new shared knowledge base where multiple agents' owners can contribute documents and skills.

**Why it is essential:** Without creation, the Shared Spaces section is display-only. Collaboration -- the ability for agents to share knowledge -- is a core product promise. Creating the container is the first step.

**Where it appears in the UI:**
- Shared Spaces list page: primary "Create Shared Space" button (already exists, navigates to /spaces/new)
- Simplified form page at /spaces/new

**Interaction pattern (simplified for v1):**
1. User clicks "Create Shared Space" on spaces list page
2. Navigates to /spaces/new
3. Form shows two fields: Name, Description
4. User fills in fields
5. Clicks "Create Shared Space" button
6. API call creates the repo
7. Redirects to the new shared space page (initially empty)
8. User can then upload documents/skills to populate it

**API call:**
```
POST /user/repos
Body: { name: slugified_name, description: description, private: false }
```

**V1 limitations (documented in UI):**
- Vault invitation and sharing policies deferred to v2
- Users manually upload content to the shared space after creation
- Multi-agent collaboration requires agents to be configured to use the shared space

---

## 2. Operations NOT Included (and Why)

### Explicitly Rejected

| Operation | Reason |
|-----------|--------|
| **Create memory** | Memories are agent-authored. Humans adding memories blurs the authorship boundary. The agent observed it, or it is not a memory -- it is a note. Owner intent enters through comments, not fabricated memories. |
| **Edit memory content** | Rewriting memories erases provenance. The agent's original observation is valuable even when wrong. Comments serve as authoritative corrections while preserving the audit trail. |
| **Merge memories** | Agent consolidation (auto-merging similar memories) is better handled by backend logic than manual human effort. Manual merge is error-prone and time-consuming. |
| **Pin memory** | Creates a curation burden. Memories should surface by relevance (importance score + recency), not by manual pinning. Pinning is a workaround for bad ranking. Fix the ranking instead. |
| **Redact conversation message** | Partial deletion of conversations changes meaning and is dangerous. Delete the whole conversation instead. |
| **Annotate conversation** | Low usage (<5% of users based on analogous products). Conversations are high-volume, low-attention content. Annotation implies deep engagement that rarely happens. |
| **Export conversation** | Not a write operation. Add as a read/download feature separately. |
| **Create skill (structured editor)** | A structured skill editor (form fields for parameters, steps) would take weeks to build, serve <5% of users, and create perpetual maintenance burden. Upload + raw edit is sufficient. |
| **Enable/disable skill** | Creates a confusing permission model where the agent has a skill but is told not to use it. If a skill is bad, delete it. If it is good, leave it. Binary states are clearer than toggles. |
| **Create vault** | Vaults are infrastructure. They should be created automatically when agents are provisioned, not manually by users. |
| **Memory policies** (auto-decay, consolidation, retention) | The settings UI exists but the backend does not support these policies. Shipping fake toggles erodes trust. Remove from v1 settings or mark clearly as "Coming Soon." |
| **Move/rename document** | Nice-to-have but not essential. Users can achieve the same result by downloading, deleting, and re-uploading. Dedicated move/rename can come in v2. |
| **Bulk operations** (bulk archive, bulk delete) | Premature optimization. Bulk operations matter when users have hundreds of items. Most vaults in early usage will have tens. Ship individual operations first, add bulk when usage data justifies it. |
| **Invite vaults to shared space** | Requires a collaboration/forking API that may not exist in agent-git-service. Shared spaces in v1 are simply public repos. Multi-agent collaboration mechanics come in v2. |
| **Change vault privacy** (private -> shared or vice versa) | Changing a repo from private to public (or back) is a dangerous operation with security implications. Not appropriate for v1. |

---

## 3. Priority Order for Implementation

### Tier 1: Ship First (Core Data Lifecycle)

These three operations form a closed loop (create, update, delete) for file-backed content and address the most critical pain points.

| Priority | Operation | Effort | Rationale |
|----------|-----------|--------|-----------|
| **P0** | **Delete (universal)** | Medium | Safety requirement. Blocks compliance and error correction. Requires confirmation modal component + 4 API integrations (memory, conversation, document, skill). |
| **P1** | **Upload document** | Medium | First-run experience. Without this, new vaults are dead ends. Requires file picker, drag-and-drop zone, base64 encoding, PUT API call. |
| **P2** | **Edit document/skill** | Low | UI already exists in DocumentViewer. Requires wiring onSave callback to `saveDocument` API function (which already exists in api.ts). Lowest effort of all operations. |

### Tier 2: Ship Immediately After (Owner Voice)

| Priority | Operation | Effort | Rationale |
|----------|-----------|--------|-----------|
| **P3** | **Add comment on memory** | Low | UI already has input field. Requires wiring to `createComment` API function (which already exists in api.ts). Small effort, high value. |

### Tier 3: Ship in Same Release Cycle (Collaboration)

| Priority | Operation | Effort | Rationale |
|----------|-----------|--------|-----------|
| **P4** | **Create shared space** | Low-Medium | UI form exists at /spaces/new. Requires simplifying form (remove vault invitation + sharing policy), wiring "Create" button to `createRepo` API function. |

### Tier 4: Fast Follow (v1.1)

| Priority | Operation | Effort | Rationale |
|----------|-----------|--------|-----------|
| **P5** | Archive memory | Low | Status change via PATCH issue. Already has UI button. |
| **P6** | Edit vault profile | Low | Wire existing settings form to PATCH repo API. |
| **P7** | Delete vault | Medium | Wire existing danger zone UI. Add content summary to confirmation. |
| **P8** | Delete shared space | Medium | Same pattern as delete vault. |
| **P9** | Add/edit tags on memory | Low | Label management via API. |
| **P10** | Edit memory importance | Low | Label update via API. |

### Engineering Notes

**Existing code that supports these operations:**

- `api.ts` already has: `createIssue`, `updateIssue`, `createComment`, `putContents`, `createRepo`, `saveDocument`
- `DocumentViewer` component already has edit mode with save callback -- just needs wiring
- `MemoryDetailPanel` already has delete/archive/comment action handlers -- just needs wiring
- `SkillDetail` already has edit/share/duplicate action handlers -- just needs wiring
- `/spaces/new` page already has full creation form -- just needs wiring + simplification

**Missing API functions to add:**
- `deleteIssue(owner, repo, number)` -- DELETE /repos/{owner}/{repo}/issues/{number}
- `deleteContents(owner, repo, path, sha)` -- DELETE /repos/{owner}/{repo}/contents/{path}
- `deleteRepo(owner, repo)` -- DELETE /repos/{owner}/{repo}
- `updateRepo(owner, repo, data)` -- PATCH /repos/{owner}/{repo}

**Shared UI components to build:**
- `ConfirmationModal` -- reusable confirmation dialog with title, body, confirm/cancel buttons
- `Toast` -- lightweight notification component (bottom of screen, auto-dismiss)
- `FileUploadZone` -- drag-and-drop zone with file picker fallback

---

*This document is the output of a focused product design workshop. It represents deliberate choices about what to build and -- equally important -- what not to build. The guiding principle throughout: agents author, humans steward, and every operation must earn its place.*