docs: add project specs and documentation for Modbus relay control

Initialize project documentation structure:
- Add CLAUDE.md with development guidelines and architecture principles
- Add project constitution (v1.1.0) with hexagonal architecture and SOLID principles
- Add MCP server configuration for Context7 integration

Feature specification (001-modbus-relay-control):
- Complete feature spec for web-based Modbus relay control system
- Implementation plan with TDD approach using SQLx for persistence
- Type-driven development design for domain types
- Technical decisions document (SQLx over rusqlite, SQLite persistence)
- Detailed task breakdown (94 tasks across 8 phases)
- Specification templates for future features

Documentation:
- Modbus POE ETH Relay hardware documentation
- Modbus Application Protocol specification (PDF)

Project uses SQLx for compile-time verified SQL queries, aligned with
type-driven development principles.

specs/001-modbus-relay-control/spec-checklist.md

@@ -0,0 +1,51 @@
+# Specification Quality Checklist: Modbus Relay Control System
+
+**Purpose**: Validate specification completeness and quality before proceeding to planning
+**Created**: 2025-12-28
+**Feature**: [spec.md](./spec.md)
+
+## Content Quality
+
+- [x] No implementation details (languages, frameworks, APIs)
+  - **Note**: Specification intentionally includes some implementation constraints (Rust, Poem, tokio-modbus) per project constitution requirements (NFR-009, NFR-014, NFR-015). These are architectural constraints, not implementation details of business logic.
+- [x] Focused on user value and business needs
+- [x] Written for non-technical stakeholders
+- [x] All mandatory sections completed
+
+## Requirement Completeness
+
+- [x] No [NEEDS CLARIFICATION] markers remain
+  - **Resolution**: FR-023 clarified by user - backend starts successfully even when device unhealthy, frontend displays error as part of Health story
+- [x] Requirements are testable and unambiguous
+- [x] Success criteria are measurable
+- [x] Success criteria are technology-agnostic (no implementation details)
+  - **Note**: SC-010 references cargo tarpaulin as measurement tool, which is acceptable for NFR validation
+- [x] All acceptance scenarios are defined
+- [x] Edge cases are identified
+- [x] Scope is clearly bounded
+- [x] Dependencies and assumptions identified
+
+## Feature Readiness
+
+- [x] All functional requirements have clear acceptance criteria
+- [x] User scenarios cover primary flows
+- [x] Feature meets measurable outcomes defined in Success Criteria
+- [x] No implementation details leak into specification
+
+## Quality Assessment
+
+**Overall Status**: ✅ **READY FOR PLANNING**
+
+### Strengths
+- Comprehensive coverage of 5 prioritized, independently testable user stories
+- 37 functional + 21 non-functional requirements provide clear scope
+- Edge cases thoroughly documented with specific mitigation strategies
+- Success criteria are measurable and aligned with user stories
+- Clear boundaries with explicit "Out of Scope" section
+- Risk matrix identifies key concerns with mitigation approaches
+
+### Notes
+- Specification includes architectural constraints (hexagonal architecture, TDD, TyDD) per project constitution
+- These constraints are non-negotiable project requirements, not arbitrary implementation details
+- User clarification resolved FR-023 regarding startup behavior when device is unhealthy
+- Specification ready for `/sdd:02-plan` stage