aios-core 2.1.0

package/.aios-core/product/checklists/database-design-checklist.md

@@ -0,0 +1,119 @@
+# Database Design Checklist
+
+## Instructions for Data Engineer Agent
+
+When designing a new database schema or reviewing significant changes, go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - DATABASE DESIGN VALIDATION
+
+This checklist is for DATA ENGINEER AGENTS validating database schema designs.
+
+IMPORTANT: Good database design prevents problems that are expensive to fix later. Take time to verify each item.
+
+EXECUTION APPROACH:
+
+1. Review the complete design before checking items
+2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
+3. Add comments explaining design decisions
+4. Flag potential issues or trade-offs
+5. Consider both current and future requirements
+
+Design for correctness first, then optimize.]]
+
+## Checklist Items
+
+1. **Domain Model Alignment:**
+
+   [[LLM: Schema should reflect business requirements]]
+
+   - [ ] All required entities from domain model are represented
+   - [ ] Entity relationships match business logic
+   - [ ] Cardinality (1:1, 1:N, M:N) correctly implemented
+   - [ ] Business rules can be enforced at database level
+   - [ ] Naming conventions are consistent and meaningful
+
+2. **Table Design:**
+
+   [[LLM: Tables are the foundation. Get them right]]
+
+   - [ ] Every table has a primary key (preferably UUID)
+   - [ ] created_at and updated_at timestamps on all tables
+   - [ ] Soft delete (deleted_at) where audit trail needed
+   - [ ] Appropriate data types chosen for each column
+   - [ ] Column names follow snake_case convention
+
+3. **Relationships & Constraints:**
+
+   [[LLM: Constraints protect data integrity]]
+
+   - [ ] Foreign keys defined for all relationships
+   - [ ] ON DELETE behavior specified (CASCADE, SET NULL, RESTRICT)
+   - [ ] Unique constraints on business keys
+   - [ ] CHECK constraints for value validation
+   - [ ] NOT NULL on required fields
+
+4. **Indexing Strategy:**
+
+   [[LLM: Indexes enable performance. Plan them carefully]]
+
+   - [ ] Primary key automatically indexed
+   - [ ] Foreign keys have indexes
+   - [ ] Frequently queried columns indexed
+   - [ ] Composite indexes for common query patterns
+   - [ ] No over-indexing (each index has justification)
+
+5. **Normalization & Denormalization:**
+
+   [[LLM: Balance normalization with practical needs]]
+
+   - [ ] At minimum 3NF (Third Normal Form) achieved
+   - [ ] Denormalization decisions documented with justification
+   - [ ] No data redundancy without explicit reason
+   - [ ] Update anomalies prevented
+   - [ ] Delete anomalies prevented
+
+6. **Security Design:**
+
+   [[LLM: Security must be built in, not bolted on]]
+
+   - [ ] Tables categorized by sensitivity level
+   - [ ] RLS policy strategy defined for each table
+   - [ ] Sensitive columns identified (PII, credentials)
+   - [ ] Audit logging requirements defined
+   - [ ] Access patterns documented
+
+7. **Performance Considerations:**
+
+   [[LLM: Design for expected scale and access patterns]]
+
+   - [ ] Expected data volumes estimated
+   - [ ] Query patterns identified and optimized for
+   - [ ] Partitioning strategy considered (if large tables)
+   - [ ] Archival strategy for old data considered
+   - [ ] Read/write ratio considered
+
+8. **Documentation:**
+
+   [[LLM: Others need to understand your design]]
+
+   - [ ] Entity-Relationship Diagram (ERD) created
+   - [ ] Each table purpose documented
+   - [ ] Complex relationships explained
+   - [ ] Design decisions recorded
+   - [ ] COMMENT ON planned for production schema
+
+## Final Confirmation
+
+[[LLM: FINAL DESIGN REVIEW SUMMARY
+
+After completing the checklist:
+
+1. Summarize the database design
+2. List any items marked as [ ] Not Done with explanations
+3. Document known trade-offs and their rationale
+4. Identify areas that may need future attention
+5. Confirm design is ready for implementation
+
+Good design is the foundation of reliable systems.]]
+
+- [ ] I, the Data Engineer Agent, confirm that this database design has been thoroughly reviewed and is ready for implementation.

package/.aios-core/product/checklists/dba-predeploy-checklist.md

@@ -0,0 +1,97 @@
+# DBA Pre-Deploy Checklist
+
+## Instructions for Data Engineer Agent
+
+Before deploying database changes to production, please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - DBA PRE-DEPLOY VALIDATION
+
+This checklist is for DATA ENGINEER AGENTS to validate database changes before production deployment.
+
+IMPORTANT: Database changes are often irreversible or costly to fix. This checklist ensures safe deployment.
+
+EXECUTION APPROACH:
+
+1. Go through each section systematically
+2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
+3. Add brief comments explaining any [ ] or [N/A] items
+4. Be specific about what was validated
+5. Flag any concerns or risks identified
+
+Production safety is paramount.]]
+
+## Checklist Items
+
+1. **Migration Validation:**
+
+   [[LLM: Migrations must be safe and reversible]]
+
+   - [ ] All migrations have been tested in development environment
+   - [ ] Migrations are idempotent (safe to run multiple times)
+   - [ ] Rollback scripts exist for all schema changes
+   - [ ] Migration order dependencies are documented
+   - [ ] No destructive operations without explicit safeguards
+
+2. **Schema Review:**
+
+   [[LLM: Schema changes can break applications. Verify carefully]]
+
+   - [ ] No breaking changes to existing APIs/tables
+   - [ ] Foreign key constraints are properly defined
+   - [ ] Indexes exist for all foreign keys and frequently queried columns
+   - [ ] NOT NULL constraints are appropriate
+   - [ ] Default values are set where needed
+
+3. **Security Review:**
+
+   [[LLM: Database security is critical. Check each item]]
+
+   - [ ] RLS policies are enabled on all user-facing tables
+   - [ ] RLS policies have been tested with positive and negative cases
+   - [ ] No sensitive data exposed without proper authorization
+   - [ ] SECURITY DEFINER functions are justified and safe
+   - [ ] No hardcoded credentials or secrets in migrations
+
+4. **Performance Review:**
+
+   [[LLM: Performance issues in production are costly. Validate]]
+
+   - [ ] Large table alterations have been planned for low-traffic periods
+   - [ ] New indexes have been tested for query performance
+   - [ ] No full table scans introduced on large tables
+   - [ ] EXPLAIN ANALYZE run on critical queries
+   - [ ] Connection pooling considerations addressed
+
+5. **Backup & Recovery:**
+
+   [[LLM: Always have a way back. Ensure recovery options]]
+
+   - [ ] Database snapshot created before deployment
+   - [ ] Rollback procedure documented and tested
+   - [ ] Recovery time estimate documented
+   - [ ] Data backup verified and accessible
+
+6. **Documentation:**
+
+   [[LLM: Future DBAs need to understand what changed]]
+
+   - [ ] COMMENT ON statements added for new tables/columns
+   - [ ] Migration notes document the purpose of changes
+   - [ ] Breaking changes communicated to development team
+   - [ ] Changelog updated with database changes
+
+## Final Confirmation
+
+[[LLM: FINAL PRE-DEPLOY SUMMARY
+
+After completing the checklist:
+
+1. Summarize database changes being deployed
+2. List any items marked as [ ] Not Done with explanations
+3. Identify risks and mitigation strategies
+4. Confirm rollback procedure is ready
+5. Confirm whether deployment should proceed
+
+Production database changes require confidence.]]
+
+- [ ] I, the Data Engineer Agent, confirm that all applicable items above have been addressed and deployment is safe to proceed.

package/.aios-core/product/checklists/dba-rollback-checklist.md

@@ -0,0 +1,99 @@
+# DBA Rollback Checklist
+
+## Instructions for Data Engineer Agent
+
+When a database rollback is needed, go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - DBA ROLLBACK EXECUTION
+
+This checklist is for DATA ENGINEER AGENTS executing database rollbacks.
+
+IMPORTANT: Rollbacks must be executed carefully to avoid data loss. Follow this checklist precisely.
+
+EXECUTION APPROACH:
+
+1. Remain calm - hasty rollbacks cause more problems
+2. Go through each section in order
+3. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
+4. Document everything for post-mortem analysis
+5. Communicate status to stakeholders
+
+Controlled rollback is better than panic.]]
+
+## Checklist Items
+
+1. **Situation Assessment:**
+
+   [[LLM: Understand the problem before acting]]
+
+   - [ ] Issue clearly identified and documented
+   - [ ] Impact assessment completed (affected users, data, features)
+   - [ ] Decision to rollback confirmed by appropriate stakeholder
+   - [ ] Current database state captured (snapshot if possible)
+   - [ ] Affected migration(s) identified
+
+2. **Pre-Rollback Preparation:**
+
+   [[LLM: Prepare before executing any rollback]]
+
+   - [ ] Rollback script(s) located and reviewed
+   - [ ] Dependencies between migrations understood
+   - [ ] Application instances notified or stopped (if needed)
+   - [ ] Maintenance mode enabled (if available)
+   - [ ] Team members notified of rollback in progress
+
+3. **Rollback Execution:**
+
+   [[LLM: Execute carefully and monitor]]
+
+   - [ ] Database connection established with appropriate privileges
+   - [ ] Transaction started for rollback operations
+   - [ ] Rollback script executed
+   - [ ] No errors during execution
+   - [ ] Transaction committed (or rolled back if errors)
+
+4. **Post-Rollback Validation:**
+
+   [[LLM: Verify the rollback was successful]]
+
+   - [ ] Schema state matches expected pre-migration state
+   - [ ] Application functionality restored
+   - [ ] No data corruption detected
+   - [ ] RLS policies functioning correctly
+   - [ ] Critical queries performing as expected
+
+5. **Recovery & Communication:**
+
+   [[LLM: Complete the recovery process]]
+
+   - [ ] Application instances restarted (if stopped)
+   - [ ] Maintenance mode disabled
+   - [ ] Stakeholders notified of rollback completion
+   - [ ] End users notified (if necessary)
+   - [ ] Monitoring confirmed normal operations
+
+6. **Documentation & Post-Mortem:**
+
+   [[LLM: Learn from this incident]]
+
+   - [ ] Incident timeline documented
+   - [ ] Root cause identified (if known)
+   - [ ] Rollback procedure effectiveness noted
+   - [ ] Improvements for future rollbacks documented
+   - [ ] Post-mortem meeting scheduled (if significant incident)
+
+## Final Confirmation
+
+[[LLM: FINAL ROLLBACK SUMMARY
+
+After completing the checklist:
+
+1. Summarize what was rolled back and why
+2. Confirm current database state is stable
+3. Document any data impact
+4. Identify follow-up actions needed
+5. Confirm system is operational
+
+Document everything for future reference.]]
+
+- [ ] I, the Data Engineer Agent, confirm that the rollback has been completed successfully and the system is stable.

package/.aios-core/product/checklists/pm-checklist.md

@@ -0,0 +1,376 @@
+# Product Manager (PM) Requirements Checklist
+
+This checklist serves as a comprehensive framework to ensure the Product Requirements Document (PRD) and Epic definitions are complete, well-structured, and appropriately scoped for MVP development. The PM should systematically work through each item during the product definition process.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - PM CHECKLIST
+
+Before proceeding with this checklist, ensure you have access to:
+
+1. prd.md - The Product Requirements Document (check docs/prd.md)
+2. Any user research, market analysis, or competitive analysis documents
+3. Business goals and strategy documents
+4. Any existing epic definitions or user stories
+
+IMPORTANT: If the PRD is missing, immediately ask the user for its location or content before proceeding.
+
+VALIDATION APPROACH:
+
+1. User-Centric - Every requirement should tie back to user value
+2. MVP Focus - Ensure scope is truly minimal while viable
+3. Clarity - Requirements should be unambiguous and testable
+4. Completeness - All aspects of the product vision are covered
+5. Feasibility - Requirements are technically achievable
+
+EXECUTION MODE:
+Ask the user if they want to work through the checklist:
+
+- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
+- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
+
+## 1. PROBLEM DEFINITION & CONTEXT
+
+[[LLM: The foundation of any product is a clear problem statement. As you review this section:
+
+1. Verify the problem is real and worth solving
+2. Check that the target audience is specific, not "everyone"
+3. Ensure success metrics are measurable, not vague aspirations
+4. Look for evidence of user research, not just assumptions
+5. Confirm the problem-solution fit is logical]]
+
+### 1.1 Problem Statement
+
+- [ ] Clear articulation of the problem being solved
+- [ ] Identification of who experiences the problem
+- [ ] Explanation of why solving this problem matters
+- [ ] Quantification of problem impact (if possible)
+- [ ] Differentiation from existing solutions
+
+### 1.2 Business Goals & Success Metrics
+
+- [ ] Specific, measurable business objectives defined
+- [ ] Clear success metrics and KPIs established
+- [ ] Metrics are tied to user and business value
+- [ ] Baseline measurements identified (if applicable)
+- [ ] Timeframe for achieving goals specified
+
+### 1.3 User Research & Insights
+
+- [ ] Target user personas clearly defined
+- [ ] User needs and pain points documented
+- [ ] User research findings summarized (if available)
+- [ ] Competitive analysis included
+- [ ] Market context provided
+
+## 2. MVP SCOPE DEFINITION
+
+[[LLM: MVP scope is critical - too much and you waste resources, too little and you can't validate. Check:
+
+1. Is this truly minimal? Challenge every feature
+2. Does each feature directly address the core problem?
+3. Are "nice-to-haves" clearly separated from "must-haves"?
+4. Is the rationale for inclusion/exclusion documented?
+5. Can you ship this in the target timeframe?]]
+
+### 2.1 Core Functionality
+
+- [ ] Essential features clearly distinguished from nice-to-haves
+- [ ] Features directly address defined problem statement
+- [ ] Each Epic ties back to specific user needs
+- [ ] Features and Stories are described from user perspective
+- [ ] Minimum requirements for success defined
+
+### 2.2 Scope Boundaries
+
+- [ ] Clear articulation of what is OUT of scope
+- [ ] Future enhancements section included
+- [ ] Rationale for scope decisions documented
+- [ ] MVP minimizes functionality while maximizing learning
+- [ ] Scope has been reviewed and refined multiple times
+
+### 2.3 MVP Validation Approach
+
+- [ ] Method for testing MVP success defined
+- [ ] Initial user feedback mechanisms planned
+- [ ] Criteria for moving beyond MVP specified
+- [ ] Learning goals for MVP articulated
+- [ ] Timeline expectations set
+
+## 3. USER EXPERIENCE REQUIREMENTS
+
+[[LLM: UX requirements bridge user needs and technical implementation. Validate:
+
+1. User flows cover the primary use cases completely
+2. Edge cases are identified (even if deferred)
+3. Accessibility isn't an afterthought
+4. Performance expectations are realistic
+5. Error states and recovery are planned]]
+
+### 3.1 User Journeys & Flows
+
+- [ ] Primary user flows documented
+- [ ] Entry and exit points for each flow identified
+- [ ] Decision points and branches mapped
+- [ ] Critical path highlighted
+- [ ] Edge cases considered
+
+### 3.2 Usability Requirements
+
+- [ ] Accessibility considerations documented
+- [ ] Platform/device compatibility specified
+- [ ] Performance expectations from user perspective defined
+- [ ] Error handling and recovery approaches outlined
+- [ ] User feedback mechanisms identified
+
+### 3.3 UI Requirements
+
+- [ ] Information architecture outlined
+- [ ] Critical UI components identified
+- [ ] Visual design guidelines referenced (if applicable)
+- [ ] Content requirements specified
+- [ ] High-level navigation structure defined
+
+## 4. FUNCTIONAL REQUIREMENTS
+
+[[LLM: Functional requirements must be clear enough for implementation. Check:
+
+1. Requirements focus on WHAT not HOW (no implementation details)
+2. Each requirement is testable (how would QA verify it?)
+3. Dependencies are explicit (what needs to be built first?)
+4. Requirements use consistent terminology
+5. Complex features are broken into manageable pieces]]
+
+### 4.1 Feature Completeness
+
+- [ ] All required features for MVP documented
+- [ ] Features have clear, user-focused descriptions
+- [ ] Feature priority/criticality indicated
+- [ ] Requirements are testable and verifiable
+- [ ] Dependencies between features identified
+
+### 4.2 Requirements Quality
+
+- [ ] Requirements are specific and unambiguous
+- [ ] Requirements focus on WHAT not HOW
+- [ ] Requirements use consistent terminology
+- [ ] Complex requirements broken into simpler parts
+- [ ] Technical jargon minimized or explained
+
+### 4.3 User Stories & Acceptance Criteria
+
+- [ ] Stories follow consistent format
+- [ ] Acceptance criteria are testable
+- [ ] Stories are sized appropriately (not too large)
+- [ ] Stories are independent where possible
+- [ ] Stories include necessary context
+- [ ] Local testability requirements (e.g., via CLI) defined in ACs for relevant backend/data stories
+
+## 5. NON-FUNCTIONAL REQUIREMENTS
+
+### 5.1 Performance Requirements
+
+- [ ] Response time expectations defined
+- [ ] Throughput/capacity requirements specified
+- [ ] Scalability needs documented
+- [ ] Resource utilization constraints identified
+- [ ] Load handling expectations set
+
+### 5.2 Security & Compliance
+
+- [ ] Data protection requirements specified
+- [ ] Authentication/authorization needs defined
+- [ ] Compliance requirements documented
+- [ ] Security testing requirements outlined
+- [ ] Privacy considerations addressed
+
+### 5.3 Reliability & Resilience
+
+- [ ] Availability requirements defined
+- [ ] Backup and recovery needs documented
+- [ ] Fault tolerance expectations set
+- [ ] Error handling requirements specified
+- [ ] Maintenance and support considerations included
+
+### 5.4 Technical Constraints
+
+- [ ] Platform/technology constraints documented
+- [ ] Integration requirements outlined
+- [ ] Third-party service dependencies identified
+- [ ] Infrastructure requirements specified
+- [ ] Development environment needs identified
+
+## 6. EPIC & STORY STRUCTURE
+
+### 6.1 Epic Definition
+
+- [ ] Epics represent cohesive units of functionality
+- [ ] Epics focus on user/business value delivery
+- [ ] Epic goals clearly articulated
+- [ ] Epics are sized appropriately for incremental delivery
+- [ ] Epic sequence and dependencies identified
+
+### 6.2 Story Breakdown
+
+- [ ] Stories are broken down to appropriate size
+- [ ] Stories have clear, independent value
+- [ ] Stories include appropriate acceptance criteria
+- [ ] Story dependencies and sequence documented
+- [ ] Stories aligned with epic goals
+
+### 6.3 First Epic Completeness
+
+- [ ] First epic includes all necessary setup steps
+- [ ] Project scaffolding and initialization addressed
+- [ ] Core infrastructure setup included
+- [ ] Development environment setup addressed
+- [ ] Local testability established early
+
+## 7. TECHNICAL GUIDANCE
+
+### 7.1 Architecture Guidance
+
+- [ ] Initial architecture direction provided
+- [ ] Technical constraints clearly communicated
+- [ ] Integration points identified
+- [ ] Performance considerations highlighted
+- [ ] Security requirements articulated
+- [ ] Known areas of high complexity or technical risk flagged for architectural deep-dive
+
+### 7.2 Technical Decision Framework
+
+- [ ] Decision criteria for technical choices provided
+- [ ] Trade-offs articulated for key decisions
+- [ ] Rationale for selecting primary approach over considered alternatives documented (for key design/feature choices)
+- [ ] Non-negotiable technical requirements highlighted
+- [ ] Areas requiring technical investigation identified
+- [ ] Guidance on technical debt approach provided
+
+### 7.3 Implementation Considerations
+
+- [ ] Development approach guidance provided
+- [ ] Testing requirements articulated
+- [ ] Deployment expectations set
+- [ ] Monitoring needs identified
+- [ ] Documentation requirements specified
+
+## 8. CROSS-FUNCTIONAL REQUIREMENTS
+
+### 8.1 Data Requirements
+
+- [ ] Data entities and relationships identified
+- [ ] Data storage requirements specified
+- [ ] Data quality requirements defined
+- [ ] Data retention policies identified
+- [ ] Data migration needs addressed (if applicable)
+- [ ] Schema changes planned iteratively, tied to stories requiring them
+
+### 8.2 Integration Requirements
+
+- [ ] External system integrations identified
+- [ ] API requirements documented
+- [ ] Authentication for integrations specified
+- [ ] Data exchange formats defined
+- [ ] Integration testing requirements outlined
+
+### 8.3 Operational Requirements
+
+- [ ] Deployment frequency expectations set
+- [ ] Environment requirements defined
+- [ ] Monitoring and alerting needs identified
+- [ ] Support requirements documented
+- [ ] Performance monitoring approach specified
+
+## 9. CLARITY & COMMUNICATION
+
+### 9.1 Documentation Quality
+
+- [ ] Documents use clear, consistent language
+- [ ] Documents are well-structured and organized
+- [ ] Technical terms are defined where necessary
+- [ ] Diagrams/visuals included where helpful
+- [ ] Documentation is versioned appropriately
+
+### 9.2 Stakeholder Alignment
+
+- [ ] Key stakeholders identified
+- [ ] Stakeholder input incorporated
+- [ ] Potential areas of disagreement addressed
+- [ ] Communication plan for updates established
+- [ ] Approval process defined
+
+## PRD & EPIC VALIDATION SUMMARY
+
+[[LLM: FINAL PM CHECKLIST REPORT GENERATION
+
+Create a comprehensive validation report that includes:
+
+1. Executive Summary
+
+   - Overall PRD completeness (percentage)
+   - MVP scope appropriateness (Too Large/Just Right/Too Small)
+   - Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
+   - Most critical gaps or concerns
+
+2. Category Analysis Table
+   Fill in the actual table with:
+
+   - Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
+   - Critical Issues: Specific problems that block progress
+
+3. Top Issues by Priority
+
+   - BLOCKERS: Must fix before architect can proceed
+   - HIGH: Should fix for quality
+   - MEDIUM: Would improve clarity
+   - LOW: Nice to have
+
+4. MVP Scope Assessment
+
+   - Features that might be cut for true MVP
+   - Missing features that are essential
+   - Complexity concerns
+   - Timeline realism
+
+5. Technical Readiness
+
+   - Clarity of technical constraints
+   - Identified technical risks
+   - Areas needing architect investigation
+
+6. Recommendations
+   - Specific actions to address each blocker
+   - Suggested improvements
+   - Next steps
+
+After presenting the report, ask if the user wants:
+
+- Detailed analysis of any failed sections
+- Suggestions for improving specific areas
+- Help with refining MVP scope]]
+
+### Category Statuses
+
+| Category                         | Status | Critical Issues |
+| -------------------------------- | ------ | --------------- |
+| 1. Problem Definition & Context  | _TBD_  |                 |
+| 2. MVP Scope Definition          | _TBD_  |                 |
+| 3. User Experience Requirements  | _TBD_  |                 |
+| 4. Functional Requirements       | _TBD_  |                 |
+| 5. Non-Functional Requirements   | _TBD_  |                 |
+| 6. Epic & Story Structure        | _TBD_  |                 |
+| 7. Technical Guidance            | _TBD_  |                 |
+| 8. Cross-Functional Requirements | _TBD_  |                 |
+| 9. Clarity & Communication       | _TBD_  |                 |
+
+### Critical Deficiencies
+
+(To be populated during validation)
+
+### Recommendations
+
+(To be populated during validation)
+
+### Final Decision
+
+- **READY FOR ARCHITECT**: The PRD and epics are comprehensive, properly structured, and ready for architectural design.
+- **NEEDS REFINEMENT**: The requirements documentation requires additional work to address the identified deficiencies.
+