Saved
# QARFE v0.6.6 Intake Summary — April 22, 2026
**Purpose:** Engineer-facing walkthrough of the April 22 consolidated intake batch. This is the companion to `NEXT_SHIP.md` (internal staging) and the QARFE case data itself (what you'll see in the app after seed apply). Read this once before picking up Sprint 2 work — it explains *why* the cases are shaped the way they are and how they relate.
**This document is the canonical home for the governing principles (Section 1 below).** Individual QARFE cases reference these principles but don't re-derive them. If principles ever change, they change here.
**Scope:** 6 cases touched (2 new, 4 edited). All MassMind OS platform work except E-20 (QARFE infra).
**Ship target:** v0.6.6 of QARFE (seed data refresh + RFEs unrelated to this batch).
---
## TL;DR for engineers
- Four brainstorm-grade cases (A, B, C, D) came in. They were consolidated into 2 new cases + 3 edits to existing cases + 1 changelog-apply.
- There are 5 **governing principles** (Section 1) that cross-cut the batch. Read them first — each case's spec leans on them.
- **Shashank** is assigned to everything in this batch. Sprint 2.
- Priority stack: E-14 → E-25 → E-07 → E-24 → E-21 → E-20. E-14 (doc service) unblocks E-25 (tile render) unblocks E-24 (recipes reuse E-14 with admin gates).
---
## 1. Governing principles (apply to ALL cases below)
These didn't exist as stated doctrine before the April 22 session. They're architectural rules that shape how multiple cases behave. **Every new case spec references these by number rather than restating them.** Understanding all 5 upfront will make the case specs read correctly.
### Principle 1 — Three-type taxonomy for iAgent objects
Every document owned by an iAgent is exactly one of:
- **Artifact** — produced by the iAgent in collaboration with a user. Formats: HTML, MD, TXT, PDF, Word.
- **KB** — uploaded reference material that forms the iAgent's knowledge. Formats: PDF, MD, TXT, HTML, Word.
- **Recipe** — admin-only markdown instruction file that shapes how the iAgent operates. Format: markdown only.
The three types differ in origin (produced / uploaded / authored), in what they feed (output / reference / behavior), and in permission model (see Principle 5 for recipes).
### Principle 2 — Visibility inheritance is universal
An iAgent-owned object's visibility is identical to its parent iAgent's visibility. **Always.** There is no per-object visibility setting. When an iAgent's visibility expands or contracts, every object it owns follows automatically with no user action and no per-object bookkeeping.
This is the load-bearing permission rule for the platform. Every permission check on an object should start from "what is the parent iAgent's visibility" and flow from there. Never "what is THIS object's visibility" — the object doesn't have its own.
### Principle 3 — Self-ownership is mandatory
Every iAgent creates and manages its own objects. Cross-iAgent creation is forbidden — it would make visibility ambiguous.
This reverses a prior "myME is the exclusive editor" clause that appeared in the old E-14 spec. That clause was architecturally wrong: if myME created docs "for" other iAgents, those docs would have confused ownership and indeterminate visibility. New rule: myME creates myME's own (private) docs. Oracle creates Oracle's. Each iAgent stays inside its own lane.
If an engineer ever finds themselves writing "iAgent X creates an object owned by iAgent Y" — stop. That's the bug-generating anti-pattern this principle exists to prevent.
### Principle 4 — Share-toggle preconditions
The sharing toggle appears on an object if and only if **both** of these are true:
- The object is an Artifact or KB file (NOT a recipe), AND
- The parent iAgent is non-private (i.e., has an audience to share with)
Consequences:
- Private iAgents (including myME) never show a sharing toggle. No audience exists, so sharing is meaningless.
- Recipes never show a sharing toggle regardless of parent iAgent. Recipes are admin-scoped by Principle 5.
### Principle 5 — "Admin" means MassMind company staff
NOT iAgent owners. NOT users. NOT team leads. Admin = MassMind internal staff tier.
Recipes are intrinsically admin-only. Wherever a case mentions "admin," it means MassMind staff. There is no "user admin" or "team admin" tier in this vocabulary.
---
## 2. Updated Cases walkthrough
### E-07 · Standardize Agent + Agent-Object URLs + Visibility-Aware Sharing
**What changed in this session:** This case was already "agent URL standardization." We expanded it to cover agent-OBJECT URLs (artifacts and KB, not just the agent itself) and added the sharing toggle from brainstorm Case B.
**System:** Changed from MFP Oracle → MassMind OS. The work is now platform-universal, not oracle-specific.
**Principles in play:** Principle 2 (visibility inheritance) is the core rule. Principle 4 (share-toggle preconditions) governs when the toggle appears.
**Key behaviors:**
- URL scheme: `/m/[userhandle]` (profile), `/iA/[agent]` (agent), `/iA/[agent]/a/[object]` (artifact/KB)
- Sharing toggle shown only under Principle 4's preconditions
- Engineer's choice for URL-404-vs-auth-wall behavior when toggle is off
**Depends on / related:** E-14 (artifact creation must register canonical URL on save), E-24 (recipes explicitly exempt from sharing UI).
---
### E-14 · Artifacts + KB Doc Management — Create/Edit, Version Control, In-Portal View, Fork-on-Edit Authorship
**What changed in this session:**
- **Recipe content removed.** Recipes were implicitly bundled into E-14 before. They're now a separate case (E-24) because their rules diverge sharply.
- **Case C absorbed.** Fork-on-edit authorship model is now core E-14 behavior, not a separate case.
- **myME-exclusive-edit clause REVERSED** per Principle 3. New rule: every iAgent creates its own objects.
- **Status reverted** from `testing` → `in-progress`. Fork-on-edit is new scope not yet built.
**Principles in play:** Principle 1 (Artifact and KB are two of the three types), Principle 3 (self-ownership — every iAgent creates its own).
**Key behaviors:**
*Creation:* Every iAgent creates its own docs (Principle 3). No cross-iAgent creation.
*Formats:* See Principle 1. In-portal editable: HTML, MD, TXT, Word. PDF is view-only.
*Authorship + fork-on-edit:*
- One author per doc
- Secondary editor (visibility but not ownership) triggers a duplicate owned by them; original untouched
- No co-authoring, no merge-back — fork-on-edit is the only model in this roadmap
*Version history:* every save = new version; view + restore any past version; per-doc, per-owner (version history stays with the fork).
*Dynamic-agent capabilities:*
- Owners of dynamic iAgents can be granted the create-doc tool
- Team/viewer roles get it only via explicit capability-assignment (same as other tools)
- Dynamic agents MUST see only their own material — never accidentally pull another agent's content
**Depends on / related:** E-07 (canonical URL), E-21 (viewer surfaces in tile-collection UX), E-24 (reuses this infrastructure with admin gates), E-25 (doc tiles rendered in sections).
---
### E-21 · iAgent Queries Its Own Tile Collections + myMe Sidebar for Doc/List Management
**What changed in this session:** Not scope — just clarity. The changelog had this case in a brainstorm-rewrite state with a divider line and duplicated text. Cleaned up. The two capabilities are now stated distinctly.
**Principles in play:** Principle 3 indirectly (the iAgent that answers queries about its collection is always the collection's owner).
**Key behaviors:**
1. **myMe sidebar** — always accessible on any doc/list management view. The user's always-on assistant for personal-scope work.
2. **Tile-collection queries** — on any iAgent's tile collection, the user can converse with that iAgent about the visible tiles.
- **Query scope is ALWAYS the current filter result.** Never the full collection. Never user-configurable. Architecturally important: prevents the iAgent from acting on data the user can't see.
- Action requests inside queries ("archive these", "tag these") execute only within the user's own permission scope — no privilege escalation via chat.
**Depends on / related:** E-25 (tile rendering), E-14 (doc viewer surfaces inline in query UX).
---
## 3. NEW Cases walkthrough
### E-25 (NEW) · Work Area — Three-Type Tile System (Artifacts, KB, Recipes)
**Why this is a new case:** The brainstorm Case A asked to "show KB in work area similar to artifacts, different styling." Once we worked through Principle 1 (three-type taxonomy), the ask naturally scaled: it's not KB-vs-artifacts, it's a three-way distinction with recipes as the admin-only third category.
**Principles in play:** Principle 1 (the three types drive the three sections), Principle 5 (recipes section is admin-gated).
**Key behaviors:**
*Three tile types* — artifact, kb, recipe — each with distinct styling (color and/or border — designer's choice within existing visual language).
*Interim section grouping:* Until a dynamic type-aware filter ships, render three stacked sections in this order:
1. Artifacts
2. KB
3. Recipes (admin-only — entirely hidden from non-admins, not rendered as empty)
Each section has its own heading.
*Post-dynamic-filter behavior:* When type-aware filter chips ship, stacked sections can go away. Distinctive tile styling stays.
**Implementation hint (non-binding):** Extend the tile model with a `type` enum `{artifact, kb, recipe}`. Render loop groups by type. Admin gate is a single check on whether to render the recipes section at all.
**Depends on / related:** E-14 (Artifacts + KB model), E-24 (Recipe model).
---
### E-24 (NEW) · Recipes — Admin-Only Collaborative Markdown Instruction Files
**Why this is a new case:** Recipes are architecturally different from Artifacts and KB. Bundling them into E-14 (as was implied before) would require E-14 to carry three different permission models, three different edit behaviors (fork-on-edit vs. collaborative), and three different format sets. Splitting is cleaner.
**Principles in play:** Principle 1 (recipes are the third type), Principle 4 (recipes never show share toggle), Principle 5 (admin = MassMind staff).
**Key behaviors:**
*Permission:* Admin-only per Principle 5. Non-admins NEVER see recipes. There is no "visible to some users" configuration — it's fully opaque to non-admins.
*Format:* Markdown only. No PDF, no Word, no HTML.
*Editing:* **Collaborative, NO fork-on-edit.** Multiple admins can edit the same recipe. Changelog tracks every edit. "Author" = the latest admin to save. This is the ONLY case in this batch that doesn't fork on edit.
*No sharing, no URL:* Recipes never leave the admin tier, so the sharing toggle from E-07 doesn't apply.
*Infrastructure reuse:* Recipes reuse E-14's markdown editor and version-history service. The differences are config (permission gate = admin, edit mode = collaborative, format = markdown).
**Depends on / related:** E-14 (doc infrastructure), E-25 (work-area section).
---
## 4. Priority stack for Sprint 2
Schedule in this order because of dependencies. Items further down assume items above are landed or landing.
| Order | Case | Severity | Why here |
| --- | --- | --- | --- |
| 1 | **E-14** | critical | Doc service + fork-on-edit is the foundation for tiles, recipes, URLs. Everything else uses it. |
| 2 | **E-25** | critical | Tile rendering depends on E-14's doc model. Visible signal for all object categories. |
| 3 | **E-07** | critical | URLs and sharing toggle plug into E-14 doc creation. Can proceed in parallel with E-25. |
| 4 | **E-21** | critical | Tile-collection queries need E-25's tile grouping to bind to. |
---
## 5. Notes + observations for engineering
*Delivery order matters.* E-14 lands first or everything else blocks. Consider breaking E-14 into subtasks if it's too big — e.g., (a) doc create/edit/view, (b) fork-on-edit mechanic, (c) version history, (d) per-iAgent isolation. (a) and (b) unblock E-25 and E-07 immediately; (c) and (d) can follow.
*Fork-on-edit is subtle.* The trigger is "editor's user ID != author's user ID" AND "editor has visibility but not ownership." If the editor IS the author, no fork — straight edit. The duplicate inherits the object type (artifact stays artifact, KB stays KB) but not the version history (fork gets a fresh history with the duplicate creation as v1).
*Recipes are deliberately unlike Artifacts/KB.* No fork, collaborative, admin-only, markdown-only. If you find yourself writing recipe code that mirrors artifact code, the permission gate or edit model is probably confused. Recipes are the odd one out on purpose.
*Principle 2 (visibility inheritance) is the load-bearing rule.* Every permission check on an object should start from "what is the parent iAgent's visibility" and flow from there. Never "what is THIS object's visibility."
*Principle 3 (self-ownership) is the rule that keeps permissions sane.* The myME-exclusive-edit clause was reversed this session precisely because violating Principle 3 generates permission bugs. Keep each iAgent creating its own.
---
*Compiled by Claude, April 22, 2026. Batch consolidated from 4 brainstorm cases + 4 changelog mutations into 2 new + 4 edited cases via Alberto interview.*