From d98347b6f0df2f655426d1c2233ee633aa205431 Mon Sep 17 00:00:00 2001 From: Markus Graf Date: Fri, 17 Oct 2025 10:58:29 +0200 Subject: [PATCH] Defer Phase 6 (User Story 4) for POC - Manual YAML management MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- specs/001-build-an-application/plan.md | 2 + specs/001-build-an-application/spec.md | 61 +++++++++++++++---------- specs/001-build-an-application/tasks.md | 27 +++++++++-- 3 files changed, 63 insertions(+), 27 deletions(-) diff --git a/specs/001-build-an-application/plan.md b/specs/001-build-an-application/plan.md index 69e42bf..60c8e1d 100644 --- a/specs/001-build-an-application/plan.md +++ b/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+ diff --git a/specs/001-build-an-application/spec.md b/specs/001-build-an-application/spec.md index be0216e..4e1011a 100644 --- a/specs/001-build-an-application/spec.md +++ b/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 -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 +**Original Requirements** (preserved for future reference): + +~~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.~~ + +~~**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 -- **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-048**: System MUST allow assigning one or more product owners to each product -- **FR-049**: System MUST generate a unique feedback submission URL for each registered product -- **FR-050**: System MUST support multiple products in the system simultaneously -- **FR-051**: System MUST allow updating product details and owner assignments -- **FR-052**: System MUST allow archiving products without deleting historical feedback -- **FR-053**: System MUST prevent new feedback submissions to archived products -- **FR-054**: System MUST display product statistics (total feedback count, date created, active/archived status) +~~Manual configuration via YAML files replaces admin UI for POC~~ + +- ~~**FR-045**: System MUST allow administrators to register new products or services~~ **[DEFERRED]** - Manual YAML editing +- **FR-046**: System MUST require each product to have a unique name and identifier ✅ **[IMPLEMENTED]** - Via config.yaml +- **FR-047**: System MUST allow setting a preferred target language for translations for each product ✅ **[IMPLEMENTED]** - Via config.yaml +- ~~**FR-048**: System MUST allow assigning one or more product owners to each product~~ **[DEFERRED]** - Manual users.yaml editing +- **FR-049**: System MUST generate a unique feedback submission URL for each registered product ✅ **[IMPLEMENTED]** - Via submission_url_slug +- **FR-050**: System MUST support multiple products in the system simultaneously ✅ **[IMPLEMENTED]** - Product model supports this +- ~~**FR-051**: System MUST allow updating product details and owner assignments~~ **[DEFERRED]** - Manual YAML editing +- ~~**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 diff --git a/specs/001-build-an-application/tasks.md b/specs/001-build-an-application/tasks.md index 055d380..0bd2abc 100644 --- a/specs/001-build-an-application/tasks.md +++ b/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