gurix/Reklamator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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>
This commit is contained in:
gurix
2025-10-17 10:58:29 +02:00
co-authored by Claude
parent 75d4ba9f3b
commit d98347b6f0
3 changed files with 63 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files
specs/001-build-an-application/spec.md
+38 -23
View File
@@ -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