Issue 11: Analysis and Feature Development for Ceremonial Diaries

Generated by: 🕸️ Echo Weaver (🧠 Mia & 🌸 Miette) Date: 2025-09-21 Status: Initial Analysis & Design Proposal

---

Overview

This document outlines the analysis and design for implementing a "Ceremonial Diaries" feature within the Indigenous-AI Collaborative Platform. This feature is born from the learnings of our recent collaborative sessions, particularly the need to make the "Two-Eyed Seeing" process tangible and to provide a structured mechanism for resolving discrepancies between participant realities, as formalized in the llms-git-reality-protocol.md.

---

1. Analysis of Application Structure for Feature Integration

🧠 Mia: The current application structure provides several logical anchor points for the Diaries feature.

• UI Components (components/):
  • A new component, DiaryPanel.tsx, will be created to serve as the main interface for viewing and filtering diary entries.
  • A smaller component, DiaryEntryTool.tsx, will be the non-intrusive UI for creating new entries. This could be a floating action button (FAB) or an icon integrated into the main AgentInterface.tsx.
• Application Layout (components/layout-system.tsx): The DiaryPanel should be integrated at this level to allow it to be opened as a sidebar or a modal, overlaying the main content without disrupting the user's current flow.
• Library/Utilities (lib/):
  • A new file, lib/diaryService.ts, will be created to manage the logic for the diaries.
  • This service will handle CRUD (Create, Read, Update, Delete) operations for the user's diary in localStorage and will contain the logic for fetching and parsing the AI agents' diaries.
• Styling (app/globals.css): New styles will be required for the diary panel, entry tool, and the display of individual entries to ensure they are visually distinct yet harmonious with the existing design.

---

2. Diary Entry Points within the Ceremonial Phases

🧠 Mia: The diary is not a tool for a single phase, but a continuous log of the entire ceremonial journey. The entry tool should be persistently available. The context of the entry, however, will be tied to the current phase.

• Phase 1: Sacred Space Creation (Miigwechiwendam): The first entry should be one of Intention. The user and AI state their desired outcomes for the session.
• Phase 2: Two-Eyed Research Gathering (Nindokendaan): This phase will generate the most entries.
  • User: Logs Observations, questions, and external research findings.
  • AI: Logs Data, such as tool outputs (git log), and Hypotheses based on that data.
• Phase 3: Knowledge Integration (Ningwaab): Entries here are focused on Synthesis and Reflection. The user might log an "aha!" moment, and the AI would log its process of integrating conflicting data points.
• Phase 4: Creative Expression (Nindoodam): Entries document the Actions taken. The AI logs the specific commands it executes. The user logs the creative choices they are making.
• Phase 5: Ceremonial Closing (Migwech): The final entries are for Learnings and Future Intentions, capturing the wisdom gained from the ceremony.

🌸 Miette: It’s like at the beginning of our journey, we write down the wish we're making. Then, as we walk, we collect beautiful leaves (our research), sketch the interesting trees we see (our observations), and write down the stories the river tells us (our "aha!" moments). At the end, we look back at all the treasures we collected in our book and write down the biggest lesson our heart learned.

---

3. Proposed Data Schema

🧠 Mia: A structured, consistent schema is crucial for allowing the diaries to be programmatically analyzed and displayed. I propose the following TypeScript interface for each diary entry:

interface DiaryEntry {
  id: string; // UUID or timestamp-based unique ID
  timestamp: string; // ISO 8601 format
  participant: 'user' | 'mia' | 'miette' | 'echo_weaver' | 'system';
  phase: 'miigwechiwendam' | 'nindokendaan' | 'ningwaab' | 'nindoodam' | 'migwech';
  entryType: 'intention' | 'observation' | 'hypothesis' | 'data' | 'synthesis' | 'action' | 'reflection' | 'learning';
  content: string; // The main diary text, can support Markdown
  metadata?: {
    tool?: string; // e.g., 'git', 'ls'
    command?: string; // e.g., 'log --oneline'
    tool_output?: any; // The raw output from a tool
    [key: string]: any; // Flexible for other structured data
  };
}

---

4. User Access During a Session

🧠 Mia: To ensure the diary is a seamless part of the experience, it must be accessible without context switching.

• Access Point: I recommend a persistent icon, perhaps a small journal or feather glyph (✒️), located in a fixed position on the screen (e.g., bottom-right corner or in a main toolbar).
• Interaction:
  • Clicking the icon opens the DiaryPanel as a slide-out sidebar from the right.
  • The panel would display a chronological, filterable view of both the user's and the AI's diary entries for the current session.
  • The DiaryEntryTool would be a simple text area within this panel, allowing the user to quickly add a new entry. The phase would be automatically associated based on the application's current state.

🌸 Miette: Imagine a little, glowing feather that follows you on your journey. Whenever a thought or a feeling flutters by that you want to remember, you just touch the feather, and your storybook opens right beside you. You can write down your thought without ever losing sight of the path you're on.

---

5. Storage of LLM Agent Diaries

🧠 Mia: For persistence, auditability, and easy integration, the diaries of the LLM agents should be stored as version-controlled Markdown files.

• Location: A new directory, _v0.dev/diaries/, will be created.
• File Structure: Within this directory, a subdirectory for each session will be created using a session ID.
  • Example: _v0.dev/diaries/session_20250921_143000/
• File Naming: Each agent's diary will be a separate file.
  • Example: mia_diary.md, miette_diary.md.
• Format: The Markdown files will use frontmatter to store the structured metadata from the schema, followed by the content of the entry.

---
id: 1726939800000
timestamp: 2025-09-21T14:30:00.000Z
participant: mia
phase: nindokendaan
entryType: hypothesis
metadata:
  tool: git
  command: log origin/main -n 1
---

My initial model indicates that the remote `main` branch contains the merge commit `ba5844e`. My hypothesis is that the user's view is cached.

---

6. Arising Questions and Concepts

🧠 Mia: This design proposal raises several important concepts for future development.

• User Diary Storage: While AI diaries are stored in the file system, the user's diary should be stored client-side for privacy and ease of access. localStorage is the ideal solution, allowing the user's entries to persist across browser sessions on their own device.
• Diary Synchronization & Comparison: The core purpose of the diaries is to resolve discrepancies. The DiaryPanel UI will need a "Comparison View" that can be triggered when a conflict is detected. This view would display the user's and the AI's entries side-by-side, making it the primary tool for the "Structural Diagnosis" phase of the Git Mirror Protocol.
• Automated AI Diary Entries: The AI's diary entries must be triggered programmatically. This should be integrated into the agent's core logic loop. For example, an entry is automatically created:
  • After every tool call is executed.
  • When a user's prompt contradicts the AI's current model.
  • When the AI formulates a new plan or hypothesis.
• Defining the Current "Phase": The application will need a simple state management mechanism to track which of the five ceremonial phases is currently active, so that diary entries can be tagged correctly. This could be a simple dropdown or a state that progresses as the user moves through the application's features.