Update group one ips.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,67 @@
+# Description
+
+Fixes #(issue number)
+_Explain how this code impacts users._
+
+## Type of change
+
+- [ ] New feature (non-breaking change which adds functionality).
+- [ ] Bug fix (non-breaking change which fixes an issue).
+- [ ] Enhancement (non-breaking change which improves an existing functionality).
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as before).
+- [ ] Sub-task of #(issue number)
+- [ ] Chore
+- [ ] Release
+
+## Detailed scenario
+
+### What was tested
+
+_Describe the scenarios that you tested, and specify if it is automated or manual. For manual scenarios, provide a screenshot of the results._
+
+### How to test
+
+_Describe how the PR can be tested so that the validator can be autonomous: environment, dependencies, specific setup, steps to perform, API requests, etc._
+
+### Affected Features & Quality Assurance Scope
+
+_Please specify which existing features or modules are impacted by the changes in this Pull Request. This information is crucial for the QA team to properly define the testing scope and ensure comprehensive test coverage._
+
+## Technical description
+
+### Documentation
+
+_Explain how this code works. Diagrams & drawings are welcome._
+
+### New dependencies
+
+_List any new dependencies that are required for this change._
+
+### Risks
+
+_List possible performance & security issues or risks, and explain how they have been mitigated._
+
+# Mandatory Checklist
+
+## Code validation
+
+- [ ] I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
+- [ ] I triggered all changed lines of code at least once without new errors/warnings/notices.
+- [ ] I implemented built-in tests to cover the new/changed code.
+
+## Code style
+
+- [ ] I wrote a self-explanatory code about what it does.
+- [ ] I protected entry points against unexpected inputs.
+- [ ] I did not introduce unnecessary complexity.
+- [ ] Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.
+
+## Unticked items justification
+
+_If some mandatory items are not relevant, explain why in this section._
+
+# Additional Checks
+
+- [ ] In the case of complex code, I wrote comments to explain it.
+- [ ] When possible, I prepared ways to observe the implemented system (logs, data, etc.).
+- [ ] I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

.github/copilot-instructions.md

@@ -0,0 +1,138 @@
+## Project Templates
+
+### Pull Request Template
+
+When creating pull requests, use this structure:
+
+```markdown
+## Description
+
+Fixes #issuenumber
+
+## Type of change
+
+- [ ] New feature (non-breaking change which adds functionality).
+- [ ] Bug fix (non-breaking change which fixes an issue).
+- [x] Enhancement (non-breaking change which improves an existing functionality).
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as before).
+- [ ] Sub-task of #(issue number)
+- [ ] Chore
+- [ ] Release
+
+## Detailed scenario
+
+### What was tested
+
+To be tested.
+
+### How to test
+
+To be tested.
+
+### Affected Features & Quality Assurance Scope
+
+## Technical description
+
+### Documentation
+
+Add here what documentation was added. But documentation should be added in the repo itself (/docs).
+
+### New dependencies
+
+Add here dependencies for this PR.
+
+### Risks
+
+Add here risks involving this PR
+
+## Mandatory Checklist
+
+### Code validation
+
+- [ ] I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
+- [ ] I triggered all changed lines of code at least once without new errors/warnings/notices.
+- [ ] I implemented built-in tests to cover the new/changed code.
+
+### Code style
+
+- [ ] I wrote a self-explanatory code about what it does.
+- [ ] I protected entry points against unexpected inputs.
+- [ ] I did not introduce unnecessary complexity.
+- [ ] Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.
+
+### Unticked items justification
+
+Add here justification for why you didn't check everything above.
+
+### Additional Checks
+
+- [ ] In the case of complex code, I wrote comments to explain it.
+- [ ] When possible, I prepared ways to observe the implemented system (logs, data, etc.).
+- [ ] I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)
+```
+
+### Bug Grooming Template
+
+When grooming bugs, use this structure:
+
+```markdown
+**Reproduce the problem**
+
+1. Do this
+2. Then
+
+**Identify the root cause**
+The issue is that …
+
+**Scope a solution**
+To solve the issue, we must …
+
+**Development steps:**
+
+- [ ] Add DB column
+- [ ] Create new endpoint
+- [ ] Implement business logic
+
+**How will this be validated?**
+Consider manual test scenarios and possible automations. Will a specific setup be needed?
+
+**Grooming confidence level**
+Are you sure the proposed solution will work? Have you tested it? Do you foresee any risks or unknowns?
+
+**Can be peer-coded:** Yes/No
+
+**Is a refactor needed in that part of the codebase?**
+Yes, the data layer could be re-written to be more generic, easing future updates. This would make the effort size XS/S/M/L/XL.
+
+**Effort estimation:** XS/S/M/L/XL
+```
+
+### User Story Grooming Template
+
+When grooming user stories, use this structure:
+
+```markdown
+**Scope a solution**
+To implement this feature, we must …
+
+**Development steps**
+
+- [ ] Add DB column
+- [ ] Create new endpoint
+- [ ] Implement business logic
+
+**How will this be validated?**
+Consider manual test scenarios and possible automations. Will a specific setup be needed?
+
+**Grooming confidence level:**
+Are you sure the proposed solution will work? Have you tested it? Do you foresee any risks or unknowns?
+
+**Can be peer-coded:** Yes/No
+
+**Is a refactor needed in that part of the codebase?**
+Yes, the data layer could be re-written to be more generic, easing future updates. This would make the effort size XS/S/M/L/XL.
+
+**Effort estimation:** XS/S/M/L/XL
+```
+
+Remember: This is an internal tool, so prioritize reliability and maintainability over public-facing features.

README.md

@@ -12,6 +12,9 @@ The Slack integration requires the app to be declared and installed as a Slack A
 Run the script app.py
 The app will listen on the configured port for API calls.
 
+## Documentation
+For detailed information about available API endpoints and Slack commands, see [docs/endpoints.md](docs/endpoints.md).
+
 ## Features
 ### Create GitHub tasks from Slack
 The Slack app adds a shortcut to create a GitHub task in the configured GitHub Project(V2). When triggered, a modal is opened to fill out information related to the task.

docker-compose.yml

@@ -0,0 +1,20 @@
+version: "3.2"
+
+services:
+  web:
+    image: tbtt-app
+    build:
+      context: .
+      dockerfile: Dockerfile
+    ports:
+      - "3000:3000"
+    volumes:
+      - .:/app
+    environment:
+      TBTT_GITHUB_ACCESS_TOKEN: tbtt_github_token
+      TBTT_SLACK_BOT_USER_TOKEN: tbtt_slack_bot_user_token
+      TBTT_SLACK_SIGNING_SECRET: tbtt_slack_signing_secret
+      TBTT_SLACK_USER_TOKEN: tbtt_slack_user_token
+      TBTT_GITHUB_WEBHOOK_SECRET: tbtt_github_webhook_secret
+      TBTT_GODP_AUTH_TOKEN: d
+      TBTT_NOTION_API_KEY: e