Defer Phase 6 (User Story 4) for POC - Manual YAML management

Updated specifications to reflect that User Story 4 (Product/Service
Registration and Management) is out of scope for the proof-of-concept.
Admin UI for product/user management is deferred in favor of manual
YAML file editing.

Specification Updates:

spec.md:
- Marked User Story 4 as [DEFERRED FOR POC]
- Added rationale: Manual management sufficient for POC
- Added manual management approach documentation
- Preserved original requirements (strikethrough) for future reference
- Updated FR-045 to FR-054 to indicate DEFERRED or IMPLEMENTED status
- Clarified which features work via YAML vs need admin UI

plan.md:
- Added POC Scope Update note in Summary section
- Documented that User Stories 1-3 are IMPLEMENTED
- Explained User Story 4 deferral and manual management approach
- Preserved original plan structure for future reference

tasks.md:
- Marked Phase 6 header as [DEFERRED FOR POC]
- Added comprehensive rationale and manual management guide
- Documented what's already implemented (models, access control)
- Listed manual operations: create product, edit product, create user, etc.
- Clarified that underlying features work, only admin UI is deferred
- Preserved all T140-T192 tasks for future implementation
- Added "Future Consideration" note

Rationale:
For a proof-of-concept, the admin UI adds no validation value. The core
functionality (anonymous submission, AI analysis, dashboard access) is
fully implemented and testable. Products and users can be managed via
YAML files:
- Products: data/products/{id}/config.yaml
- Users: data/users.yaml (with bcrypt passwords)

What Works Without Admin UI:
✅ Multi-product support (Product model + access control)
✅ Product owner assignment (via users.yaml product_ids field)
✅ Unique submission URLs per product (submission_url_slug)
✅ Archived product blocking (checked in submission route)
✅ Role-based access (owners see assigned, admins see all)

Decision Benefits:
- Reduces POC scope to essential features
- Eliminates ~53 admin UI tasks (T140-T192)
- Maintains all core product/user functionality
- Enables faster POC validation
- Can be implemented later if scaling is needed

Next Steps:
Focus on Phase 7 (Polish) - production hardening, documentation,
performance verification, and deployment readiness.

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

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

specs/001-build-an-application/plan.md

@@ -9,6 +9,8 @@
 
 Build a minimal web application using Flask that enables anonymous feedback submission with AI-powered analysis and translation. The system uses a file-based storage approach with folders for each submission, YAML metadata files, and markdown-formatted AI analysis reports. Product owners access analyzed feedback through an authenticated web dashboard. Design prioritizes simplicity and functionality over aesthetics - plain HTML without CSS frameworks or JavaScript libraries.
 
+**POC Scope Update (2025-10-17)**: User Story 4 (Product/Service Registration and Management) has been **deferred** for the proof-of-concept. Products and users will be managed manually via YAML configuration files (`data/products/{id}/config.yaml` and `data/users.yaml`). This decision removes admin UI complexity while maintaining full functionality for POC validation. User Stories 1-3 (Anonymous Submission, AI Analysis, Dashboard) remain in scope and are **IMPLEMENTED**.
+
 ## Technical Context
 
 **Language/Version**: Python 3.11+

specs/001-build-an-application/spec.md

@@ -70,23 +70,36 @@ As a product owner or responsible person for a product/service, I want to access
 
 ---
 
-### User Story 4 - Product/Service Registration and Management (Priority: P4)
+### User Story 4 - Product/Service Registration and Management ~~(Priority: P4)~~ **[DEFERRED FOR POC]**
 
-As a platform administrator, I want to register new products or services in the system and assign responsible persons (product owners) to them, so that feedback can be properly routed and access controlled.
+~~As a platform administrator, I want to register new products or services in the system and assign responsible persons (product owners) to them, so that feedback can be properly routed and access controlled.~~
 
-**Why this priority**: This is administrative infrastructure needed for multi-product support. It's lower priority because the MVP could work with a single hardcoded product. However, it's necessary for a scalable production system.
+**Status**: **DEFERRED** - Out of scope for POC. Products and users will be managed manually via YAML configuration files.
 
-**Independent Test**: Can be tested by logging in as an administrator, creating a new product/service entry with details (name, description, preferred language for translations), assigning one or more product owners to it, and verifying that the product appears in the system with a unique feedback submission URL and that assigned owners can access its feedback in their dashboards.
+**Rationale**: For a proof-of-concept, manual management of products and users through configuration files is sufficient. Building an admin UI for product/user management does not add value at this stage and can be implemented later if the POC proves successful and requires scaling.
 
-**Acceptance Scenarios**:
+**Manual Management Approach**:
+- Products: Edit `data/products/{product-id}/config.yaml` directly
+- Users: Edit `data/users.yaml` with bcrypt-hashed passwords
+- Product assignment: Update `product_ids` field in user records
 
-1. **Given** I am an administrator, **When** I create a new product entry with name, description, and preferred language for feedback translations, **Then** the product is registered and assigned a unique identifier
+**Original Requirements** (preserved for future reference):
-2. **Given** a product exists, **When** I assign a user as a product owner, **Then** that user gains access to view feedback for this product in their dashboard
+
-3. **Given** a product is registered, **When** I request the feedback submission URL, **Then** I receive a unique URL that end users can use to submit feedback for this specific product
+~~As a platform administrator, I want to register new products or services in the system and assign responsible persons (product owners) to them, so that feedback can be properly routed and access controlled.~~
-4. **Given** multiple products exist, **When** feedback is submitted via a product-specific URL, **Then** the feedback is correctly associated with that product and only visible to its assigned owners
+
-5. **Given** a product exists, **When** I update the preferred translation language setting, **Then** future feedback translations for this product use the new language preference
+~~**Why this priority**: This is administrative infrastructure needed for multi-product support. It's lower priority because the MVP could work with a single hardcoded product. However, it's necessary for a scalable production system.~~
-6. **Given** a product is registered, **When** I view its settings, **Then** I can see statistics like total feedback count, submission URL, and assigned owners
+
-7. **Given** a product has historical feedback, **When** I archive the product, **Then** the feedback is preserved but the product is marked inactive and new submissions are disabled
+~~**Independent Test**: Can be tested by logging in as an administrator, creating a new product/service entry with details (name, description, preferred language for translations), assigning one or more product owners to it, and verifying that the product appears in the system with a unique feedback submission URL and that assigned owners can access its feedback in their dashboards.~~
+
+~~**Acceptance Scenarios**:~~
+
+~~1. **Given** I am an administrator, **When** I create a new product entry with name, description, and preferred language for feedback translations, **Then** the product is registered and assigned a unique identifier~~
+~~2. **Given** a product exists, **When** I assign a user as a product owner, **Then** that user gains access to view feedback for this product in their dashboard~~
+~~3. **Given** a product is registered, **When** I request the feedback submission URL, **Then** I receive a unique URL that end users can use to submit feedback for this specific product~~
+~~4. **Given** multiple products exist, **When** feedback is submitted via a product-specific URL, **Then** the feedback is correctly associated with that product and only visible to its assigned owners~~
+~~5. **Given** a product exists, **When** I update the preferred translation language setting, **Then** future feedback translations for this product use the new language preference~~
+~~6. **Given** a product is registered, **When** I view its settings, **Then** I can see statistics like total feedback count, submission URL, and assigned owners~~
+~~7. **Given** a product has historical feedback, **When** I archive the product, **Then** the feedback is preserved but the product is marked inactive and new submissions are disabled~~
 
 ---
 
@@ -166,18 +179,20 @@ As a platform administrator, I want to register new products or services in the
 - **FR-043**: System MUST preserve status indicators when filtering or searching
 - **FR-044**: System MUST display file attachments with thumbnails for images and appropriate icons for documents
 
-#### Product/Service Management
+#### Product/Service Management **[DEFERRED FOR POC]**
 
-- **FR-045**: System MUST allow administrators to register new products or services
+~~Manual configuration via YAML files replaces admin UI for POC~~
-- **FR-046**: System MUST require each product to have a unique name and identifier
+
-- **FR-047**: System MUST allow setting a preferred target language for translations for each product
+- ~~**FR-045**: System MUST allow administrators to register new products or services~~ **[DEFERRED]** - Manual YAML editing
-- **FR-048**: System MUST allow assigning one or more product owners to each product
+- **FR-046**: System MUST require each product to have a unique name and identifier ✅ **[IMPLEMENTED]** - Via config.yaml
-- **FR-049**: System MUST generate a unique feedback submission URL for each registered product
+- **FR-047**: System MUST allow setting a preferred target language for translations for each product ✅ **[IMPLEMENTED]** - Via config.yaml
-- **FR-050**: System MUST support multiple products in the system simultaneously
+- ~~**FR-048**: System MUST allow assigning one or more product owners to each product~~ **[DEFERRED]** - Manual users.yaml editing
-- **FR-051**: System MUST allow updating product details and owner assignments
+- **FR-049**: System MUST generate a unique feedback submission URL for each registered product ✅ **[IMPLEMENTED]** - Via submission_url_slug
-- **FR-052**: System MUST allow archiving products without deleting historical feedback
+- **FR-050**: System MUST support multiple products in the system simultaneously ✅ **[IMPLEMENTED]** - Product model supports this
-- **FR-053**: System MUST prevent new feedback submissions to archived products
+- ~~**FR-051**: System MUST allow updating product details and owner assignments~~ **[DEFERRED]** - Manual YAML editing
-- **FR-054**: System MUST display product statistics (total feedback count, date created, active/archived status)
+- ~~**FR-052**: System MUST allow archiving products without deleting historical feedback~~ **[DEFERRED]** - Manual status field editing
+- **FR-053**: System MUST prevent new feedback submissions to archived products ✅ **[IMPLEMENTED]** - Checked in submission route
+- ~~**FR-054**: System MUST display product statistics (total feedback count, date created, active/archived status)~~ **[DEFERRED]** - Not needed for POC
 
 #### Security and Privacy
 

specs/001-build-an-application/tasks.md

@@ -228,13 +228,32 @@
 
 ---
 
-## Phase 6: User Story 4 - Product/Service Registration and Management (Priority: P4)
+## Phase 6: User Story 4 - Product/Service Registration and Management ~~(Priority: P4)~~ **[DEFERRED FOR POC]**
 
-**Goal**: Enable administrators to register products, assign owners, manage product settings, and view statistics
+**Status**: **OUT OF SCOPE FOR POC** - Products and users managed manually via YAML files
 
-**Independent Test**: Login as admin, create new product with name/language/owners, verify submission URL works, assign additional owners, archive product, verify submissions blocked
+**Rationale**: For a proof-of-concept, manual management of products and users through configuration files is sufficient. Building an admin UI for product/user management does not add value at this stage. The underlying product/user models and access control are already implemented - only the admin UI routes are deferred.
 
-### Tests for User Story 4 (MUST WRITE FIRST) ⚠️
+**Manual Management Guide**:
+- **Create Product**: Create `data/products/{product-id}/` directory with `config.yaml`
+- **Edit Product**: Modify `data/products/{product-id}/config.yaml` (fields: product_id, name, submission_url_slug, owner_language, assigned_owner_ids, status)
+- **Create User**: Add entry to `data/users.yaml` with bcrypt-hashed password
+- **Assign Product Owners**: Update `product_ids` array in user record in `data/users.yaml`
+- **Archive Product**: Set `status: archived` in product's `config.yaml`
+
+**What's Already Implemented** (no admin UI needed):
+- ✅ Product model with YAML loading (`app/models/product.py`)
+- ✅ User model with role-based access (`app/models/user.py`)
+- ✅ Multi-product support in submission and dashboard
+- ✅ Product access control (owners see assigned, admins see all)
+- ✅ Archived product blocking (submission route checks status)
+- ✅ Unique submission URLs per product (via submission_url_slug)
+
+**Future Consideration**: If POC proves successful and scaling is needed, Phase 6 tasks below can be implemented to add admin UI.
+
+---
+
+### ~~Tests for User Story 4 (DEFERRED)~~ ⚠️
 
 - [ ] T140 [P] [US4] Contract test for GET /admin/products in tests/contract/test_admin_routes.py
 - [ ] T141 [P] [US4] Contract test for GET /admin/products/new in tests/contract/test_admin_routes.py