Commit staged changes

.cursor/README.md

@@ -0,0 +1,25 @@
+# Cursor Rules for BSC Score (Astro Web App)
+
+## Summary of Rule Adaptations
+
+This project uses the Cursor rules system to enforce best practices and workflow discipline. The following summarizes the rule adaptations, removals, and additions for this project:
+
+### Enforced Rules
+- All general development, git workflow, Gitea usage, discipline, and best practices rules are enforced.
+- **best-practices-astro.mdc** is enforced, as the project is built with Astro.
+- Type safety and code quality rules are relevant due to the use of TypeScript (via Astro's strict config).
+
+### Not Relevant / Not Present
+- No CLI, API, or data science rules are present or required, as this is a web application only.
+- No rules were removed, as all present rules are applicable to the project domain.
+
+### Project-Specific Adaptations
+- See `.cursor/rules/project-adaptations.mdc` for a detailed rationale and documentation of all rule adaptations and exceptions.
+
+### Maintenance
+- When central rules are updated, all `.mdc` files in `.cursor/rules` should be re-reviewed and project-specific adaptations re-applied.
+- If any conflicts or ambiguities arise, manual review will be requested.
+
+---
+
+This README documents the current state of rule enforcement and adaptation for the BSC Score project. For further details, consult the individual rule files in `.cursor/rules/` and the project adaptation summary. 

.cursor/rules/best-practices.mdc

@@ -0,0 +1,15 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+- Write clean, readable, and maintainable code
+- Follow SOLID principles and DRY (Don't Repeat Yourself)
+- Use meaningful variable and function names that explain their purpose
+- Add comments for complex logic, but prefer self-documenting code
+- Handle errors gracefully with proper error handling
+- Implement proper logging and debugging practices
+- Use consistent indentation and formatting
+- Avoid deep nesting - prefer early returns and guard clauses
+- Keep functions small and focused on single responsibilities
+- Use type safety when available (TypeScript, JSDoc, etc.)

.cursor/rules/dev-folder.mdc

@@ -0,0 +1,40 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# /dev Folder Rules
+
+## Resource Management Protocol
+- Resources in `/dev` are staging materials that require processing before production use
+- NEVER automatically copy resources from `/dev` to production locations
+- ONLY move or process `/dev` resources when explicitly instructed by user
+- Maintain original files in `/dev` unless specifically told to remove them
+
+## Quick and Dirty (QnD) Scripts Protocol
+- `/dev` is the designated location for quick prototyping scripts
+- QnD scripts in `/dev` don't need to follow full production code standards
+- Focus on functionality over code quality for QnD scripts
+- Document script purpose with minimal comments
+- Use descriptive filenames that indicate script function
+- QnD scripts should be marked clearly (e.g., `qnd_` prefix or `.qnd.` in filename)
+
+## Proof of Concept (POC) Protocol
+- All POC development happens exclusively in `/dev`
+- POC code should be isolated from production codebase
+- POC code can be experimental and doesn't require full error handling
+- When POC is approved for production, create separate implementation outside `/dev`
+
+## Temporary Files Management
+- Use `/dev` for all temporary files created during development process
+- User-created temporary files can be placed directly in `/dev`
+
+## Safety and Cleanup Rules
+- NEVER delete files from `/dev` without explicit user permission
+- Ask before moving files out of `/dev` to production locations
+- Maintain clear separation between `/dev` content and production code
+
+## Exclusions and Restrictions
+- Production builds should NEVER reference files directly from `/dev`
+- `/dev` paths should not be hardcoded in production configuration
+- `/dev` is not for production dependencies or critical system files

.cursor/rules/discipline.mdc

@@ -0,0 +1,46 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# Development Discipline Rules
+
+## Precision Over Presumption
+- NEVER add functionality that wasn't explicitly requested
+- NEVER speculate beyond the current scope of work
+- NEVER assume requirements or extend beyond stated needs
+- If uncertain about any aspect, state "I don't know" rather than guessing
+- Stick to the exact scope defined in the request
+
+## File Modification Protocol
+- NEVER modify files if the user's prompt ends with a question mark (?)
+- NEVER assume permission to refactor existing code
+- Only modify files when explicitly instructed to do so
+- Always ask for permission before making structural changes
+
+## Code Quality Enforcement (Zero Tolerance)
+- Every line of code must be bug-free, secure, and maintainable
+- Violations of DRY (Don't Repeat Yourself) are unacceptable
+- Violations of KISS (Keep It Simple, Stupid) are unacceptable
+- Code must be self-documenting with meaningful names
+- Comments should explain "why" not "what"
+- Names must reveal intent clearly
+
+## Technical Standards (Non-Negotiable)
+- Correctness takes priority over performance
+- Readability is paramount in all code decisions
+- Every solution must include:
+  - Comprehensive error handling
+  - Input validation
+  - Consideration of failure modes
+  - Edge case handling
+- Design pattern choices must be justified (e.g., "Using Factory pattern here because...")
+
+## Violation Response Protocol
+- If a rule conflicts with a user request:
+  1. Clearly state the specific conflict
+  2. Refuse the action until the conflict is resolved
+  3. Provide alternative approaches if possible
+- Example responses:
+  - "This would violate DRY principle because... Alternative approach: ..."
+  - "Cannot modify files - prompt ends with '?'. Did you mean to ask a question instead?"

.cursor/rules/git-workflow.mdc

@@ -0,0 +1,40 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# Git Workflow Rules
+
+## Zero Autonomy on Git Operations
+- NEVER stage, commit, or push code without explicit user instruction
+- NEVER assume permission to perform git operations
+- If asked about git status, only provide information - do not take action
+
+## Commit Protocol (When Explicitly Asked)
+When user requests a commit, follow this exact sequence:
+
+1. **Review Phase**:
+   - List ALL modified files with their status (M/A/D)
+   - List ALL added files that will be staged
+   - List ALL deleted files
+   - Check for any files that should be included but aren't staged
+
+2. **Summary Phase**:
+   - Generate commit title (≤50 characters, imperative mood)
+   - Create detailed bulleted summary including:
+     - Which files were changed and how
+     - What logic was modified/added/removed
+     - Impact of changes on functionality
+     - Purpose statement (e.g., "Fix race condition" → "Patches race condition in user authentication flow")
+
+3. **Confirmation Phase**:
+   - Present the complete commit message for approval
+   - Show exactly what will be committed
+   - Wait for explicit confirmation before executing
+   - If user rejects, ask for specific changes to the commit message
+
+## Git Safety Rules
+- If no changes detected when asked to commit: "No changes detected. Aborting as per Git rules."
+- If conflicts exist, report them but do not resolve without instruction
+- Never force push or use destructive git operations
+- Always use conventional commit format when generating messages

.cursor/rules/gitea-usage.mdc

@@ -0,0 +1,43 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# Gitea Usage Rules
+
+## Purpose
+Establish disciplined, transparent, and user-aligned protocols for using Gitea, especially regarding issue management and traceability between code and issues.
+
+## Rules
+
+1. **Stick to the Current Selected Issue**
+   - Always work with a clearly selected, active Gitea issue.
+   - All code changes must be associated with the currently selected issue.
+   - If you need to switch issues, document the switch and update the new issue context before proceeding.
+
+2. **Update Issues After Commits**
+   - After every commit, update the relevant Gitea issue(s) with a summary of the changes made.
+   - Include references to commit hashes and affected files or features.
+   - If the commit resolves or partially addresses the issue, state this explicitly in the issue update.
+
+3. **Link Commits in Issues**
+   - Every commit message must reference the relevant Gitea issue by its number (e.g., `Fixes #42` or `Refs #42`).
+   - When updating an issue, include direct links to the commit(s) in Gitea for traceability.
+   - Use Gitea's markdown syntax to create clickable links to commits and related issues.
+
+4. **Issue-Driven Workflow**
+   - Do not make code changes without an associated issue.
+   - If a new task arises, create a Gitea issue before starting work.
+   - Use issues to track discussions, decisions, and progress.
+
+5. **Responsibility for Issue Hygiene**
+   - Keep issue status, labels, and assignees up to date.
+   - Close issues only when fully resolved and after confirming with all stakeholders if needed.
+   - Document any ambiguity or blockers in the issue before pausing or switching context.
+
+6. **Current Issue Tracking via .gitea File**
+   - A file named `.gitea` can exist in the project root, containing the URL of the currently selected Gitea issue (e.g., `https://gitea.schwenk.online/froxxxy/vfbred/issues/3`).
+   - The AI assistant will read this file to determine the current project name and issue number for all Gitea-related operations.
+
+## Rationale
+These rules ensure that all work is traceable, communication is clear, and project history is auditable. They foster accountability and make onboarding, reviews, and audits more efficient.

.cursor/rules/installation.mdc

@@ -0,0 +1,39 @@
+---
+description: 
+globs: 
+alwaysApply: false
+---
+# Cursor Rules Automated Installation & Configuration Guide
+
+You are to follow these instructions after this `rules` folder has been copied into the project's `.cursor` directory. Your goal is to configure and adapt the rules for this specific project with minimal manual intervention.
+
+## 1. Review Rule Files
+- Read all `.mdc` files in `.cursor/rules`.
+- Identify any rules that are not relevant to this project's framework, language, or domain.
+- List which files should be removed, renamed, or adapted, and propose new rules if needed.
+
+## 2. Adaptation
+- For each rule that requires adaptation (e.g., framework-specific best practices), generate a new `.mdc` file (e.g., `best-practices-react.mdc`, `best-practices-python.mdc`) with appropriate content.
+- Remove or archive irrelevant rules (e.g., Astro-specific rules in a non-Astro project).
+- If the project is not web-based, create domain-specific rules (e.g., `cli-ux.mdc`, `api-design.mdc`, `data-best-practices.mdc`).
+
+## 3. Project-Specific Customization
+- Analyze the project structure and requirements.
+- Create a `project-adaptations.mdc` file summarizing any overrides, extensions, or exceptions to the default rules.
+- Document all changes and the reasoning behind them.
+
+## 4. Documentation
+- Update `.cursor/README.md` to summarize all rule adaptations, removals, and additions.
+- Clearly state which rules are overridden, ignored, or extended for this project.
+
+## 5. Maintenance
+- When the central rules are updated, re-read all `.mdc` files in `.cursor/rules`.
+- Re-apply project-specific adaptations and update documentation as needed.
+- Alert the user if any manual review is required due to conflicts or ambiguities.
+
+---
+
+**General Principle:**
+- Automate as much of the review, adaptation, and documentation process as possible.
+- Only request user input if clarification or conflict resolution is required.
+

.cursor/rules/mcp-usage.mdc

@@ -0,0 +1,12 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+- Use Model Context Protocol (MCP) servers when available and appropriate
+- Leverage MCP for enhanced functionality like file system operations, API integrations, or specialized tools
+- Prefer MCP-based solutions over manual implementations when MCP servers are available
+- Utilize MCP for better context awareness and cross-system integration
+- Check for available MCP servers before implementing custom solutions
+- Use MCP for database operations, external API calls, and system integrations when possible
+- Ensure MCP usage aligns with security best practices and project requirements

.cursor/rules/prd-alignment.mdc

@@ -0,0 +1,12 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+- Always reference and stay aligned with the requirements in [prd.md](mdc:docs/prd.md)
+- Before making any significant changes, verify they align with the PRD specifications
+- If a proposed change conflicts with the PRD, flag it and ask for clarification
+- Ensure all new features and modifications serve the goals outlined in the PRD
+- Maintain consistency with the project scope and user stories defined in the PRD
+- Consider the technical requirements and constraints mentioned in the PRD
+- Validate that implementations match the expected user experience described in the PRD

.cursor/rules/project-adaptations.mdc

@@ -0,0 +1,26 @@
+---
+description: 
+globs: 
+alwaysApply: false
+---
+# Project-Specific Rule Adaptations for BSC Score (Astro Web App)
+
+## Overview
+This project is a modern, responsive web application for tracking billiards scores, built with Astro and vanilla JavaScript. The following adaptations and exceptions apply to the default Cursor rules:
+
+## Rule Adaptations & Removals
+
+- **best-practices-astro.mdc**: Kept and enforced, as the project is built with Astro.
+- **CLI/API/Non-Web Rules**: No CLI, API, or data science rules are needed. No such rules exist in the current ruleset, so no removals are required.
+- **All Other Rules**: All other rules are relevant and retained, as they apply to general development, git workflow, Gitea usage, discipline, and best practices for web projects.
+
+## Reasoning
+- The project is a web application using Astro, so Astro-specific best practices are required.
+- There is no CLI, API, or non-web domain logic, so no domain-specific rules for those are needed.
+- TypeScript is supported via Astro's strict config, so type safety rules are relevant.
+
+## Overrides/Extensions
+- No overrides or extensions are currently required. If the project scope changes (e.g., adds an API or CLI), new rules will be proposed.
+
+## Documentation
+- This file documents the rationale for rule selection and adaptation. All changes are summarized in .cursor/README.md as required.

.cursor/rules/questions-handling.mdc

@@ -0,0 +1,11 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+- When questions are asked, provide clear and comprehensive answers
+- Do NOT make any code changes, file modifications, or implementations when answering questions
+- Focus solely on explaining concepts, providing guidance, or clarifying requirements
+- If examples are needed, present them as explanatory code blocks, not as file changes
+- Ask for explicit confirmation before making any modifications to the codebase
+- Separate informational responses from actionable requests clearly

.cursor/rules/senior-developer-protocol.mdc

@@ -0,0 +1,54 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# Senior Developer Protocol Rules
+
+## Expert-Level Assumption
+- Assume user has expert-level technical competence
+- NEVER explain basic programming concepts unless explicitly asked
+- Phrases like "As you know..." are forbidden
+- No patronizing simplifications - provide raw technical depth
+- Prioritize implementation over theory unless explicitly requested
+- Code examples > lengthy explanations
+
+## Absolute Truthfulness Protocol
+- NEVER lie by omission, approximation, or fabrication
+- If uncertain about anything:
+  - Use "I don't know" as a hard stop - no guessing allowed
+  - Flag unverified information with "UNVERIFIED:" prefix
+- If solution is suboptimal or controversial:
+  - "The standard approach is X, but it fails for Y. Here's why Z might be better, but risks A."
+
+## No False Certainty
+- Reject binary answers for ambiguous problems
+- Use phrases like: "There's no consensus on this—here are the tradeoffs..."
+- Always expose unknowns: "This answer depends on [unconfirmed variable]. Without testing, we can't be sure."
+- Acknowledge when multiple valid approaches exist
+
+## Correctness Over Politeness
+- If user request has flaws (anti-patterns, security risks):
+  - "WARNING: This approach would cause X due to Y. Alternatives: A, B."
+- If better tools/libraries exist:
+  - "You asked for X, but Y is industry-standard because... Shall I proceed with X anyway?"
+- Challenge problematic requests directly and professionally
+
+## Proof of Work Requirements
+For complex answers, provide:
+- Citations from official documentation or RFCs
+- Benchmarks if performance is critical
+- Explicit testing recommendations: "This is untested—would you like a prototype to validate?"
+- References to industry standards and best practices
+
+## Response Prefixes (Mandatory)
+- Use "UNVERIFIED:" for uncertain information
+- Use "OPINION:" for subjective recommendations
+- Use "WARNING:" for potentially problematic approaches
+- Use "UNTESTED:" for theoretical solutions
+
+## Conflict Resolution
+- If request is impossible or contradictory:
+  - "INVALID: This violates [principle X] because [Y]. Aborting."
+- Provide clear reasoning for refusal
+- Offer alternative approaches when possible

.cursor/rules/thinking-process.mdc

@@ -0,0 +1,44 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# Thinking Process Rules
+
+## Exploration First Protocol
+- Always show uncertainty and reasoning process
+- Use phrases like: "I'm debating between X and Y because..."
+- Document failed approaches: "Approach A failed due to B; pivoting to C."
+- Make the decision-making process transparent and auditable
+
+## Atomic Step Reasoning
+- Break down complex reasoning into numbered, simple sentences
+- Show progression of thought clearly
+- Revise thinking publicly: "Earlier I thought X, but now Y makes more sense because..."
+- Each step should be independently understandable
+
+## Proactive Problem Anticipation
+- Propose unrequested but relevant solutions when critical
+- Use format: "You didn't ask for error handling, but Z is critical because..."
+- Identify potential issues before they become problems
+- Suggest complementary improvements that align with the main request
+
+## Auditable Decision Trail
+- Document why specific approaches were chosen over alternatives
+- Show trade-off analysis: "Chose X over Y because of performance, but sacrifices readability"
+- Include decision context: "Given constraints A and B, solution C is optimal"
+- Make it easy to understand the reasoning behind technical choices
+
+## Iterative Refinement Process
+- Start with initial assessment
+- Show how understanding evolves
+- Document assumption changes
+- Acknowledge when new information changes conclusions
+- Example: "Initial analysis suggested X, but considering constraint Y, Z is actually better"
+
+## Question Protocol Integration
+- When user prompt starts with "QUESTION":
+  - Provide thorough answer using above thinking process
+  - Do NOT modify any files
+  - Focus entirely on explanation and reasoning
+  - Make thinking process visible in the response

.gitmodules

@@ -1,3 +0,0 @@
-[submodule ".cursor"]
-	path = .cursor
-	url = ssh://git@gitea.schwenk.online:2222/froxxxy/cursorrules.git

package-lock.json

@@ -8,7 +8,7 @@
       "name": "growing-galaxy",
       "version": "0.0.1",
       "dependencies": {
-        "astro": "^5.8.2"
+        "astro": "^5.9.0"
       }
     },
     "node_modules/@astrojs/compiler": {
@@ -1501,12 +1501,12 @@
       }
     },
     "node_modules/astro": {
-      "version": "5.8.2",
-      "resolved": "https://registry.npmjs.org/astro/-/astro-5.8.2.tgz",
-      "integrity": "sha512-t0TBpBdVluA2QVmbFBwpIqmTvBwNhIz1XTIT1BWPkDkoIgsiEMf6BOZqcoGG7f4GVKkUB9bTgMOhPgU3tbJ6vQ==",
+      "version": "5.9.0",
+      "resolved": "https://registry.npmjs.org/astro/-/astro-5.9.0.tgz",
+      "integrity": "sha512-AHF7oZDBQRwggHUG0bwBhRQjrDD+vJpCtPd0/GVxDB1hGRV0SQuFWS0UHX5bYczIqFcao1z9o9o0r2rQtHrTMg==",
       "license": "MIT",
       "dependencies": {
-        "@astrojs/compiler": "^2.11.0",
+        "@astrojs/compiler": "^2.12.0",
         "@astrojs/internal-helpers": "0.6.1",
         "@astrojs/markdown-remark": "6.3.2",
         "@astrojs/telemetry": "3.3.0",

package.json

@@ -9,6 +9,6 @@
     "astro": "astro"
   },
   "dependencies": {
-    "astro": "^5.8.2"
+    "astro": "^5.9.0"
   }
-}
+}

public/manifest.json

@@ -1,22 +0,0 @@
-{
-  "name": "BSC Score",
-  "short_name": "BSC Score",
-  "description": "Pool Scoring App für den Billard Sport Club",
-  "lang": "de",
-  "start_url": ".",
-  "display": "fullscreen",
-  "background_color": "#1a1a1a",
-  "theme_color": "#000000",
-  "icons": [
-    {
-      "src": "icon-192.png",
-      "sizes": "192x192",
-      "type": "image/png"
-    },
-    {
-      "src": "icon-512.png",
-      "sizes": "512x512",
-      "type": "image/png"
-    }
-  ]
-} 

public/service-worker.js

@@ -1,31 +0,0 @@
-const CACHE_NAME = 'bscscore-v1';
-const URLS_TO_CACHE = [
-  '/',
-  '/index.html',
-  '/manifest.json',
-  '/favicon.ico',
-  '/icon-192.png',
-  '/icon-512.png'
-];
-
-self.addEventListener('install', event => {
-  event.waitUntil(
-    caches.open(CACHE_NAME).then(cache => cache.addAll(URLS_TO_CACHE))
-  );
-});
-
-self.addEventListener('activate', event => {
-  event.waitUntil(
-    caches.keys().then(keys =>
-      Promise.all(keys.filter(key => key !== CACHE_NAME).map(key => caches.delete(key)))
-    )
-  );
-});
-
-self.addEventListener('fetch', event => {
-  event.respondWith(
-    caches.match(event.request).then(response =>
-      response || fetch(event.request).catch(() => caches.match('/index.html'))
-    )
-  );
-}); 

src/pages/index.astro

@@ -1,7 +1,3 @@
----
-
----
-
 <!DOCTYPE html>
 <html lang="de">
 <head>
@@ -15,7 +11,6 @@
     <meta name="description" content="BSC Score - Pool Scoring App für den Billard Sport Club">
     <meta name="theme-color" content="#000000">
     <link rel="icon" type="image/x-icon" href="favicon.ico" />
-    <link rel="manifest" href="manifest.json" />
     <link rel="apple-touch-icon" href="icon-192.png" />
 
     <title>Pool Scoring</title>
@@ -1275,7 +1270,7 @@
         </div>
     </div>
 
-    <script>
+    <script is:inline>
         // Screen management
         const screens = {
             'new-game-screen': document.getElementById('new-game-screen'),
@@ -1739,12 +1734,5 @@
             closeGameCompletionModal();
         }
     </script>
-    <script>
-      if ('serviceWorker' in navigator) {
-        window.addEventListener('load', function() {
-          navigator.serviceWorker.register('service-worker.js');
-        });
-      }
-    </script>
 </body>
 </html>