neotoma 0.3.0 → 0.3.2

package/docs/releases/archived/aspirational/v0.5.0/release_plan.md

@@ -1,236 +0,0 @@
-## Release v0.5.0 — Agent Cryptographic Signing
-### 1. Release Overview
-- **Release ID**: `v0.5.0`
-- **Name**: Agent Cryptographic Signing
-- **Release Type**: Not Marketed (production deployment without marketing activities)
-- **Goal**: Enable cryptographic attribution and permissioning for agent interactions. Every agent that interacts with Neotoma can sign their interactions with public keys for attribution, permissioning, and audit trails.
-- **Priority**: P1 (high-value enhancement, enables multi-agent coordination)
-- **Target Ship Date**: After v0.3.0 validation, before v1.0.0
-- **Marketing Required**: No (not marketed release)
-- **Deployment**: Production (neotoma.io)
-- **Owner**: Mark Hendrickson
-#### 1.1 Canonical Specs (Authoritative Sources)
-- **Manifest**: `docs/NEOTOMA_MANIFEST.md`
-- **MCP Specification**: `docs/specs/MCP_SPEC.md`
-- **Payload Model**: `docs/architecture/source_material_model.md`
-- **Crypto Infrastructure**: `src/crypto/` (existing Ed25519 signing)
-This release plan coordinates agent signing scope into a concrete release plan.
-**Release Classification:**
-- **All releases deploy to production** at neotoma.io
-- **Release types**: "Marketed" (with marketing activities) vs "Not Marketed" (silent deployment)
-- **This release**: Not Marketed (deploys to production without marketing activities)
-### 2. Problem Statement
-**Current State:**
-- Agents interact with Neotoma via MCP but cannot cryptographically prove their identity
-- No way to attribute data modifications to specific agents
-- No granular permissioning per agent
-- No cryptographic audit trail for compliance
-- Multi-agent coordination lacks identity differentiation
-**User Pain Points Solved:**
-1. **Attribution**: "Which agent created this data?" — Cryptographic proof of agent identity
-2. **Security**: "Can I trust this agent?" — Impersonation prevention via signatures
-3. **Permissioning**: "How do I control what each agent can do?" — Granular permissions per public key
-4. **Audit Trail**: "Who changed my data?" — Non-repudiable cryptographic audit trail
-5. **Data Integrity**: "Did an agent tamper with my data?" — Signature verification detects tampering
-6. **Multi-Agent Coordination**: "How do multiple agents coordinate?" — Identity differentiation enables coordination
-7. **Access Revocation**: "How do I revoke access?" — Public key-based revocation
-### 3. Scope
-#### 3.1 Included Feature Units
-**Phase 1: Core Infrastructure**
-- **FU-200**: Agent Keypair Generation Utilities
-  - Client-side utilities for generating per-chat Ed25519 keypairs
-  - Key storage strategies (sessionStorage, IndexedDB, localStorage)
-  - Key management helpers (import/export, regeneration)
-  - Browser and Node.js support
-- **FU-201**: Payload Signature Extension
-  - Extend `PayloadEnvelope.provenance` to include:
-    - `signer_public_key?: string` (base64url-encoded Ed25519 public key)
-    - `signature?: string` (base64url-encoded Ed25519 signature)
-  - Update `ProvenanceSchema` in `src/services/payload_schema.ts`
-  - Update `docs/architecture/source_material_model.md`
-- **FU-202**: Agent Identity Service Implementation
-  - Implement `getAgentPublicKey()` in `src/crypto/agent_identity.ts`
-  - Extract public key from request context (MCP request or HTTP header)
-  - Replace stub implementation with real extraction logic
-**Phase 2: MCP Integration**
-- **FU-203**: MCP Payload Signing
-  - MCP client library helpers for signing `submit_payload` requests
-  - Helper functions: `signPayload()`, `getAgentKeypair(chatId)`
-  - Example implementations for browser and Node.js clients
-  - Documentation updates to `docs/specs/MCP_SPEC.md`
-- **FU-204**: Signature Verification Middleware
-  - Verify payload signatures in `submit_payload` handler
-  - Optional verification initially (backward compatibility)
-  - Signature verification logic using existing `verifySignature()` from `src/crypto/signature.ts`
-  - Error handling for invalid signatures
-**Phase 3: Permission System Foundation (P1, Optional)**
-- **FU-205**: Agent Public Key Registry
-  - Database table: `agent_public_keys`
-  - Fields: `public_key` (PK), `agent_id`, `user_id`, `permissions` (JSONB), `created_at`, `revoked_at`
-  - CRUD operations for agent key management
-- **FU-206**: Permission Enforcement Framework
-  - Permission checking based on public key
-  - Permission types: `read`, `write`, `financial_operations`, `admin`
-  - Middleware for permission enforcement
-  - Integration with `submit_payload` handler
-#### 3.2 Deferred to Post-MVP
-- **FU-207**: Required Signatures
-  - Make signatures mandatory for all write operations
-  - Migration period needed for existing clients
-- **FU-208**: Agent Trust Profiles
-  - User-configurable trust levels per agent public key
-  - Requires UI layer (v1.0.0+)
-- **FU-209**: Agent Revocation UI
-  - UI for revoking agent access
-  - Requires UI layer (v1.0.0+)
-#### 3.3 Excluded
-- UI components (v1.0.0+)
-- Multi-user agent management (v1.0.0+)
-- Agent analytics dashboard (v1.0.0+)
-- Required signatures (deferred for migration period)
-### 4. Technical Architecture
-#### 4.1 Key Generation Flow
-```typescript
-// Client-side (browser or Node.js)
-import { generateEd25519KeyPair, deriveBearerToken } from '@neotoma/crypto';
-async function initializeChatSession(chatId: string) {
-  const keyPair = await generateEd25519KeyPair();
-  const publicKeyToken = deriveBearerToken(keyPair.publicKey);
-  
-  // Store keypair (encrypted in localStorage/IndexedDB)
-  storeAgentKeypair(chatId, keyPair);
-  
-  return { keyPair, publicKeyToken };
-}
-```
-#### 4.2 Payload Signing Flow
-```typescript
-// MCP client signs payload before submission
-import { signPayload } from '@neotoma/mcp-client';
-const agentKeyPair = await getAgentKeypair(chatId);
-const signedPayload = signPayload(payloadEnvelope, agentKeyPair);
-// Submit signed payload via MCP
-await mcpClient.call('submit_payload', signedPayload);
-```
-#### 4.3 Signature Verification Flow
-```typescript
-// Server-side verification in submit_payload handler
-import { verifySignature } from '../crypto/signature.js';
-import { parseBearerToken } from '../crypto/keys.js';
-if (payload.provenance.signature && payload.provenance.signer_public_key) {
-  const publicKey = parseBearerToken(payload.provenance.signer_public_key);
-  const payloadBytes = serializePayloadForSigning(payload);
-  const signature = base64UrlDecode(payload.provenance.signature);
-  
-  const isValid = verifySignature(payloadBytes, signature, publicKey);
-  if (!isValid) {
-    throw new Error('Invalid payload signature');
-  }
-}
-```
-#### 4.4 Database Schema Changes
-**New Table (if FU-205 included):**
-```sql
-CREATE TABLE agent_public_keys (
-  public_key TEXT PRIMARY KEY, -- Base64url-encoded Ed25519 public key
-  agent_id TEXT, -- Short identifier (first 16 chars of public_key)
-  user_id UUID REFERENCES auth.users(id),
-  permissions JSONB DEFAULT '{"read": true, "write": true}'::jsonb,
-  created_at TIMESTAMPTZ DEFAULT NOW(),
-  revoked_at TIMESTAMPTZ,
-  metadata JSONB DEFAULT '{}'::jsonb
-);
-CREATE INDEX idx_agent_public_keys_user_id ON agent_public_keys(user_id);
-CREATE INDEX idx_agent_public_keys_agent_id ON agent_public_keys(agent_id);
-```
-**Payload Schema Extension:**
-```typescript
-// src/services/payload_schema.ts
-export const ProvenanceSchema = z.object({
-  source_refs: z.array(z.string()),
-  extracted_at: z.string().datetime(),
-  extractor_version: z.string(),
-  agent_id: z.string().optional(),
-  signer_public_key: z.string().optional(), // NEW
-  signature: z.string().optional(), // NEW
-});
-```
-### 5. Acceptance Criteria
-#### 5.1 Product Acceptance Criteria
-- ✅ Agents can generate Ed25519 keypairs per chat session
-- ✅ Payloads can include cryptographic signatures
-- ✅ Signatures are verified when provided (optional initially)
-- ✅ Agent public keys are extractable from request context
-- ✅ MCP clients can sign payloads using provided utilities
-- ✅ Backward compatibility maintained (unsigned payloads still work)
-#### 5.2 Technical Acceptance Criteria
-- ✅ `generateEd25519KeyPair()` available for client-side use
-- ✅ `PayloadEnvelope.provenance` includes `signer_public_key` and `signature` fields
-- ✅ `getAgentPublicKey()` extracts public key from request context
-- ✅ Signature verification in `submit_payload` handler (optional)
-- ✅ MCP client library helpers for signing (`signPayload()`, `getAgentKeypair()`)
-- ✅ Agent public key registry table (if FU-205 included)
-- ✅ Permission checking framework (if FU-206 included)
-- ✅ Integration tests passing
-- ✅ Documentation updated (`MCP_SPEC.md`, `source_material_model.md`)
-#### 5.3 Business Acceptance Criteria
-- ✅ Enables multi-agent coordination with attribution
-- ✅ Foundation for permission system
-- ✅ Cryptographic audit trail for compliance
-- ✅ Backward compatible (signatures optional initially)
-- ✅ No breaking changes to existing MCP clients
-### 6. Success Criteria
-- All Phase 1-2 Feature Units completed
-- Agent keypair generation utilities functional
-- Payload signatures can be included and verified
-- MCP clients can sign payloads
-- Signature verification middleware functional
-- Integration tests passing
-- Backward compatibility maintained (unsigned payloads still work)
-- Documentation updated (`MCP_SPEC.md`, `source_material_model.md`, `docs/specs/AGENT_SIGNING.md`)
-- No breaking changes to existing MCP clients
-### 7. Implementation Notes
-#### 7.1 Backward Compatibility
-- Signatures are **optional** initially to maintain backward compatibility
-- Existing MCP clients without signing continue to work
-- Signature verification only occurs when both `signer_public_key` and `signature` are present
-- Post-MVP: Signatures will become required for write operations (FU-207)
-#### 7.2 Key Storage Strategies
-**Browser Clients:**
-- `sessionStorage`: Per-tab, cleared on close (ephemeral)
-- `IndexedDB`: Persistent across sessions (recommended)
-- `localStorage`: Simple but less secure (fallback)
-**Node.js Clients:**
-- File system: `~/.neotoma/agent_keys/`
-- Environment variables: For CI/CD agents
-- Keychain: OS-native keychain integration (future)
-#### 7.3 Migration Path
-1. **Phase 1**: Infrastructure (signatures optional)
-2. **Phase 2**: MCP integration (clients can sign)
-3. **Phase 3**: Permission system (optional, P1)
-4. **Post-MVP**: Required signatures (FU-207)
-### 8. Dependencies
-- **v0.3.0**: Operational Hardening (prerequisite)
-- **Existing crypto infrastructure**: `src/crypto/` (Ed25519 signing already implemented)
-- **MCP protocol**: No protocol changes needed (signatures in payload provenance)
-### 9. Risks and Mitigations
-**Risk**: Breaking existing MCP clients
-- **Mitigation**: Signatures optional initially, backward compatibility maintained
-**Risk**: Key management complexity for clients
-- **Mitigation**: Provide helper utilities and clear documentation
-**Risk**: Performance impact of signature verification
-- **Mitigation**: Ed25519 verification is fast (~1-2ms), optional verification initially
-**Risk**: Key storage security
-- **Mitigation**: Document best practices, provide encryption helpers
-### 10. Related Documents
-- `docs/specs/MCP_SPEC.md` — MCP action specification
-- `docs/architecture/source_material_model.md` — Payload model architecture
-- `src/crypto/agent_identity.ts` — Agent identity abstraction (stub)
-- `src/crypto/signature.ts` — Ed25519 signature utilities
-- `src/crypto/keys.ts` — Key generation utilities
-- `docs/foundation/composability_analysis.md` — Multi-agent coordination context
-### 11. Release Spacing
-- **v0.3.0**: Operational hardening (prerequisite)
-- **v0.5.0**: Agent cryptographic signing (this release)
-- **v0.4.0**: Intelligence + housekeeping (can run in parallel)
-- **v1.0.0**: MVP (can include agent signing if validated)

package/docs/releases/archived/aspirational/v0.9.0/README.md

@@ -1,78 +0,0 @@
-# Neotoma v0.9.0 - MCP Support System
-
-**Status:** Planning  
-**Origin:** Split from v0.2.1  
-**Breaking Changes:** No
-
-## Overview
-
-Version 0.9.0 adds MCP-based support inquiry capabilities, enabling users to get help without leaving their AI tool environment. Uses the documentation generated in v0.2.1 as the knowledge base for a RAG-powered support agent.
-
-## Feature Units
-
-### FU-302: MCP Support Inquiry Endpoint
-New MCP action `query_support` that accepts support queries and returns agent-generated responses with citations.
-
-### FU-303: Support Agent System
-RAG-based support agent that:
-- Retrieves relevant documentation context
-- Generates accurate responses
-- Includes citations to source documentation
-- Handles edge cases gracefully
-
-## Dependencies
-
-**Required from previous releases:**
-- v0.2.1: Documentation generation (FU-300) - knowledge base
-- v0.2.1: Documentation web server (FU-301) - searchable index
-- v0.1.0: MCP Server Core (FU-200) - MCP protocol
-
-## Why v0.9.0?
-
-Originally part of v0.2.1, but support capabilities are better positioned immediately before v1.0.0:
-- Documentation foundation established early (v0.2.1)
-- Support system valuable when user base exists (v1.0.0)
-- Reduces v0.2.1 scope for faster delivery
-- Better sequencing: docs first, support later
-
-## Usage Example
-
-```typescript
-// Query support via MCP
-const response = await mcp.call('query_support', {
-  query: 'How do I submit a transaction payload?',
-  context: ['mcp', 'transactions']
-});
-
-// Response includes:
-{
-  answer: "To submit a transaction payload...",
-  citations: [
-    { doc: "MCP_SPEC.md", section: "submit_payload" },
-    { doc: "source_material_model.md", section: "Capability Registry" }
-  ],
-  related: ["submit_payload", "capabilities"]
-}
-```
-
-## Timeline
-
-- **Week 1:** MCP Support Endpoint (FU-302)
-- **Week 2-3:** Support Agent System (FU-303)
-- **Week 4:** Testing & Validation
-
-**Total:** 4 weeks
-
-## Success Criteria
-
-- MCP `query_support` action operational
-- Support agent accuracy ≥ 80% on test queries
-- Response time < 3s (p95)
-- Citations included in all responses
-- Edge cases handled gracefully
-
-See `release_plan.md` for complete details.
-
-
-
-

package/docs/releases/archived/aspirational/v0.9.0/manifest.yaml

@@ -1,111 +0,0 @@
-release:
-  id: "v0.9.0"
-  name: "MCP Support System"
-  type: "not_marketed" # marketed | not_marketed
-  status: "planning" # planning | in_progress | in_testing | ready_for_deployment | deployed | completed
-  target_date: "before_v1.0.0"
-  priority: "P1"
-  marketing_required: false
-  origin: "Split from v0.2.1 for better sequencing"
-
-# Execution strategy
-execution_strategy:
-  type: "sequential" # "multi_agent" or "sequential"
-  max_parallel_fus: 1
-  max_high_risk_in_parallel: 1
-  agent_spawning:
-    enabled: true
-    status_tracking: "file"
-    status_file: "docs/releases/v0.9.0/status.md"
-
-feature_units:
-  # MCP Support Inquiry Endpoint
-  - id: "FU-302"
-    priority: "P1"
-    dependencies: ["FU-200", "FU-300", "FU-301"]
-    risk_level: "low"
-    notes: "Moved from v0.2.1; MCP action for support queries"
-
-  # Support Agent System
-  - id: "FU-303"
-    priority: "P1"
-    dependencies: ["FU-302", "FU-300", "FU-301"]
-    risk_level: "medium"
-    notes: "Moved from v0.2.1; RAG-based agent using static documentation"
-
-execution_schedule:
-  batches:
-    # Batch 0: MCP Support Endpoint
-    - batch_id: 0
-      feature_units: ["FU-302"]
-      dependencies: []
-      estimated_duration: "1 week"
-      notes: "MCP endpoint for support queries"
-
-    # Batch 1: Support Agent System
-    - batch_id: 1
-      feature_units: ["FU-303"]
-      dependencies: [0]
-      estimated_duration: "2 weeks"
-      notes: "RAG-based support agent with documentation index integration"
-
-checkpoints:
-  - id: "checkpoint_1"
-    name: "Support Agent Validation"
-    trigger: "after_batch_1"
-    validation_required: true
-    criteria:
-      - "Support agent accuracy ≥ 80% on test queries"
-      - "Citation quality validated"
-      - "Edge case handling functional"
-      - "Performance targets met (< 3s response time)"
-
-integration_tests:
-  - id: "IT-001"
-    name: "Support Query → Agent Response"
-    priority: "P0"
-    
-  - id: "IT-002"
-    name: "Documentation Update → Agent Knowledge"
-    priority: "P0"
-    
-  - id: "IT-003"
-    name: "Multi-Topic Support Query"
-    priority: "P1"
-    
-  - id: "IT-004"
-    name: "Edge Case Handling"
-    priority: "P1"
-
-acceptance_criteria:
-  product:
-    - "MCP query_support action operational"
-    - "Support agent responds accurately to common inquiries"
-    - "Support agent responses include citations"
-    - "Edge cases handled gracefully"
-    
-  technical:
-    - "MCP endpoint follows protocol specification"
-    - "Support agent accuracy ≥ 80% on test queries"
-    - "Response time < 3s (p95)"
-    - "RAG retrieval accuracy validated"
-    
-  business:
-    - "Users can query support via MCP"
-    - "Support burden reduced through automation"
-    - "User satisfaction improved"
-
-timeline:
-  estimated_duration: "4 weeks"
-  phases:
-    - name: "MCP Support Endpoint"
-      duration: "1 week"
-    - name: "Support Agent System"
-      duration: "2 weeks"
-    - name: "Testing & Validation"
-      duration: "1 week"
-
-notes: |
-  Split from v0.2.1 for better release sequencing. Support capabilities positioned 
-  before v1.0.0 when user base exists. Builds on documentation foundation from v0.2.1.
-

package/docs/releases/archived/aspirational/v0.9.0/release_plan.md

@@ -1,238 +0,0 @@
-## Release v0.9.0 — MCP Support System
-### 1. Release Overview
-- **Release ID**: `v0.9.0`
-- **Name**: MCP Support System
-- **Release Type**: Not Marketed (production deployment without marketing activities)
-- **Goal**: Add MCP-based support inquiry system with RAG agent that uses generated documentation as knowledge base. Enables users to get help without leaving their AI tool environment.
-- **Priority**: P1 (user experience enhancement)
-- **Target Ship Date**: Before v1.0.0 MVP release
-- **Marketing Required**: No (not marketed release)
-- **Deployment**: Production (neotoma.io)
-
-#### 1.0 Guiding Principle
-> Enable seamless support within the MCP environment before public MVP launch.
-
-This release completes the user enablement stack: documentation (v0.2.1) provides the knowledge base, and support system (v0.9.0) makes it queryable via MCP.
-
-#### 1.1 Canonical Specs (Authoritative Sources)
-- **Manifest**: `docs/NEOTOMA_MANIFEST.md`
-- **MVP Overview**: `docs/specs/MVP_OVERVIEW.md`
-- **MCP Specification**: `docs/specs/MCP_SPEC.md`
-- **Documentation Standards**: `docs/conventions/documentation_standards.md`
-
-This release plan coordinates the MCP support system scope into a concrete release plan.
-
-### 2. Scope
-
-#### 2.1 Included Feature Units (Deferred from v0.2.1)
-
-**MCP Support System:**
-- `FU-302`: MCP Support Inquiry Endpoint
-  - New MCP action: `query_support`
-  - Request/response schema for support queries
-  - Error handling and validation
-  - Integration with support agent
-  
-- `FU-303`: Support Agent System
-  - RAG-based agent using static documentation as knowledge base
-  - Query understanding and intent classification
-  - Context retrieval from documentation index
-  - Response generation with citations and guidance
-  - Integration with MCP endpoint
-
-#### 2.2 Dependencies
-
-**Required from Previous Releases:**
-- v0.2.1: FU-300 (Documentation generation) - provides knowledge base
-- v0.2.1: FU-301 (Documentation web server) - provides searchable index
-- v0.1.0: FU-200 (MCP Server Core) - provides MCP protocol foundation
-
-#### 2.3 Explicitly Excluded
-- Chat UI for support (MCP-only access)
-- Real-time human support escalation
-- Multi-language support (English only)
-- User-contributed documentation search
-- Support ticket system
-
-### 3. Release-Level Acceptance Criteria
-
-#### 3.1 Product
-- MCP `query_support` action operational and accessible via MCP clients
-- Support agent responds accurately to common inquiries:
-  - API usage questions
-  - Architecture questions
-  - Troubleshooting guidance
-  - Integration setup help
-- Support agent responses include citations to source documentation
-- Support agent handles edge cases gracefully (unclear queries, missing context)
-
-#### 3.2 Technical
-- MCP endpoint follows MCP protocol specification
-- Support agent accuracy validated (80%+ correct responses on test queries)
-- Support agent responses cite source documentation with links
-- Response time < 3 seconds (p95)
-- RAG retrieval accuracy validated
-- Documentation index integration functional
-- Error handling for malformed queries
-- Graceful degradation when documentation unavailable
-
-#### 3.3 Business
-- Users can query support via MCP without leaving their AI tool
-- Support burden reduced through automated guidance
-- User satisfaction improved through immediate, contextual help
-
-### 4. Cross-FU Integration Scenarios
-
-These scenarios must pass end-to-end before v0.9.0 is approved:
-
-1. **Support Query → Agent Response**
-   - Query MCP `query_support` action with question
-   - Verify agent retrieves relevant documentation context
-   - Verify response includes accurate answer with citations
-   - Verify response format follows MCP response schema
-
-2. **Documentation Update → Support Agent Knowledge**
-   - Update source documentation
-   - Regenerate static documentation
-   - Query support agent with question about updated content
-   - Verify agent uses updated documentation in response
-
-3. **Multi-Topic Support Query**
-   - Query support agent with complex multi-part question
-   - Verify agent retrieves context from multiple documentation sections
-   - Verify response addresses all parts of question
-   - Verify citations reference correct documentation sections
-
-4. **Edge Case Handling**
-   - Query with unclear/ambiguous question
-   - Query about undocumented feature
-   - Query with no relevant documentation
-   - Verify graceful responses in all cases
-
-### 5. Implementation Plan
-
-#### Phase 1: MCP Support Endpoint (1 week)
-**Tasks:**
-- [ ] Define `query_support` MCP action schema
-- [ ] Implement MCP endpoint handler
-- [ ] Add request validation
-- [ ] Add error handling
-- [ ] Integration with support agent service
-- [ ] Unit tests for endpoint
-
-**Acceptance Criteria:**
-- Endpoint callable via MCP
-- Request/response schema validated
-- Error handling functional
-- Unit tests passing
-
-#### Phase 2: Support Agent System (2 weeks)
-**Tasks:**
-- [ ] Implement RAG retrieval from documentation index
-- [ ] Implement query understanding logic
-- [ ] Implement response generation with citations
-- [ ] Add context retrieval optimization
-- [ ] Integration with MCP endpoint
-- [ ] Test query accuracy on sample questions
-
-**Acceptance Criteria:**
-- Agent retrieves relevant documentation
-- Responses include citations
-- 80%+ accuracy on test queries
-- Response time < 3s (p95)
-
-#### Phase 3: Testing & Validation (1 week)
-**Tasks:**
-- [ ] Create test query dataset (50+ questions)
-- [ ] Validate response accuracy
-- [ ] Validate citation quality
-- [ ] End-to-end integration tests
-- [ ] Performance testing
-- [ ] Edge case testing
-
-**Acceptance Criteria:**
-- All integration tests passing
-- Accuracy threshold met (80%+)
-- Performance targets met
-- Edge cases handled gracefully
-
-### 6. Success Criteria
-
-**Release is Complete When:**
-1. ✅ MCP `query_support` action implemented and tested
-2. ✅ Support agent system operational
-3. ✅ Support agent accuracy validated (80%+ on test queries)
-4. ✅ Support agent responses include citations
-5. ✅ Integration tests passing (4 scenarios)
-6. ✅ Performance targets met (< 3s response time)
-7. ✅ Edge case handling validated
-8. ✅ Deployed to production (neotoma.io)
-
-### 7. Dependencies
-
-**Upstream:**
-- v0.2.1: Documentation generation and web server must be complete
-- v0.1.0: MCP server core must be operational
-
-**Downstream:**
-- v1.0.0: Support system ready for MVP users
-
-### 8. Rollback Plan
-
-If issues are discovered:
-1. Disable `query_support` MCP action (remove from tool list)
-2. Redirect users to web documentation
-3. Fix issues and redeploy
-
-### 9. Testing Strategy
-
-**Unit Tests:**
-- MCP endpoint validation
-- RAG retrieval logic
-- Response formatting
-- Citation extraction
-
-**Integration Tests:**
-- Full query → response flow
-- Documentation index integration
-- MCP protocol compliance
-- Multi-topic queries
-
-**Accuracy Tests:**
-- 50+ test queries covering:
-  - API usage questions
-  - Architecture questions
-  - Troubleshooting scenarios
-  - Integration setup
-- Validation: 80%+ correct responses
-
-### 10. Timeline
-
-- **Week 1:** MCP Support Endpoint (FU-302)
-- **Week 2-3:** Support Agent System (FU-303)
-- **Week 4:** Testing & Validation
-
-**Total Duration:** 4 weeks
-
-### 11. Release Spacing Context
-
-| Release | Focus | Status |
-|---------|-------|--------|
-| v0.2.1 | Documentation generation & web server | Prerequisite |
-| v0.2.15 | Complete architecture migration | Planned |
-| **v0.9.0** | **MCP support system** | **This release** |
-| v1.0.0 | MVP (public release) | Next major |
-
-### 12. Status
-- **Current Status**: `planning`
-- **Owner**: Mark Hendrickson
-- **Gate**: v0.2.1 must be complete (documentation available)
-- **Notes**:
-  - Split from original v0.2.1 scope
-  - Support capabilities moved closer to v1.0.0 MVP
-  - Documentation foundation in v0.2.1 enables this release
-  - Improves user experience for v1.0.0 launch
-
-
-
-