306 schedule preparing logic refactor

docs/Git.md

@@ -0,0 +1,99 @@
+## Git Strategy
+
+## Commit Message Formats
+
+### Default
+<pre>
+<b><a href="#types">&lt;type&gt;</a></b></font>(<b><a href="#scopes">&lt;optional scope&gt;</a></b>): <b><a href="#description">&lt;description&gt;</a></b>
+<sub>empty separator line</sub>
+<b><a href="#body">&lt;optional body&gt;</a></b>
+<sub>empty separator line</sub>
+<b><a href="#footer">&lt;optional footer&gt;</a></b>
+</pre>
+
+### Types
+* API relevant changes
+    * `feat` Commits, that add or remove a new feature
+    * `fix` Commits, that fixes a bug
+* `refactor` Commits, that rewrite/restructure your code, however, does not change any API behavior
+    * `perf` Commits are special `refactor` commits, that improve performance
+* `style` Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
+* `test` Commits, that add missing tests or correct existing tests
+* `docs` Commits, that affect documentation only
+* `build` Commits affect build components like build tool, ci pipeline, dependencies, project version, ...
+* `ops` Commits affect operational components like infrastructure, deployment, backup, recovery, ...
+* `chore` Miscellaneous commits e.g. modifying `.gitignore`
+
+### Scopes
+The `scope` provides additional contextual information.
+* Is an **optional** part of the format
+* Allowed Scopes depends on the specific project
+* Don't use issue identifiers as scopes
+
+### Breaking Changes Indicator
+Breaking changes should be indicated by an `!` before the `:` in the subject line e.g. `feat(api)!: remove status endpoint`
+* Is an **optional** part of the format
+
+### Description
+The `description` contains a concise description of the change.
+* Is a **mandatory** part of the format
+* Use the imperative, present tense: "change" not "changed" nor "changes"
+  * Think of `This commit will...` or `This commit should...`
+* Don't capitalize the first letter
+* No dot (`.`) at the end
+
+### Body
+The `body` should include the motivation for the change and contrast this with previous behavior.
+* Is an **optional** part of the format
+* Use the imperative, present tense: "change" not "changed" nor "changes"
+* This is the place to mention issue identifiers and their relations
+
+### Footer
+The `footer` should contain any information about **Breaking Changes** and is also the place to **reference Issues** that this commit refers to.
+* Is an **optional** part of the format
+* **optionally** reference an issue by its id.
+* **Breaking Changes** should start with the word `BREAKING CHANGES:` followed by space or two newlines. The rest of the commit message is then used for this.
+
+
+### Examples
+* ```
+  feat: add email notifications on new direct messages
+  ```
+* ```
+  feat(shopping cart): add the amazing button
+  ```
+* ```
+  feat!: remove ticket list endpoint
+
+  refers to JIRA-1337
+
+  BREAKING CHANGES: ticket endpoints no longer support listing all entities.
+  ```
+* ```
+  fix(shopping-cart): prevent ordering an empty shopping cart
+  ```
+* ```
+  fix(api): fix the wrong calculation of the request body checksum
+  ```
+* ```
+  fix: add a missing parameter to a service call
+
+  The error occurred because of <reasons>.
+  ```
+* ```
+  perf: decrease memory footprint to determine uniqe visitors by using HyperLogLog
+  ```
+* ```
+  build: update dependencies
+  ```
+* ```
+  build(release): bump version to 1.0.0
+  ```
+* ```
+  refactor: Implement Fibonacci number calculation as recursion
+  ```
+* ```
+  style: remove empty line
+  ```
+
+---

docs/Home.md

@@ -0,0 +1,42 @@
+# OnTime Flutter Project Wiki
+
+Welcome to the OnTime-front project documentation! This wiki contains everything new developers need to understand and contribute to the project.
+
+## 📚 Documentation Index
+
+### Getting Started
+- [Wiki Management Guide](./Wiki-Management.md) - How to modify and upload wiki content
+- [Project Architecture](./Architecture.md) - Understanding the project structure
+- [Git Workflow](./Git.md) - Git strategy and commit message formats
+
+### Development Resources
+- 🚧 **Getting Started Guide** *(Coming Soon)* - Setup and installation
+- 🚧 **Development Guide** *(Coming Soon)* - Development workflow and best practices
+- 🚧 **API Documentation** *(Coming Soon)* - Backend API reference
+- 🚧 **Testing Guide** *(Coming Soon)* - Testing procedures and guidelines
+
+## 🎯 Quick Links
+
+- [Main Repository](https://github.com/DevKor-github/OnTime-front)
+- [Issues](https://github.com/DevKor-github/OnTime-front/issues)
+- [Pull Requests](https://github.com/DevKor-github/OnTime-front/pulls)
+- [Widgetbook](https://on-time-front-widgetbook.web.app/)
+
+## 🤝 Contributing
+
+New to the project? Start here:
+
+1. **Read the [Wiki Management Guide](./Wiki-Management.md)** to understand how documentation works
+2. **Review the [Architecture](./Architecture.md)** to understand the project structure
+3. **Follow the [Git Workflow](./Git.md)** for consistent development practices
+4. **Set up your development environment** *(guide coming soon)*
+
+## 📝 Need Help?
+
+- Create an issue for bugs or feature requests
+- Ask questions in team discussions
+- Contribute to documentation improvements
+
+---
+
+*This wiki is maintained by the OnTime development team and integrated with the main repository.*

docs/Schedule-Timer-System.md

@@ -0,0 +1,132 @@
+# Schedule Timer System
+
+The OnTime app includes an automatic timer system within the `ScheduleBloc` that manages precise timing for schedule start notifications. This system ensures that schedule start events are triggered at the exact scheduled time.
+
+## 🎯 Overview
+
+The timer system automatically:
+
+- Starts when an upcoming schedule is received
+- Triggers a `ScheduleStarted` event at exactly x minute 00 seconds
+- Handles proper cleanup and timer management
+- Ensures thread-safety and prevents memory leaks
+
+## 🔄 Timer Flow
+
+```mermaid
+sequenceDiagram
+    participant UC as UseCase
+    participant SB as ScheduleBloc
+    participant Timer as Timer
+    participant State as State
+
+    UC->>SB: ScheduleUpcomingReceived(schedule)
+    SB->>SB: Cancel existing timer
+    SB->>SB: _startScheduleTimer(schedule)
+    SB->>Timer: Create Timer(targetTime)
+    Note over Timer: Timer set for schedule.scheduleTime<br/>at x minute 00 seconds
+    SB->>State: emit(ScheduleState.upcoming/ongoing)
+
+    Timer-->>SB: Timer fires at exact minute
+    SB->>SB: add(ScheduleStarted())
+    SB->>SB: _onScheduleStarted()
+    SB->>State: emit(ScheduleState.started)
+
+    Note over SB: Timer cleanup on close()<br/>or new schedule received
+```
+
+## 📋 Implementation Details
+
+### Key Components
+
+1. **Timer Management**
+
+   - `_scheduleStartTimer`: Dart Timer instance that handles the countdown
+   - `_currentScheduleId`: Tracks the active schedule to prevent stale events
+
+2. **Event Handling**
+
+   - `ScheduleUpcomingReceived`: Triggers timer setup
+   - `ScheduleStarted`: Fired when timer completes
+
+3. **State Transitions**
+   - `upcoming` → `started`: When timer fires for upcoming schedules
+   - `ongoing` → `started`: When timer fires for preparation-in-progress schedules
+
+### Timer Calculation
+
+The timer calculates the exact target time as:
+
+```dart
+final targetTime = DateTime(
+  scheduleTime.year,
+  scheduleTime.month,
+  scheduleTime.day,
+  scheduleTime.hour,
+  scheduleTime.minute,
+  0, // Always trigger at 00 seconds
+  0, // 0 milliseconds
+);
+```
+
+### Safety Features
+
+- **Timer Cancellation**: Previous timers are automatically cancelled when new schedules arrive
+- **Bloc State Validation**: Timer callbacks verify the bloc is still active before firing events
+- **Schedule ID Matching**: Events only fire for the currently tracked schedule
+- **Proper Cleanup**: All timers are cancelled when the bloc is disposed
+
+## 🛡️ Error Handling
+
+The system includes several safety mechanisms:
+
+1. **Past Schedule Protection**: Timers are not set for schedules in the past
+2. **Bloc Lifecycle Management**: Timer callbacks check `isClosed` before adding events
+3. **Memory Leak Prevention**: All timers are properly cancelled in `close()`
+4. **Race Condition Prevention**: Schedule ID tracking prevents stale timer events
+
+## 📱 Usage Example
+
+The timer system works automatically within the `ScheduleBloc`:
+
+```dart
+// When a new schedule is received
+bloc.add(ScheduleSubscriptionRequested());
+
+// The bloc will:
+// 1. Listen for upcoming schedules
+// 2. Automatically start timers for each schedule
+// 3. Emit ScheduleStarted events at the exact scheduled time
+// 4. Transition to 'started' state
+
+// Listen for state changes
+bloc.stream.listen((state) {
+  if (state.status == ScheduleStatus.started) {
+    // Handle schedule start (e.g., show notification, start tracking)
+  }
+});
+```
+
+## 🔧 Configuration
+
+The timer system requires no additional configuration and works automatically with:
+
+- Any `ScheduleWithPreparationEntity` that has a valid `scheduleTime`
+- Both upcoming and ongoing schedule states
+- All timezone-aware DateTime calculations
+
+## 📊 Performance Considerations
+
+- **Single Timer**: Only one timer runs at a time per bloc instance
+- **Minimal Memory Footprint**: Timers are created/destroyed as needed
+- **Precise Timing**: Uses Dart's native Timer for accurate scheduling
+- **Efficient Cleanup**: No lingering resources after bloc disposal
+
+## 🚀 Future Enhancements
+
+Potential improvements to consider:
+
+- Multiple concurrent schedule timers
+- Configurable timer precision (seconds vs milliseconds)
+- Timer persistence across app restarts
+- Integration with system-level scheduling APIs