mcp-adr-analysis-server

# Tool Context Documentation System - Implementation Plan ## Overview This document outlines the design and implementation plan for a persistent context documentation system that captures tool execution results and project-specific patterns for reuse in future sessions. ## Problem Statement When tools like `bootstrap_validation_loop` run, they generate valuable context including: - Platform detection results - Validated patterns and deployment strategies - Environment-specific configurations - Learnings from execution (successes/failures) - Architectural decisions Currently, this context is lost after the session ends. Developers have to re-discover or re-analyze the same information in future sessions, especially problematic for: - LLMs with limited context windows (e.g., Gemini) - Long-term project maintenance - Team onboarding - CI/CD pipeline consistency ## Solution: Tool Context Documents Generate persistent, project-specific context documents that can be: 1. **Automatically created** by tools during execution 2. **Stored in a predictable location** within the project 3. **Easily referenced** by developers and LLMs in future prompts 4. **Version controlled** alongside code and ADRs --- ## Context Document Schema ### Standard Structure All context documents follow a consistent markdown format: ````markdown # Tool Context: {Tool Name} > **Generated**: {ISO timestamp} > **Tool Version**: {version} > **Project**: {project name/path} ## Quick Reference Brief summary for immediate use (1-2 paragraphs) ## Execution Summary - **Status**: Success | Failed | Partial - **Confidence**: {0-100}% - **Key Findings**: Bullet list of main outcomes ## Detected Context ### Platform/Environment - Primary: {platform} - Confidence: {percentage} - Evidence: {key evidence files/indicators} ### Project Configuration - Architecture: {detected architecture} - Technologies: {list} - Deployment Target: {target} ### Validated Pattern (if applicable) - **Pattern Name**: {e.g., Multicluster GitOps, Industrial Edge, Medical Diagnosis} - **Version**: {pattern version} - **Pattern Type**: {platform type} - **Base Repository**: {GitHub URL} - **Documentation**: {pattern docs URL} - **Authoritative Sources**: {list of required sources} - **Why Chosen**: {rationale for this pattern} - **Deployment Phases**: {number of phases} - **Validation Checks**: {number of checks} ## Generated Artifacts List of files/ADRs/configs created by this tool execution ## Key Decisions Architectural and deployment decisions made during execution ## Learnings & Recommendations ### Successes ✅ - What worked well ### Failures ⚠️ - What didn't work - Recommendations for fixes ### Environment-Specific Notes - Special considerations for this environment ## Usage in Future Sessions ### How to Reference This Context ```text Example prompt: "Using the context from docs/context/bootstrap-{timestamp}.md, continue the deployment process for {platform}" ``` ```` ### Related Documents - ADRs: {links} - Other context docs: {links} - Configuration files: {links} ## Raw Data (Optional) <details> <summary>Full execution output</summary> ```json { // Complete execution result for debugging } ``` </details> --- _Auto-generated by {tool_name} v{version}_ ``` ### Schema Fields | Field | Type | Required | Description | |-------|------|----------|-------------| | `tool_name` | string | Yes | Name of the tool that generated this | | `generated` | ISO datetime | Yes | When this context was created | | `tool_version` | semver | Yes | Tool version for compatibility | | `project` | string | Yes | Project identifier | | `status` | enum | Yes | Success, Failed, Partial | | `confidence` | number (0-100) | No | Confidence in results | | `detected_context` | object | Yes | Platform, tech stack, architecture | | `artifacts` | array[string] | No | Files/ADRs created | | `decisions` | array[Decision] | No | Key architectural decisions | | `learnings` | array[Learning] | No | Successes, failures, recommendations | | `related_docs` | array[string] | No | Links to ADRs, configs, etc. | --- ## Storage Strategy ### Directory Structure ``` docs/ ├── context/ │ ├── README.md # Overview of context system │ ├── bootstrap/ │ │ ├── latest.md # Symlink to most recent │ │ ├── bootstrap-20250119T143022.md # Timestamped execution │ │ └── bootstrap-20250115T091533.md # Historical context │ ├── deployment/ │ │ ├── latest.md │ │ └── deployment-analysis-20250119.md │ ├── environment/ │ │ ├── latest.md │ │ └── environment-analysis-20250118.md │ ├── research/ │ │ ├── latest.md │ │ ├── openshift-research-20250119.md │ │ └── kubernetes-research-20250117.md │ └── planning/ │ ├── latest.md │ └── adr-planning-session-20250116.md ```` ### File Naming Convention **Format**: `{tool-category}-{detail}-{ISO-date}.md` **Examples**: - `bootstrap-openshift-20250119T143022.md` - `deployment-readiness-check-20250119T101500.md` - `research-validated-patterns-20250118T154433.md` - `planning-microservices-architecture-20250115.md` ### Retention Policy - **latest.md**: Always points to most recent context for that category - **Historical**: Keep last 10 executions per category - **Archive**: Move older contexts to `docs/context/archive/` after 30 days - **Cleanup**: Add cleanup script to prune old contexts --- ## Tools Benefiting from Context Generation ### 1. Bootstrap & Deployment Tools #### `bootstrap_validation_loop` **Context Generated**: - Platform detection (OpenShift, Kubernetes, Docker, etc.) - Validated pattern selection and configuration - Research report from authoritative sources - Deployment plan with architecture diagrams - Environment snapshot (running services, versions) - Execution learnings (what worked, what failed) - Bootstrap ADR path and status **Context Document**: `docs/context/bootstrap/bootstrap-{platform}-{timestamp}.md` **Value**: Developers can reference the exact validated pattern, deployment steps, and environment configuration in future sessions without re-running detection. --- #### `deployment_readiness` **Context Generated**: - Readiness assessment (pass/fail for deployment gates) - Missing prerequisites and blockers - Deployment risks and mitigation strategies - Compliance checks (security, performance, architecture) **Context Document**: `docs/context/deployment/readiness-{timestamp}.md` **Value**: Track deployment readiness over time, understand what changed between attempts. --- #### `deployment_analysis` **Context Generated**: - Current deployment state analysis - Resource utilization and health - Deployment history and patterns - Recommended optimizations **Context Document**: `docs/context/deployment/analysis-{timestamp}.md` **Value**: Maintain historical deployment insights for troubleshooting and optimization. --- ### 2. Environment & Research Tools #### `environment_analysis` **Context Generated**: - Detected environment configuration - Available tools and versions - Infrastructure capabilities - Environment-specific constraints **Context Document**: `docs/context/environment/analysis-{timestamp}.md` **Value**: Preserve environment details for consistent deployments across sessions. --- #### `perform_research` / `research_integration` **Context Generated**: - Research questions asked - Sources consulted (authoritative docs, GitHub, Stack Overflow) - Research findings and confidence scores - Technology decisions based on research - Cached research results **Context Document**: `docs/context/research/{topic}-research-{timestamp}.md` **Value**: Avoid re-researching the same topics, maintain knowledge base of research findings. --- ### 3. Planning & Decision Tools #### `interactive_adr_planning` **Context Generated**: - Planning session decisions - Architectural options considered - Trade-offs analyzed - Selected approach and rationale - ADRs created from planning **Context Document**: `docs/context/planning/session-{timestamp}.md` **Value**: Preserve planning decisions and rationale for future reference and ADR updates. --- #### `adr_validation` **Context Generated**: - Validation results (ADR compliance) - Detected inconsistencies or gaps - Recommendations for improvements - ADR quality scores **Context Document**: `docs/context/validation/adr-validation-{timestamp}.md` **Value**: Track ADR quality over time, maintain validation history. --- ### 4. Git & Workflow Tools #### `smart_git_push` **Context Generated**: - Git workflow patterns used - Commit conventions followed - Branch strategies detected - Push validation results **Context Document**: `docs/context/git/workflow-{timestamp}.md` **Value**: Maintain consistent git practices across sessions. --- ## Implementation Plan ### Phase 1: Core Infrastructure (Week 1) #### 1.1 Create Context Manager Utility **File**: `src/utils/context-document-manager.ts` ```typescript export interface ToolContextMetadata { toolName: string; toolVersion: string; generated: string; // ISO timestamp projectPath: string; projectName: string; status: 'success' | 'failed' | 'partial'; confidence?: number; } export interface ToolContextDocument { metadata: ToolContextMetadata; quickReference: string; executionSummary: { status: string; confidence?: number; keyFindings: string[]; }; detectedContext: Record<string, any>; generatedArtifacts?: string[]; keyDecisions?: Array<{ decision: string; rationale: string; alternatives?: string[]; }>; learnings?: { successes: string[]; failures: string[]; recommendations: string[]; environmentSpecific: string[]; }; relatedDocuments?: { adrs: string[]; configs: string[]; otherContexts: string[]; }; rawData?: any; } export class ToolContextManager { private contextDir: string; constructor(projectPath: string) { this.contextDir = path.join(projectPath, 'docs', 'context'); } async initialize(): Promise<void>; async saveContext( category: string, document: ToolContextDocument ): Promise<string>; async loadLatestContext(category: string): Promise<ToolContextDocument | null>; async loadContextByTimestamp( category: string, timestamp: string ): Promise<ToolContextDocument | null>; async listContexts(category: string): Promise<string[]>; async updateLatestSymlink(category: string, filePath: string): Promise<void>; async cleanupOldContexts( category: string, keepCount: number = 10 ): Promise<void>; generateMarkdown(document: ToolContextDocument): string; } ```` **Tests**: `tests/utils/context-document-manager.test.ts` --- #### 1.2 Create README for Context System **File**: `docs/context/README.md` Explain: - Purpose of context documents - How to use them in prompts - File organization - Retention policy - Examples of referencing context --- ### Phase 2: Bootstrap Tool Integration (Week 2) #### 2.1 Integrate Context Generation into Bootstrap Tool **File**: `src/tools/bootstrap-validation-loop-tool.ts` Add context generation at key points: ```typescript import { ToolContextManager, ToolContextDocument } from '../utils/context-document-manager.js'; // In BootstrapValidationLoop class private contextManager: ToolContextManager; constructor(projectPath: string, adrDirectory: string, maxIterations: number = 5) { // ... existing initialization this.contextManager = new ToolContextManager(projectPath); } // After deployment plan generation (line ~270) async saveBootstrapContext( platformDetection: PlatformDetectionResult, validatedPattern: ValidatedPattern | null, deploymentPlan: DynamicDeploymentPlan, bootstrapAdrPath: string ): Promise<void> { const contextDoc: ToolContextDocument = { metadata: { toolName: 'bootstrap_validation_loop', toolVersion: '1.0.0', generated: new Date().toISOString(), projectPath: this.projectPath, projectName: path.basename(this.projectPath), status: 'success', confidence: platformDetection.confidence * 100, }, quickReference: ` Detected ${platformDetection.primaryPlatform} (${(platformDetection.confidence * 100).toFixed(0)}% confidence). Using validated pattern: ${validatedPattern?.name || 'Dynamic AI Analysis'}. Bootstrap ADR: ${bootstrapAdrPath} `, executionSummary: { status: 'Platform detected and deployment plan generated', confidence: platformDetection.confidence * 100, keyFindings: [ `Primary platform: ${platformDetection.primaryPlatform}`, `Validated pattern: ${validatedPattern?.name || 'N/A'}`, `Required files: ${deploymentPlan.requiredFiles.length}`, `Deployment steps: ${deploymentPlan.deploymentSteps.length}`, ], }, detectedContext: { platform: { primary: platformDetection.primaryPlatform, all: platformDetection.detectedPlatforms.map(p => p.type), confidence: platformDetection.confidence, evidence: platformDetection.evidence.slice(0, 10), }, validatedPattern: validatedPattern ? { name: validatedPattern.name, version: validatedPattern.version, platformType: validatedPattern.platformType, baseRepository: validatedPattern.baseCodeRepository.url, authoritativeSources: validatedPattern.authoritativeSources.map(s => ({ type: s.type, url: s.url, required: s.requiredForDeployment, })), } : null, deploymentPlan: { recommendedPlatform: deploymentPlan.recommendedPlatform, confidence: deploymentPlan.confidence, source: deploymentPlan.source, requiredFiles: deploymentPlan.requiredFiles.map(f => ({ path: f.path, purpose: f.purpose, required: f.required, })), environmentVariables: deploymentPlan.environmentVariables.map(e => ({ name: e.name, required: e.required, isSecret: e.isSecret, })), deploymentSteps: deploymentPlan.deploymentSteps.length, estimatedDuration: deploymentPlan.estimatedDuration, }, }, generatedArtifacts: [ bootstrapAdrPath, path.join(this.projectPath, 'bootstrap.sh'), path.join(this.projectPath, 'validate_bootstrap.sh'), ], keyDecisions: [ { decision: `Use ${platformDetection.primaryPlatform} as deployment platform`, rationale: `Detected with ${(platformDetection.confidence * 100).toFixed(0)}% confidence based on project structure and configuration files`, }, ], relatedDocuments: { adrs: [bootstrapAdrPath], configs: deploymentPlan.requiredFiles.map(f => f.path), otherContexts: [], }, }; await this.contextManager.saveContext('bootstrap', contextDoc); } ``` Call this method after creating the bootstrap ADR (around line 270): ```typescript // After line 270: bootstrapAdrPath created await this.saveBootstrapContext( this.platformDetection!, this.validatedPattern, this.deploymentPlan!, bootstrapAdrPath ); ``` --- #### 2.2 Update Bootstrap Results to Include Context Path Modify the return type of `executeLoop` to include context document path: ```typescript return { success, iterations: this.currentIteration, finalResult, adrUpdates, executionHistory: this.executionHistory, deploymentPlan: this.deploymentPlan, bootstrapAdrPath, contextDocumentPath: contextDocPath, // NEW requiresHumanApproval: true, }; ``` --- ### Phase 3: Extend to Other Tools (Week 3-4) Apply similar context generation to: 1. **deployment_readiness** → `docs/context/deployment/readiness-{timestamp}.md` 2. **environment_analysis** → `docs/context/environment/analysis-{timestamp}.md` 3. **perform_research** → `docs/context/research/{topic}-{timestamp}.md` 4. **interactive_adr_planning** → `docs/context/planning/session-{timestamp}.md` Each tool should: - Use `ToolContextManager` to save context - Generate appropriate `ToolContextDocument` - Return context document path in results - Update `latest.md` symlink for the category --- ### Phase 4: Usage Patterns & Documentation (Week 4) #### 4.1 Create Usage Guide **File**: `docs/how-to-guides/using-tool-context-documents.md` Content: - How to reference context in prompts - Examples for different LLMs (Claude, Gemini, GPT-4) - Best practices for context injection - How to find the right context document - How context improves consistency --- #### 4.2 Update Tool Documentation Add sections to each tool's documentation: - **Context Generation**: What context this tool creates - **Using Context**: How to reference generated context in future sessions - **Context Location**: Where to find the context document --- #### 4.3 LLM Integration Examples **For Gemini** (limited context): ``` System instructions: "Before generating ADRs or deployment plans, always check for and read: 1. docs/context/bootstrap/latest.md - For platform and deployment context 2. docs/context/environment/latest.md - For environment configuration 3. docs/context/research/latest.md - For research findings These context documents contain project-specific validated patterns and decisions." ``` **For Claude** (via CLAUDE.md): ```markdown ## Tool Context Documents This project uses tool context documents to preserve execution results and decisions. **Location**: `docs/context/` **Key Documents**: - `docs/context/bootstrap/latest.md` - Latest bootstrap/deployment context - `docs/context/environment/latest.md` - Environment analysis - `docs/context/research/latest.md` - Research findings **Usage**: When starting a new session related to deployment, architecture, or infrastructure: 1. Read the relevant latest.md file in docs/context/ 2. Use the context to inform decisions and maintain consistency 3. Reference specific decisions and validated patterns from context docs ``` --- ### Phase 5: Cleanup & Maintenance (Week 5) #### 5.1 Create Cleanup Script **File**: `src/scripts/cleanup-context-docs.ts` ```typescript // Prune old context documents based on retention policy // Keep last 10 per category, archive older ones ``` **CLI Command**: ```bash npm run cleanup:context ``` --- #### 5.2 Add to CI/CD **.github/workflows/context-cleanup.yml**: ```yaml name: Context Document Cleanup on: schedule: - cron: '0 0 * * 0' # Weekly on Sunday workflow_dispatch: jobs: cleanup: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Setup Node uses: actions/setup-node@v3 - name: Install dependencies run: npm ci - name: Cleanup old contexts run: npm run cleanup:context - name: Commit changes run: | git config user.name "github-actions" git config user.email "github-actions@github.com" git add docs/context/ git commit -m "chore: cleanup old context documents" || echo "No changes" git push ``` --- ## Usage Patterns for Developers ### Pattern 1: Starting New Session with Context **Scenario**: Developer wants to continue deployment after a week **Without Context**: ``` User: "Continue the OpenShift deployment" LLM: "Let me detect your platform and analyze your project..." [Re-runs detection, re-researches, loses previous decisions] ``` **With Context**: ``` User: "Using the context from docs/context/bootstrap/latest.md, continue the OpenShift deployment" LLM: [Reads context] "I see from the bootstrap context that: - Platform: OpenShift (95% confidence) - Validated pattern: Multicluster GitOps v2.0 - Bootstrap ADR: docs/adrs/bootstrap-deployment-1234.md - Last execution: Phase 2 complete, Phase 3 pending Continuing with Phase 3: Deployment Validation..." ``` --- ### Pattern 2: Onboarding New Team Member **Scenario**: New developer joins the project **Onboarding Steps**: 1. Read `docs/context/README.md` - Understanding context system 2. Read `docs/context/bootstrap/latest.md` - Current deployment approach 3. Read `docs/context/environment/latest.md` - Environment setup 4. Read relevant ADRs linked in context docs **Value**: New developer understands project-specific patterns and decisions quickly without re-discovering them. --- ### Pattern 3: CI/CD Pipeline Consistency **Scenario**: CI/CD pipeline needs to deploy consistently **.github/workflows/deploy.yml**: ```yaml - name: Generate Deployment Context run: | # Use bootstrap tool to generate/update context echo "Using context from docs/context/bootstrap/latest.md" - name: Deploy using Validated Pattern run: | # Reference context for deployment parameters ./bootstrap.sh ``` **Value**: Pipeline uses the same validated pattern and configuration across runs. --- ### Pattern 4: Troubleshooting with Historical Context **Scenario**: Deployment failed, need to understand what changed **Troubleshooting**: ```bash # Compare current context with previous successful deployment diff docs/context/bootstrap/latest.md \ docs/context/bootstrap/bootstrap-openshift-20250115.md # Identify what changed between successful and failed deployment ``` --- ## Benefits ### For Developers - ✅ **Faster onboarding** - Context docs provide project-specific knowledge - ✅ **Consistent decisions** - Reference previous validated patterns - ✅ **Reduced re-work** - Avoid re-discovering platform, environment, configs - ✅ **Better troubleshooting** - Historical context for debugging ### For LLMs - ✅ **Context preservation** - Overcome limited context windows - ✅ **Decision consistency** - Maintain architectural alignment across sessions - ✅ **Reduced hallucination** - Ground decisions in documented context - ✅ **Faster execution** - Skip re-analysis, use cached research ### For Teams - ✅ **Knowledge sharing** - Context docs are team knowledge base - ✅ **Audit trail** - Historical decisions and their rationale - ✅ **Compliance** - Document deployment decisions for governance - ✅ **Collaboration** - Shared understanding of project state --- ## Success Metrics ### Quantitative - **Context Reuse Rate**: % of sessions that reference existing context docs - **Time to Deploy**: Reduction in deployment time with context vs without - **Research Cache Hit Rate**: % of research questions answered from context - **LLM Token Usage**: Reduction in tokens used (less re-analysis) ### Qualitative - **Developer Satisfaction**: Easier to resume work across sessions - **Decision Consistency**: Fewer conflicting architectural decisions - **Onboarding Speed**: Faster for new team members - **Troubleshooting Efficiency**: Easier debugging with historical context --- ## Future Enhancements ### Version 2.0 - **Semantic Search**: Search across all context documents by topic/keyword - **Context Diff**: Visual diff tool for comparing contexts - **Context Validation**: Ensure context docs match current project state - **Auto-expiration**: Smart cleanup based on relevance, not just age ### Version 3.0 - **Context Graph**: Relationship graph between context docs, ADRs, code - **AI-Powered Summarization**: Auto-generate context summaries - **Context Recommendations**: Suggest relevant context docs for current task - **Cross-Project Context**: Share validated patterns across multiple projects --- ## Appendix: Example Context Document ### Bootstrap Context Example **File**: `docs/context/bootstrap/bootstrap-openshift-20250119T143022.md` ```markdown # Tool Context: Bootstrap Validation Loop > **Generated**: 2025-01-19T14:30:22.123Z > **Tool Version**: 1.0.0 > **Project**: mcp-adr-analysis-server ## Quick Reference Detected **OpenShift** (95% confidence) as deployment platform. Using validated pattern: **Multicluster GitOps** v2.0 from Red Hat Validated Patterns. Bootstrap ADR created: `docs/adrs/bootstrap-deployment-1705759822.md` **Next Steps**: Review bootstrap ADR, then run `./bootstrap.sh` to deploy. ## Execution Summary - **Status**: Success - **Confidence**: 95% - **Key Findings**: - Primary platform: openshift - Validated pattern: Multicluster GitOps - Required files: 12 - Deployment steps: 7 ## Detected Context ### Platform/Environment - **Primary**: openshift - **All Detected**: openshift, kubernetes, ansible, helm - **Confidence**: 95% - **Evidence**: - `values-global.yaml` (OpenShift Validated Patterns config) - weight: 90% - `.github/workflows/validate-origin.yaml` (GitOps validation) - weight: 80% - `charts/` directory (Helm charts) - weight: 70% ### Validated Pattern - **Name**: Multicluster GitOps - **Version**: 2.0 - **Platform**: OpenShift - **Base Repository**: https://github.com/validatedpatterns/multicloud-gitops - **Documentation**: https://validatedpatterns.io/patterns/multicloud-gitops/ - **Authoritative Sources**: - Documentation: https://validatedpatterns.io/patterns/multicloud-gitops/ (required) - Base Code: https://github.com/validatedpatterns/multicloud-gitops (required) - Framework Guide: https://validatedpatterns.io/learn/vp_openshift_framework/ (required) ### Deployment Plan - **Recommended Platform**: openshift - **Confidence**: high - **Source**: validated-pattern - **Required Files**: 12 - `values-global.yaml` (Global Helm values) - `values-hub.yaml` (Hub cluster config) - `.vault/` (HashiCorp Vault secrets) - `charts/` (Helm charts) - **Environment Variables**: 5 - `KUBECONFIG` (required, path to kubeconfig) - `VAULT_ADDR` (optional, Vault server URL) - **Estimated Duration**: 20-30 minutes ## Generated Artifacts - `docs/adrs/bootstrap-deployment-1705759822.md` (Bootstrap ADR) - `bootstrap.sh` (Deployment script) - `validate_bootstrap.sh` (Validation script) ## Key Decisions ### 1. Use OpenShift as Deployment Platform - **Rationale**: Detected with 95% confidence based on `values-global.yaml` (OpenShift Validated Patterns configuration) and GitOps workflow files - **Alternatives Considered**: - Kubernetes (70% confidence, but OpenShift-specific files present) - Docker Compose (30% confidence, not suitable for this architecture) ### 2. Use Multicluster GitOps Validated Pattern - **Rationale**: Best practice pattern from Red Hat for multi-cluster OpenShift deployments. Provides proven deployment workflow, GitOps automation, and HashiCorp Vault integration. - **Pattern Features**: - Multi-cluster management - GitOps-based deployment - HashiCorp Vault for secrets - ArgoCD for continuous deployment ## Usage in Future Sessions ### How to Reference This Context **For LLMs (Claude, Gemini, GPT-4)**: ``` "Using the bootstrap context from docs/context/bootstrap/latest.md, continue the OpenShift deployment to Phase 3: Validation" ```` **For Developers**: ```bash # Check what was detected cat docs/context/bootstrap/latest.md # Reference in CI/CD echo "Deploying using: $(grep 'Primary platform' docs/context/bootstrap/latest.md)" ```` ### Related Documents - **ADRs**: - `docs/adrs/bootstrap-deployment-1705759822.md` (Deployment plan) - **Configs**: - `values-global.yaml` - `values-hub.yaml` - **Other Contexts**: - `docs/context/environment/latest.md` (Environment analysis) --- _Auto-generated by bootstrap_validation_loop v1.0.0_ ``` --- ## Next Steps 1. **Review this plan** with the team 2. **Prioritize tools** to integrate first (bootstrap recommended) 3. **Implement Phase 1** (Core Infrastructure) 4. **Test with bootstrap tool** integration 5. **Iterate** based on usage feedback 6. **Roll out** to other tools progressively **Estimated Timeline**: 4-5 weeks for full implementation --- *This plan is a living document. Update as implementation progresses and requirements evolve.* ```