chore: add spec-kit and standardize signatures

- Added GitHub spec-kit for development workflow
- Standardized file signatures to Descomplicar® format
- Updated development configuration

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

specs/001-care-api-sistema/research.md

@@ -0,0 +1,130 @@
+# Phase 0 Research: Care API System
+
+**Feature**: Care API - Sistema de gestão de cuidados de saúde  
+**Date**: 2025-09-12  
+**Status**: Complete
+
+## Research Summary
+
+All technical requirements have been clearly specified in the detailed KiviCare integration specifications provided. No unknowns remain from the Technical Context analysis.
+
+## WordPress REST API Framework
+
+**Decision**: WordPress REST API with custom endpoints via register_rest_route()
+**Rationale**: 
+- Native WordPress integration ensuring compatibility
+- Built-in authentication and permission handling
+- Standardized HTTP methods and response formats
+- Existing KiviCare plugin integration points
+
+**Alternatives considered**:
+- Custom API framework: Rejected due to WordPress ecosystem requirements
+- GraphQL implementation: Rejected due to REST API simplicity and WordPress standards
+
+## JWT Authentication for WordPress
+
+**Decision**: WordPress JWT Authentication plugin with custom role-based permissions
+**Rationale**:
+- Stateless authentication suitable for API consumption
+- Integrates with existing WordPress user system (wp_users)
+- Supports custom role definitions (administrator, doctor, patient, receptionist)
+- Token-based security for mobile/web app integration
+
+**Alternatives considered**:
+- WordPress cookies: Rejected due to cross-origin limitations
+- OAuth2: Over-engineered for single-plugin use case
+
+## KiviCare Database Integration
+
+**Decision**: Direct WordPress $wpdb queries with prepared statements
+**Rationale**:
+- Preserves existing KiviCare 35-table schema integrity
+- No additional ORM layer needed - WordPress provides secure database access
+- Maintains compatibility with existing KiviCare plugin operations
+- Performance optimized for medical data relationships
+
+**Alternatives considered**:
+- WordPress ORM plugins: Unnecessary complexity for established schema
+- Custom database layer: Would duplicate WordPress security features
+
+## Testing Framework
+
+**Decision**: PHPUnit with WordPress testing framework (WP_UnitTestCase)
+**Rationale**:
+- Standard WordPress plugin testing approach
+- Provides database setup/teardown for integration tests
+- Mocks WordPress environment for isolated testing
+- Compatible with continuous integration workflows
+
+**Alternatives considered**:
+- Standalone PHPUnit: Insufficient WordPress integration
+- Custom testing framework: Reinventing established tools
+
+## API Response Format
+
+**Decision**: JSON responses following WordPress REST API standards
+**Rationale**:
+- Consistent with WordPress ecosystem expectations
+- Standardized error codes and response structures
+- Built-in CORS handling for cross-origin requests
+- Cacheable response formats
+
+**Alternatives considered**:
+- XML responses: Outdated for modern applications
+- Custom formats: Would break client expectation standards
+
+## Performance and Caching
+
+**Decision**: WordPress Object Cache with Transients API
+**Rationale**:
+- Built-in WordPress caching mechanism
+- Configurable TTL for different data types
+- Compatible with Redis/Memcached backends
+- Automatic cache invalidation on data updates
+
+**Alternatives considered**:
+- Database-level caching: Limited control over cache invalidation
+- External caching services: Additional infrastructure complexity
+
+## Plugin Architecture
+
+**Decision**: WordPress plugin with modular endpoint classes
+**Rationale**:
+- Clear separation of concerns (endpoints, models, utilities)
+- Easy testing of individual components
+- Follows WordPress plugin development best practices
+- Maintainable codebase structure
+
+**Alternatives considered**:
+- Monolithic plugin file: Poor maintainability and testing
+- Multiple plugins: Unnecessary complexity for single API system
+
+## Error Handling and Logging
+
+**Decision**: WordPress WP_Error with structured logging to debug.log
+**Rationale**:
+- Standard WordPress error handling mechanism
+- Structured logging for operational monitoring
+- Integration with existing WordPress debugging tools
+- Configurable log levels for production/development
+
+**Alternatives considered**:
+- Custom exception handling: Would bypass WordPress standards
+- External logging services: Additional infrastructure dependency
+
+## Research Validation
+
+✅ **All technical decisions align with**:
+- WordPress development best practices
+- Healthcare data security requirements
+- KiviCare plugin compatibility
+- Performance and scalability goals
+- Testing and observability standards
+
+✅ **No remaining NEEDS CLARIFICATION items**
+✅ **All dependencies verified as available and compatible**
+✅ **Integration patterns established and documented**
+
+---
+
+**Phase 0 Complete**: Ready for Phase 1 Design & Contracts