docs: amend constitution to v1.1.1 (refine Ruby on Rails as full-stack) and create spec for 010-port-the-app

specs/010-port-the-app/checklists/requirements.md

@@ -0,0 +1,34 @@
+# Specification Quality Checklist: Port the app to Ruby on Rails
+
+**Purpose**: Validate specification completeness and quality before proceeding to planning
+**Created**: 2025-10-17
+**Feature**: ../../010-port-the-app/spec.md
+
+## Content Quality
+
+- [ ] No implementation details (languages, frameworks, APIs) - *FAIL: Mentions Ruby on Rails in several places. Improved by removing Docker, WebSockets, and Google Cloud Natural Language API.*
+- [x] Focused on user value and business needs
+- [ ] Written for non-technical stakeholders - *FAIL: Explicit mention of Ruby on Rails makes it less accessible.*
+- [x] All mandatory sections completed
+
+## Requirement Completeness
+
+- [x] No [NEEDS CLARIFICATION] markers remain
+- [x] Requirements are testable and unambiguous
+- [x] Success criteria are measurable
+- [ ] Success criteria are technology-agnostic (no implementation details) - *FAIL: SC-003 mentions Ruby on Rails application. Improved SC-001 and SC-004.*
+- [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
+- [ ] No implementation details leak into specification - *FAIL: Same as content quality and success criteria issues.*
+
+## Notes
+
+- Items marked incomplete require spec updates before `/speckit.clarify` or `/speckit.plan`

specs/010-port-the-app/spec.md

@@ -0,0 +1,56 @@
+# Feature Specification: Port the app to Ruby on Rails
+
+**Feature Branch**: `010-port-the-app`  
+**Created**: 2025-10-17  
+**Status**: Draft  
+**Input**: User description: "Port the app to Ruby on Rails, still run it in Docker"
+
+## User Scenarios & Testing *(mandatory)*
+
+### User Story 1 - Continued Application Functionality (Priority: P1)
+
+Users can continue to access and use all existing features of the application without interruption or change in behavior after the port to Ruby on Rails.
+
+**Why this priority**: This is the primary goal of the porting effort – to ensure business continuity and user satisfaction by maintaining all current functionalities.
+
+**Independent Test**: Can be fully tested by verifying all existing end-to-end user flows and features function correctly.
+
+**Acceptance Scenarios**:
+
+1.  **Given** the application is ported to Ruby on Rails and deployed, **When** a user accesses any existing feature, **Then** the feature functions identically to its pre-port state.
+2.  **Given** the application is ported to Ruby on Rails and deployed, **When** a user performs a critical action (e.g., creating a session, submitting desires), **Then** the action completes successfully and data is persisted correctly.
+
+### Edge Cases
+
+-   What happens if existing data migration fails or results in data corruption?
+-   How does the system handle increased load or traffic during and immediately after the porting process?
+-   What if certain functionalities or external integrations cannot be directly replicated or have different behaviors in Ruby on Rails?
+-   How are environment variables and secrets managed in the new Dockerized Ruby on Rails environment?
+
+## Requirements *(mandatory)*
+
+### Functional Requirements
+
+-   **FR-001**: The ported application MUST provide all existing functionalities available in the current version.
+    **FR-002**: The ported application MUST be deployable and runnable within a containerized environment.
+-   **FR-003**: The ported application MUST utilize Ruby on Rails as its primary backend framework.
+-   **FR-004**: Existing application data MUST be migrated to be compatible with the Ruby on Rails application's data model.
+-   **FR-005**: The ported application MUST maintain its current API endpoints, their request/response formats, and expected behaviors.
+    **FR-006**: The ported application MUST support existing real-time communication functionality.
+    **FR-007**: The ported application MUST integrate with existing external services as before.
+
+### Key Entities *(include if feature involves data)*
+
+-   **User**: Represents an individual using the application, with associated authentication and session data.
+-   **Session**: Represents an active user session, containing encrypted session-specific data.
+-   **Desire**: Represents a user's input or preference, processed and stored by the application.
+
+## Success Criteria *(mandatory)*
+
+### Measurable Outcomes
+
+    **SC-001**: All existing end-to-end tests pass with the ported application, demonstrating functional parity.
+-   **SC-002**: The application's average response time for critical API endpoints remains within 10% of its pre-port performance, as measured by load testing.
+-   **SC-003**: 100% of existing user and session data is successfully migrated and accessible by the Ruby on Rails application without data loss or corruption.
+    **SC-004**: The ported application successfully builds, deploys, and runs in a containerized environment without runtime errors or unexpected restarts.
+-   **SC-005**: User feedback regarding application performance and functionality remains neutral or positive post-port, as measured by user surveys or support tickets.