neotoma 0.3.0 → 0.3.2

package/.cursor/plans/all-storage-unstructured_provenance_df0b7a8f.plan.md

@@ -1,112 +0,0 @@
----
-name: All-storage-unstructured provenance
-overview: "Plan for an alternative architecture where all storage goes through the unstructured path: agents submit conversation turns (and optionally attachments) as unstructured blobs so Neotoma stores the artifact and runs interpretation internally, capturing full provenance (artifact plus logged interpretation protocol) instead of agent-side structuring."
-todos: []
-isProject: false
----
-
-# All-storage-unstructured for full provenance
-
-## Goal
-
-Enable a mode where **conversation-sourced** data is stored the same way as file-sourced data: the agent submits the **raw turn (and optional attachment refs)** as unstructured content; Neotoma stores it as an artifact, runs interpretation with a logged protocol, and produces observations. No agent-side structuring, so no lost provenance context.
-
-## Current vs proposed flow
-
-```mermaid
-flowchart LR
-  subgraph current [Current]
-    A1[Conversation turn] --> A2[Agent structures]
-    A2 --> A3[store_structured]
-    A3 --> A4[Source = entity payload]
-    A4 --> A5[No original turn artifact]
-  end
-  subgraph proposed [Proposed]
-    B1[Conversation turn] --> B2[Agent sends blob]
-    B2 --> B3[store unstructured]
-    B3 --> B4[Source = turn artifact]
-    B4 --> B5[Server interpretation]
-    B5 --> B6[Logged protocol]
-    B6 --> B7[Observations]
-  end
-```
-
-
-
-**Today:** Unstructured path already supports `file_content` + `mime_type` (and `file_path`). [extractTextFromBuffer](src/server.ts) (lines 93–135) returns UTF-8 for `text/*`, JSON, XML, and common extensions (`.txt`, `.csv`, `.json`, `.md`). So sending a turn as `text/plain` (base64) would be stored and interpreted with the **document** extraction prompt. Gaps: (1) document prompt is not tuned for conversation turns; (2) content-hash dedup would collapse two turns with identical text; (3) no standard envelope for turn + metadata + attachment refs.
-
-## Recommended design
-
-### 1. Conversation-turn envelope (contract)
-
-Define a single, explicit format for “conversation turn as unstructured source” so that:
-
-- Each turn is a **distinct artifact** (different bytes → different `content_hash` → no unwanted dedup).
-- Optional metadata (timestamp, conversation_id, attachment refs) is preserved and can be used by interpretation or UI.
-
-**Proposed envelope (JSON):**
-
-- `content` (string): The turn text (user message, or user + assistant, per product choice).
-- `timestamp` (string, optional): ISO 8601; helps ordering and uniqueness.
-- `conversation_id` (string, optional): Thread identifier.
-- `turn_id` (string, optional): Unique per turn; if omitted, client can use `idempotency_key` as the unique handle.
-- `attachment_source_ids` (string[], optional): Source IDs of attachments already stored via unstructured store; interpretation can use these for context if needed later.
-
-**Storage:** Agent sends this JSON as the unstructured payload:
-
-- `file_content`: base64(JSON.stringify(envelope))
-- `mime_type`: e.g. `application/x-neotoma-conversation-turn` (new) or `application/json` with a convention (e.g. `original_filename` or a query param indicating “conversation turn” so the server can choose the right interpretation path).
-
-**Uniqueness:** Including `turn_id` or `timestamp` (or both) in the envelope ensures the stored bytes differ per turn, so content-hash dedup does not merge two different turns that happen to have the same text.
-
-### 2. Interpretation path for conversation turns
-
-- **Text extraction:** For `application/x-neotoma-conversation-turn` (or the chosen mime type), treat the blob as UTF-8 JSON; parse the envelope and use `content` as the text passed to the LLM. No PDF/OCR path.
-- **Prompt:** Add a **conversation-turn variant** of the extraction prompt (e.g. in [docs/prompts/llm_extraction_system_prompt.md](docs/prompts/llm_extraction_system_prompt.md) or a new file). Instructions: extract entities and facts from this conversation turn; support multiple entity types (person, task, event, note, etc.) in one turn; do not invent data. Same output shape as today (entity_type + fields) so [runInterpretation](src/services/interpretation.ts) and the rest of the pipeline stay unchanged.
-- **Prompt selection:** In [src/server.ts](src/server.ts), after `extractTextFromBuffer`, branch on mime type (or on a flag derived from envelope): if conversation-turn, call the LLM with the conversation prompt; otherwise keep current document prompt. Reuse [extractWithLLM](src/services/llm_extraction.ts) with a prompt parameter or a small wrapper that loads the correct system prompt.
-
-### 3. Attachments
-
-- **MVP:** Agent stores each attachment via the existing unstructured path (`store` with `file_content`/`file_path` + `mime_type`). Agent then stores the turn with an envelope that includes `attachment_source_ids` (the returned source IDs). The turn source is one artifact; each attachment is its own source. Interpretation for the turn uses only the turn `content` today; attachment content can be passed to the LLM in a later phase (e.g. “context: these sources are attached” and fetch their extracted text or summaries).
-- **Optional later:** Interpretation service accepts optional “context sources” (e.g. attachment source_ids), fetches their stored content or prior extraction, and passes them to the LLM as context for the turn. No schema change required for MVP if we only interpret the turn text.
-
-### 4. MCP contract
-
-- **Use existing `store` (and `store_unstructured`).** No new action required for MVP. Agent passes:
-  - `file_content`: base64-encoded JSON envelope (or plain text if no metadata needed).
-  - `mime_type`: `application/x-neotoma-conversation-turn` (recommended) or `text/plain` (simpler; then uniqueness relies on idempotency_key + always including something unique in the text, e.g. a timestamp line).
-  - `idempotency_key`: e.g. `conversation-{conversation_id}-{turn_id}` for replay safety.
-  - `original_filename`: optional, e.g. `turn-2025-01-15T12-00-00Z.json`.
-- **Spec and instructions:** Document that for **maximum provenance**, agents may store conversation turns as unstructured (envelope format above) so the artifact is preserved and interpretation is server-side with a logged protocol. Keep `store_structured` for backward compatibility and for clients that prefer not to pay interpretation cost per turn.
-
-### 5. Dedup semantics
-
-- **Today:** [raw_storage](src/services/raw_storage.ts) deduplicates by `content_hash` (and optionally by `idempotency_key`). Same bytes → same source.
-- **Conversation turns:** Envelope must include a unique field (`turn_id` or `timestamp`) so that two different turns never produce the same bytes. No change to raw_storage logic; the contract (envelope format) guarantees distinct content per turn when the client follows it.
-
-### 6. Implementation tasks (concise)
-
-
-| Area             | Task                                                                                                                                                                                                                                                                         |
-| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Contract         | Define envelope schema and mime type in [docs/specs/MCP_SPEC.md](docs/specs/MCP_SPEC.md) (and optionally [docs/vocabulary/canonical_terms.md](docs/vocabulary/canonical_terms.md)).                                                                                          |
-| Server           | In [src/server.ts](src/server.ts): for the chosen mime type, parse JSON envelope, use `content` as text; branch to conversation-turn extraction.                                                                                                                             |
-| Prompt           | Add conversation-turn extraction prompt (new file or section in [docs/prompts/llm_extraction_system_prompt.md](docs/prompts/llm_extraction_system_prompt.md)); load it in [src/services/llm_extraction.ts](src/services/llm_extraction.ts) when source is conversation-turn. |
-| Extraction       | In [llm_extraction.ts](src/services/llm_extraction.ts): add a function or parameter to extract using the conversation prompt; same output shape (entity_type + fields) for [interpretation.ts](src/services/interpretation.ts).                                              |
-| Text extraction  | In [src/server.ts](src/server.ts) `extractTextFromBuffer`: for `application/x-neotoma-conversation-turn`, return the envelope’s `content` (or full JSON if interpretation needs metadata); no PDF/OCR.                                                                       |
-| MCP instructions | Update [docs/developer/mcp/instructions.md](docs/developer/mcp/instructions.md) and tool descriptions: for full provenance, agents can store turns as unstructured using the envelope; document the format and mime type.                                                    |
-| Tests            | Add tests: store conversation-turn envelope → source created, interpretation run with conversation prompt, observations created; idempotency_key replay returns same source; two turns with same text but different turn_id produce two sources.                             |
-
-
-### 7. Out of scope for this plan
-
-- Changing or removing `store_structured`; it remains the fast path for clients that accept less provenance.
-- Pushing attachment content into the same interpretation call (optional future work).
-- Schema or migration changes; existing sources, interpretations, and observations tables are reused.
-
-### 8. Validation
-
-- Store a conversation-turn envelope (with `turn_id`), run interpretation, then verify: one source, one interpretation run (with config logged), observations trace to that source.
-- Store a second turn with same `content` but different `turn_id`; verify two distinct sources and two interpretation runs.
-- Reinterpret the first source; verify new interpretation run and new observations, original artifact unchanged.
-

package/.cursor/plans/automated_error_debugging_cloud_agents.plan.md

@@ -1,526 +0,0 @@
-# Automated Error Debugging with Cursor Cloud Agents
-
-Set up Cursor Cloud Agents to automatically monitor and debug error reports, using Cursor's AI to fix bugs automatically.
-
-## Technology: Cursor Cloud Agents
-
-**This implementation uses:**
-
-- ✅ **Cursor Cloud Agents API** - Spawn background agents that process errors
-- ✅ **Cursor's AI** - Agents use Cursor's AI to analyze and fix bugs
-- ✅ **Remote execution** - Agents run in Cursor's cloud environment
-- ✅ **Full automation** - Complete AI-powered bug fixing
-
-**Does NOT use:**
-
-- ❌ Local file watcher
-- ❌ Claude Code
-- ❌ Direct AI API calls
-
-## How It Works
-
-1. **Error Reporter** creates error reports in `.cursor/error_reports/pending.json`
-2. **Cloud Agent Spawner** monitors pending.json (or is triggered by error creation)
-3. **Cloud Agent** is spawned via Cursor Cloud Agents API with instructions to process errors
-4. **Agent** reads pending.json, selects highest priority error, fixes it using Cursor's AI
-5. **Agent** updates error report, archives resolved errors, continues with next error
-6. **Agent** terminates when queue is empty or encounters errors requiring human review
-
-## Prerequisites
-
-### 1. Cursor Cloud Subscription
-
-- Requires Cursor Cloud subscription with Background Agents enabled
-- Check subscription status in Cursor Settings
-
-### 2. API Credentials
-
-Configure environment variables:
-
-```bash
-export CURSOR_CLOUD_API_URL="https://api.cursor.com/v1"
-export CURSOR_CLOUD_API_KEY="your_api_key_here"
-export REPO_URL="https://github.com/your-org/neotoma"  # or your repo URL
-```
-
-**Getting API Key:**
-
-- Check Cursor Settings → Cloud Agents → API Key
-- Or contact Cursor support for API access
-
-### 3. Repository Access
-
-- Repository must be accessible to Cloud Agents
-- Ensure repo is public or Cloud Agents have access permissions
-- Configure in Cursor Cloud Agents Settings if needed
-
-### 4. Remote Repository Requirement ⚠️
-
-**Critical limitation:**
-- Cloud Agents work with **committed and pushed code only**
-- They clone the remote repository (GitHub)
-- Uncommitted local changes are **not accessible**
-- Errors in local-only changes cannot be fixed by Cloud Agents
-
-**Workaround:**
-- Commit error-producing changes before using Cloud Agents
-- Or use local solution (Claude Code) for uncommitted changes
-
-## Implementation Plan
-
-### 1. Create Agent Spawner Script
-
-**File:** `scripts/spawn_error_debug_agent.js`This script:
-
-- Monitors `.cursor/error_reports/pending.json` for new errors
-- Spawns Cloud Agents when errors are detected
-- Manages agent lifecycle (spawn, monitor, cleanup)
-
-### 2. Agent Instructions
-
-**File:** `scripts/error_debug_agent_instructions.md` (or embedded in spawn script)Instructions for the Cloud Agent:
-
-- Read pending.json
-- Select highest priority error
-- Run `/debug_pending_errors --auto` workflow
-- Use `/fix_feature_bug` to fix bugs
-- Update error reports
-- Archive resolved errors
-- Continue until queue empty or human intervention needed
-
-### 3. Integration with Error Reporting
-
-- Modify `report_error` workflow to optionally trigger agent spawn
-- Or use file watcher to detect new errors and spawn agents
-- Or use git hooks to spawn agents on commits
-
-### 4. Configuration
-
-**Add to `foundation-config.yaml`:**
-
-```yaml
-development:
-  error_debugging:
-    enabled: true
-    cloud_agents:
-      enabled: true
-      api_url: "${CURSOR_CLOUD_API_URL}"
-      api_key: "${CURSOR_CLOUD_API_KEY}"
-      repo_url: "${REPO_URL}"
-      auto_spawn: true  # Auto-spawn agents when errors detected
-      max_concurrent_agents: 1  # One agent at a time for error queue
-      agent_instructions_file: "scripts/error_debug_agent_instructions.md"
-```
-
-
-
-## Cloud Agent Spawner Implementation
-
-### Option A: File Watcher + Cloud Agent Spawner
-
-```javascript
-// scripts/watch_and_spawn_agent.js
-const fs = require('fs');
-const path = require('path');
-
-const WATCH_FILE = '.cursor/error_reports/pending.json';
-const API_URL = process.env.CURSOR_CLOUD_API_URL;
-const API_KEY = process.env.CURSOR_CLOUD_API_KEY;
-const REPO_URL = process.env.REPO_URL;
-
-let agentSpawned = false;
-
-async function spawnErrorDebugAgent() {
-  if (agentSpawned) {
-    console.log('[SPAWNER] Agent already spawned, skipping...');
-    return;
-  }
-
-  try {
-    const response = await fetch(`${API_URL}/v0/agents`, {
-      method: 'POST',
-      headers: {
-        'Authorization': `Bearer ${API_KEY}`,
-        'Content-Type': 'application/json'
-      },
-      body: JSON.stringify({
-        instruction: `Process all pending errors in the error queue.
-        
-1. Read .cursor/error_reports/pending.json
-2. Sort errors by priority (critical → low, oldest first)
-3. For each error:
-    - Load error report details
-    - Run /debug_pending_errors workflow
-    - Use /fix_feature_bug to fix the bug
-    - Update error report resolution status
-    - Archive resolved errors
-    - Remove from pending queue
-4. Continue until queue is empty
-5. If human intervention needed (unclear design), log error and stop
-
-Repository: ${REPO_URL}`,
-        repo_url: REPO_URL
-      })
-    });
-
-    if (response.ok) {
-      const agent = await response.json();
-      console.log(`[SPAWNER] Cloud Agent spawned: ${agent.id}`);
-      agentSpawned = true;
-      
-      // Monitor agent status
-      monitorAgent(agent.id);
-    } else {
-      console.error('[SPAWNER] Failed to spawn agent:', await response.text());
-    }
-  } catch (error) {
-    console.error('[SPAWNER] Error spawning agent:', error);
-  }
-}
-
-// Watch for new errors
-fs.watch(WATCH_FILE, async (eventType) => {
-  if (eventType === 'change') {
-    const pending = JSON.parse(fs.readFileSync(WATCH_FILE, 'utf8'));
-    if (pending.length > 0 && !agentSpawned) {
-      await spawnErrorDebugAgent();
-    }
-  }
-});
-
-console.log('[SPAWNER] Monitoring for errors, will spawn Cloud Agent when detected...');
-```
-
-
-
-### Option B: Direct Spawn on Error Report
-
-Modify `report_error` workflow to spawn agent after creating error report:
-
-```javascript
-// In report_error command logic (when error report created)
-if (config.cloud_agents?.enabled && config.cloud_agents?.auto_spawn) {
-  await spawnErrorDebugAgent(errorReport);
-}
-```
-
-
-
-### Option C: Git Hook Trigger
-
-Use git hook to spawn agent after commits that add error reports:
-
-```bash
-# .git/hooks/post-commit
-if git diff HEAD~1 --name-only | grep -q "\.cursor/error_reports/pending\.json"; then
-  node scripts/spawn_error_debug_agent.js
-fi
-```
-
-
-
-## Agent Instructions Template
-
-**File:** `scripts/error_debug_agent_instructions.md`
-
-```markdown
-# Error Debug Agent Instructions
-
-You are a Cloud Agent tasked with automatically debugging and fixing errors in the error queue.
-
-## Workflow
-
-1. **Read Error Queue:**
-    - Read `.cursor/error_reports/pending.json`
-    - Sort errors by priority: critical → high → medium → low
-    - Within same severity, oldest first
-
-2. **Process Each Error:**
-    - Load error report from file path
-    - Analyze error: category, severity, affected files
-    - Run `/debug_pending_errors --auto` workflow
-    - Use `/fix_feature_bug` to fix bugs
-    - Update error report with resolution status
-    - Move to resolved archive
-    - Remove from pending queue
-
-3. **Continue Until:**
-    - Pending queue is empty, OR
-    - Human intervention needed (unclear design, security-sensitive changes)
-
-4. **Human Intervention Required:**
-    - Schema conflicts requiring architectural decisions
-    - Security-sensitive changes
-    - Breaking API changes
-    - Missing context/documentation
-
-## Commands to Use
-
-- `/debug_pending_errors --auto` - Debug highest priority error
-- `/fix_feature_bug` - Fix the bug
-- Update error reports directly via file operations
-
-## Success Criteria
-
-- All errors processed
-- Error reports updated with resolution status
-- Resolved errors archived
-- Pending queue empty (or errors requiring human review logged)
-```
-
-
-
-## API Integration Details
-
-Based on release orchestrator pattern:
-
-```javascript
-// scripts/spawn_error_debug_agent.js
-const API_URL = process.env.CURSOR_CLOUD_API_URL || 'https://api.cursor.com/v1';
-const API_KEY = process.env.CURSOR_CLOUD_API_KEY;
-const REPO_URL = process.env.REPO_URL || 'https://github.com/your-org/neotoma';
-const ENDPOINT = `${API_URL}/v0/agents`;
-
-async function spawnErrorDebugAgent() {
-  const instruction = `Process all pending errors in the error queue automatically.
-
-1. Read .cursor/error_reports/pending.json
-2. Process errors in priority order (critical → low)
-3. For each error:
-    - Load error report
-    - Debug and fix using /debug_pending_errors and /fix_feature_bug
-    - Update resolution status
-    - Archive resolved errors
-4. Stop when queue empty or human intervention needed
-
-Repository: ${REPO_URL}`;
-
-  const response = await fetch(ENDPOINT, {
-    method: 'POST',
-    headers: {
-      'Authorization': `Bearer ${API_KEY}`,
-      'Content-Type': 'application/json'
-    },
-    body: JSON.stringify({
-      instruction: instruction,
-      repo_url: REPO_URL,
-      // Additional agent configuration if available
-    })
-  });
-
-  if (!response.ok) {
-    throw new Error(`Failed to spawn agent: ${response.statusText}`);
-  }
-
-  return await response.json();
-}
-```
-
-
-
-## Agent Lifecycle Management
-
-### Monitoring Agent Status
-
-```javascript
-async function monitorAgent(agentId) {
-  const statusEndpoint = `${API_URL}/v0/agents/${agentId}/status`;
-  
-  // Poll agent status
-  const interval = setInterval(async () => {
-    const response = await fetch(statusEndpoint, {
-      headers: { 'Authorization': `Bearer ${API_KEY}` }
-    });
-    const status = await response.json();
-    
-    if (status.status === 'completed' || status.status === 'failed') {
-      clearInterval(interval);
-      console.log(`[SPAWNER] Agent ${agentId} finished: ${status.status}`);
-      agentSpawned = false; // Allow spawning new agent
-    }
-  }, 5000); // Poll every 5 seconds
-}
-```
-
-
-
-### Cleanup
-
-- Agents should terminate when queue is empty
-- Log agent activity for audit trail
-- Handle agent failures gracefully
-
-## Error Handling
-
-### API Errors
-
-- Handle authentication failures
-- Handle rate limits
-- Retry with backoff
-
-### Agent Failures
-
-- Log failures
-- Option to retry
-- Fallback to manual review
-
-### Human Intervention
-
-- Agent stops when unclear design needed
-- Logs error with details
-- Notify user (optional: email, notification)
-
-## Configuration Options
-
-```yaml
-development:
-  error_debugging:
-    cloud_agents:
-      enabled: true
-      api_url: "${CURSOR_CLOUD_API_URL}"
-      api_key: "${CURSOR_CLOUD_API_KEY}"
-      repo_url: "${REPO_URL}"
-      auto_spawn: true
-      max_concurrent_agents: 1
-      spawn_on_new_error: true  # Spawn when new error added
-      spawn_on_commit: false  # Spawn on git commit with errors
-      poll_interval_ms: 1000  # How often to check for new errors
-      agent_instruction_template: "scripts/error_debug_agent_instructions.md"
-      monitor_agent: true  # Monitor agent status
-      retry_failed: true  # Retry if agent fails
-      max_retries: 3
-```
-
-
-
-## Files to Create
-
-1. `scripts/spawn_error_debug_agent.js` - Main spawner script
-2. `scripts/monitor_error_agent.js` - Agent monitoring (optional)
-3. `scripts/error_debug_agent_instructions.md` - Agent instructions template
-4. Update `package.json` - Add npm scripts
-5. Update `foundation-config.yaml` - Add Cloud Agents config
-
-## Files to Modify
-
-1. `foundation/agent_instructions/cursor_commands/report_error.md` - Document Cloud Agent integration
-2. `docs/developer/getting_started.md` - Document Cloud Agents setup
-3. `.env.example` - Add Cloud Agents API credentials
-
-## npm Scripts
-
-```json
-{
-  "scripts": {
-    "watch:errors:agent": "node scripts/watch_and_spawn_agent.js",
-    "spawn:error-agent": "node scripts/spawn_error_debug_agent.js"
-  }
-}
-```
-
-
-
-## Usage
-
-### Manual Spawn
-
-```bash
-npm run spawn:error-agent
-```
-
-
-
-### Continuous Monitoring
-
-```bash
-npm run watch:errors:agent
-```
-
-
-
-### Git Hook (Optional)
-
-Add to `.git/hooks/post-commit`:
-
-```bash
-#!/bin/bash
-node scripts/spawn_error_debug_agent.js
-```
-
-
-
-## Testing
-
-1. Create test error report
-2. Verify agent spawns
-3. Monitor agent processing
-4. Verify errors resolved and archived
-5. Verify agent terminates when done
-
-## Limitations
-
-- Requires Cursor Cloud subscription
-- Requires API credentials
-- Agents run remotely (not truly "localhost")
-- API rate limits may apply
-- Agent execution time varies
-
-## Comparison with File Watcher Approach
-
-| Feature | Cloud Agents | File Watcher |
-
-|---------|-------------|--------------|
-
-| AI-powered fixes | ✅ Yes (Cursor's AI) | ❌ No (infrastructure only) |
-
-| Code bug fixes | ✅ Yes | ❌ No (logged for review) |
-
-| Local execution | ❌ No (remote) | ✅ Yes |
-
-| Subscription required | ✅ Yes | ❌ No |
-
-| API credentials | ✅ Required | ❌ Not needed |
-
-| Full automation | ✅ Yes | ⚠️ Partial |
-
-## Summary
-
-**This plan implements:** Cursor Cloud Agents for automated error debugging
-
-**AI Used:** Cursor's AI (via Cloud Agents)
-
-**Automatically fixes:** All errors (infrastructure + code bugs) **in committed/pushed code**
-
-**Requires:** Cursor Cloud subscription, API credentials, remote repository access
-
-**Runs:** Remotely in Cursor's cloud environment
-
-**⚠️ Limitation:** Only works with committed/pushed code, not uncommitted local changes
-
-**How it works:**
-1. Error reporter creates error in pending.json (from committed code)
-2. Spawner script detects error and calls Cloud Agents API
-3. Cloud Agent spawned with instructions to process errors
-4. Agent clones remote repository (GitHub)
-5. Agent uses Cursor's AI to analyze and fix bugs in committed code
-6. Agent commits fixes and updates error reports
-7. Agent terminates when queue empty
-
-**For uncommitted local changes:** Consider Claude Code instead, or commit changes first, then use Cloud Agents.
-
-## Alternative: Claude Code for Local Development
-
-If you need to fix errors in **uncommitted local changes**, Claude Code would be superior:
-
-**Claude Code advantages:**
-- ✅ Works with local files directly
-- ✅ No subscription required
-- ✅ No API credentials needed
-- ✅ Immediate access to uncommitted changes
-
-**Implementation would require:**
-- Installing Claude Code CLI
-- Creating integration script that calls Claude Code
-- Formatting error reports for Claude Code input
-
-Should I create a separate plan for Claude Code integration for local development?