14893e62a5
This MVP release provides a complete full-stack solution for managing action mappings in Geutebruck's GeViScope and GeViSoft video surveillance systems. ## Features ### Flutter Web Application (Port 8081) - Modern, responsive UI for managing action mappings - Action picker dialog with full parameter configuration - Support for both GSC (GeViScope) and G-Core server actions - Consistent UI for input and output actions with edit/delete capabilities - Real-time action mapping creation, editing, and deletion - Server categorization (GSC: prefix for GeViScope, G-Core: prefix for G-Core servers) ### FastAPI REST Backend (Port 8000) - RESTful API for action mapping CRUD operations - Action template service with comprehensive action catalog (247 actions) - Server management (G-Core and GeViScope servers) - Configuration tree reading and writing - JWT authentication with role-based access control - PostgreSQL database integration ### C# SDK Bridge (gRPC, Port 50051) - Native integration with GeViSoft SDK (GeViProcAPINET_4_0.dll) - Action mapping creation with correct binary format - Support for GSC and G-Core action types - Proper Camera parameter inclusion in action strings (fixes CrossSwitch bug) - Action ID lookup table with server-specific action IDs - Configuration reading/writing via SetupClient ## Bug Fixes - **CrossSwitch Bug**: GSC and G-Core actions now correctly display camera/PTZ head parameters in GeViSet - Action strings now include Camera parameter: `@ PanLeft (Comment: "", Camera: 101028)` - Proper filter flags and VideoInput=0 for action mappings - Correct action ID assignment (4198 for GSC, 9294 for G-Core PanLeft) ## Technical Stack - **Frontend**: Flutter Web, Dart, Dio HTTP client - **Backend**: Python FastAPI, PostgreSQL, Redis - **SDK Bridge**: C# .NET 8.0, gRPC, GeViSoft SDK - **Authentication**: JWT tokens - **Configuration**: GeViSoft .set files (binary format) ## Credentials - GeViSoft/GeViScope: username=sysadmin, password=masterkey - Default admin: username=admin, password=admin123 ## Deployment All services run on localhost: - Flutter Web: http://localhost:8081 - FastAPI: http://localhost:8000 - SDK Bridge gRPC: localhost:50051 - GeViServer: localhost (default port) Generated with Claude Code (https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
116 lines
3.9 KiB
Markdown
116 lines
3.9 KiB
Markdown
# Feature Specification: [FEATURE NAME]
|
|
|
|
**Feature Branch**: `[###-feature-name]`
|
|
**Created**: [DATE]
|
|
**Status**: Draft
|
|
**Input**: User description: "$ARGUMENTS"
|
|
|
|
## User Scenarios & Testing *(mandatory)*
|
|
|
|
<!--
|
|
IMPORTANT: User stories should be PRIORITIZED as user journeys ordered by importance.
|
|
Each user story/journey must be INDEPENDENTLY TESTABLE - meaning if you implement just ONE of them,
|
|
you should still have a viable MVP (Minimum Viable Product) that delivers value.
|
|
|
|
Assign priorities (P1, P2, P3, etc.) to each story, where P1 is the most critical.
|
|
Think of each story as a standalone slice of functionality that can be:
|
|
- Developed independently
|
|
- Tested independently
|
|
- Deployed independently
|
|
- Demonstrated to users independently
|
|
-->
|
|
|
|
### User Story 1 - [Brief Title] (Priority: P1)
|
|
|
|
[Describe this user journey in plain language]
|
|
|
|
**Why this priority**: [Explain the value and why it has this priority level]
|
|
|
|
**Independent Test**: [Describe how this can be tested independently - e.g., "Can be fully tested by [specific action] and delivers [specific value]"]
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
|
2. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
|
|
|
---
|
|
|
|
### User Story 2 - [Brief Title] (Priority: P2)
|
|
|
|
[Describe this user journey in plain language]
|
|
|
|
**Why this priority**: [Explain the value and why it has this priority level]
|
|
|
|
**Independent Test**: [Describe how this can be tested independently]
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
|
|
|
---
|
|
|
|
### User Story 3 - [Brief Title] (Priority: P3)
|
|
|
|
[Describe this user journey in plain language]
|
|
|
|
**Why this priority**: [Explain the value and why it has this priority level]
|
|
|
|
**Independent Test**: [Describe how this can be tested independently]
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
|
|
|
---
|
|
|
|
[Add more user stories as needed, each with an assigned priority]
|
|
|
|
### Edge Cases
|
|
|
|
<!--
|
|
ACTION REQUIRED: The content in this section represents placeholders.
|
|
Fill them out with the right edge cases.
|
|
-->
|
|
|
|
- What happens when [boundary condition]?
|
|
- How does system handle [error scenario]?
|
|
|
|
## Requirements *(mandatory)*
|
|
|
|
<!--
|
|
ACTION REQUIRED: The content in this section represents placeholders.
|
|
Fill them out with the right functional requirements.
|
|
-->
|
|
|
|
### Functional Requirements
|
|
|
|
- **FR-001**: System MUST [specific capability, e.g., "allow users to create accounts"]
|
|
- **FR-002**: System MUST [specific capability, e.g., "validate email addresses"]
|
|
- **FR-003**: Users MUST be able to [key interaction, e.g., "reset their password"]
|
|
- **FR-004**: System MUST [data requirement, e.g., "persist user preferences"]
|
|
- **FR-005**: System MUST [behavior, e.g., "log all security events"]
|
|
|
|
*Example of marking unclear requirements:*
|
|
|
|
- **FR-006**: System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?]
|
|
- **FR-007**: System MUST retain user data for [NEEDS CLARIFICATION: retention period not specified]
|
|
|
|
### Key Entities *(include if feature involves data)*
|
|
|
|
- **[Entity 1]**: [What it represents, key attributes without implementation]
|
|
- **[Entity 2]**: [What it represents, relationships to other entities]
|
|
|
|
## Success Criteria *(mandatory)*
|
|
|
|
<!--
|
|
ACTION REQUIRED: Define measurable success criteria.
|
|
These must be technology-agnostic and measurable.
|
|
-->
|
|
|
|
### Measurable Outcomes
|
|
|
|
- **SC-001**: [Measurable metric, e.g., "Users can complete account creation in under 2 minutes"]
|
|
- **SC-002**: [Measurable metric, e.g., "System handles 1000 concurrent users without degradation"]
|
|
- **SC-003**: [User satisfaction metric, e.g., "90% of users successfully complete primary task on first attempt"]
|
|
- **SC-004**: [Business metric, e.g., "Reduce support tickets related to [X] by 50%"]
|